From palmer@google.com Tue Nov 8 15:57:12 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2A611E80A2 for ; Tue, 8 Nov 2011 15:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.477 X-Spam-Level: X-Spam-Status: No, score=-104.477 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Tyfuik86OF04 for ; Tue, 8 Nov 2011 15:57:11 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB3B311E8081 for ; Tue, 8 Nov 2011 15:57:10 -0800 (PST) Received: by wyg30 with SMTP id 30so1276435wyg.31 for ; Tue, 08 Nov 2011 15:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=dI8n+t9iGZO1fs1jF6iqED0jRAPbcTX08Joz6bfyYhk=; b=BBgnJ26PhMEA7wm/ZVxECp89HoEuJs41cVcr+kMvIrjZdjceP78SsZF8//dzRT2ERf nzxkYb8sj/SAvxHChR5w== Received: by 10.216.135.79 with SMTP id t57mr15750wei.4.1320796627873; Tue, 08 Nov 2011 15:57:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.135.79 with SMTP id t57mr15742wei.4.1320796627613; Tue, 08 Nov 2011 15:57:07 -0800 (PST) Received: by 10.216.216.205 with HTTP; Tue, 8 Nov 2011 15:57:07 -0800 (PST) Date: Tue, 8 Nov 2011 15:57:07 -0800 Message-ID: From: Chris Palmer To: IETF WebSec WG , Chris Evans Content-Type: multipart/mixed; boundary=0016e6de14edcf384104b141ed16 X-System-Of-Record: true Cc: Ian Fette , Wan-Teh Chang Subject: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 23:57:12 -0000 --0016e6de14edcf384104b141ed16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I tried to get this in by the deadline last week, but I had formatting errors at the last minute (the draft name had changed to reflect its non-HSTS nature, so the submission form rejected my version of -01! Sigh), and then it cuts you off at 5:00 PST. Ah well. I've attached the .txt form of the latest draft, and Ian Fette and Wan-Teh Chang will be with you in Taipei. Only Ian has officially signed on to represent this proposal at the meeting, though. I changed a lot in this document, thanks to all your excellent suggestions. Especially Jeff Hodges! This is a significantly different and simpler document than the previous versions, although I'm sure it's still not perfect =E2=80=94 blame me for those parts. --0016e6de14edcf384104b141ed16 Content-Type: text/plain; charset=US-ASCII; name="draft-evans-palmer-key-pinning-00.txt" Content-Disposition: attachment; filename="draft-evans-palmer-key-pinning-00.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gurk5oy20 CgoKV2ViIFNlY3VyaXR5ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEMuIEV2YW5zCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEMuIFBhbG1lcgpFeHBpcmVzOiBBcHJpbCAzLCAyMDEy ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHb29nbGUsIEluYy4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT2N0 b2JlciAyMDExCgoKICAgICAgICAgICAgICAgICBQdWJsaWMgS2V5IFBpbm5pbmcgRXh0ZW5zaW9u IGZvciBIVFRQCiAgICAgICAgICAgICAgICAgICBkcmFmdC1ldmFucy1wYWxtZXIta2V5LXBpbm5p bmctMDAKCkFic3RyYWN0CgogICBUaGlzIG1lbW8gZGVzY3JpYmVzIGFuIGV4dGVuc2lvbiB0byB0 aGUgSFRUUCBwcm90b2NvbCBhbGxvd2luZyB3ZWIKICAgaG9zdCBvcGVyYXRvcnMgdG8gaW5zdHJ1 Y3QgdXNlciBhZ2VudHMgKFVBcykgdG8gcmVtZW1iZXIgKCJwaW4iKSB0aGUKICAgaG9zdHMnIGNy eXB0b2dyYXBoaWMgaWRlbnRpdGllcyBmb3IgYSBnaXZlbiBwZXJpb2Qgb2YgdGltZS4gIER1cmlu ZwogICB0aGF0IHRpbWUsIFVBcyB3aWxsIHJlcXVpcmUgdGhhdCB0aGUgaG9zdCBwcmVzZW50IGEg Y2VydGlmaWNhdGUgY2hhaW4KICAgaW5jbHVkaW5nIGF0IGxlYXN0IG9uZSBTdWJqZWN0IFB1Ymxp YyBLZXkgSW5mbyBzdHJ1Y3R1cmUgd2hvc2UKICAgZmluZ2VycHJpbnQgbWF0Y2hlcyBvbmUgb3Ig bW9yZSBvZiB0aGUgcGlubmVkIGZpbmdlcnByaW50cyBmb3IgdGhhdAogICBob3N0LiAgQnkgZWZm ZWN0aXZlbHkgcmVkdWNpbmcgdGhlIHNjb3BlIG9mIGF1dGhvcml0aWVzIHdobyBjYW4KICAgYXV0 aGVudGljYXRlIHRoZSBkb21haW4gZHVyaW5nIHRoZSBsaWZldGltZSBvZiB0aGUgcGluLCBwaW5u aW5nIG1heQogICByZWR1Y2UgdGhlIGluY2lkZW5jZSBvZiBtYW4taW4tdGhlLW1pZGRsZSBhdHRh Y2tzIGR1ZSB0byBjb21wcm9taXNlZAogICBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0aWVzIGFuZCBv dGhlciBhdXRoZW50aWNhdGlvbiBlcnJvcnMgYW5kCiAgIGF0dGFja3MuCgpTdGF0dXMgb2YgdGhp cyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZv cm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJ bnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdp bmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5 IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMu ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBh cmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1l bnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQt RHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhh biBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhw aXJlIG9uIEFwcmlsIDMsIDIwMTIuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMp IDIwMTEgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9j dW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlz IHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lv bnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3Jn L2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9m IHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVs bHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJl c3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJv bSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRl eHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92 aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQg aW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgoKMS4gIEludHJvZHVjdGlvbgoKICAgV2Ug cHJvcG9zZSBhIG5ldyBIVFRQIGhlYWRlciB0byBlbmFibGUgYSB3ZWIgaG9zdCB0byBleHByZXNz IHRvIHVzZXIKICAgYWdlbnRzIChVQXMpIHdoaWNoIFN1YmplY3QgUHVibGljIEtleSBJbmZvIChT UEtJKSBzdHJ1Y3R1cmUocykgVUFzCiAgIE1VU1QgZXhwZWN0IHRvIGJlIHByZXNlbnQgaW4gdGhl IGhvc3QncyBjZXJ0aWZpY2F0ZSBjaGFpbiBpbiBmdXR1cmUKICAgY29ubmVjdGlvbnMgdXNpbmcg VExTIChzZWUgW3JmYy01MjQ2XSkuICBXZSBjYWxsIHRoaXMgInB1YmxpYyBrZXkKICAgcGlubmlu ZyIuICBBdCBsZWFzdCBvbmUgdXNlciBhZ2VudCAoR29vZ2xlIENocm9tZSkgaGFzIGV4cGVyaW1l bnRlZAogICB3aXRoIHNoaXBwaW5nIHdpdGggYSB1c2VyLWV4dGVuc2libGUgZW1iZWRlZCBzZXQg b2YgcGlucy4gIEFsdGhvdWdoCiAgIGVmZmVjdGl2ZSwgdGhpcyBkb2VzIG5vdCBzY2FsZS4gIFRo aXMgcHJvcG9zYWwgYWRkcmVzc2VzIHRoZSBzY2FsZQogICBwcm9ibGVtLgoKICAgRGVwbG95aW5n IHB1YmxpYyBrZXkgcGlubmluZyBzYWZlbHkgd2lsbCByZXF1aXJlIG9wZXJhdGlvbmFsIGFuZAog ICBvcmdhbml6YXRpb25hbCBtYXR1cml0eSBkdWUgdG8gdGhlIHJpc2sgdGhhdCBob3N0cyBtYXkg bWFrZQogICB0aGVtc2VsdmVzIHVuYXZhaWxhYmxlIGJ5IHBpbm5pbmcgdG8gYSBTUEtJIHRoYXQg YmVjb21lcyBpbnZhbGlkLgogICAoU2VlIFNlY3Rpb24gMy4pICBXZSBiZWxpZXZlIHRoYXQsIHdp dGggY2FyZSwgaG9zdCBvcGVyYXRvcnMgY2FuCiAgIGdyZWF0bHkgcmVkdWNlIHRoZSByaXNrIG9m IE1JVE0gYXR0YWNrcyBhbmQgb3RoZXIgZmFsc2UtCiAgIGF1dGhlbnRpY2F0aW9uIHByb2JsZW1z IGZvciB0aGVpciB1c2VycyB3aXRob3V0IGluY3VycmluZyB1bmR1ZSByaXNrLgoKICAgV2UgaW50 ZW5kIGZvciBob3N0cyB0byB1c2UgcHVibGljIGtleSBwaW5uaW5nIHRvZ2V0aGVyIHdpdGggSFNU UyAoYXMKICAgZGVmaW5lZCBpbiBbaHN0cy1kcmFmdF0sIGJ1dCBpcyBwb3NzaWJsZSB0byBwaW4g a2V5cyB3aXRob3V0CiAgIHJlcXVpcmluZyBIU1RTLgoKICAgVGhpcyBkcmFmdCBpcyBiZWluZyBk aXNjdXNzZWQgb24gdGhlIFdlYlNlYyBXb3JraW5nIEdyb3VwIG1haWxpbmcKICAgbGlzdCwgd2Vi c2VjQGlldGYub3JnLgoKMS4xLiAgQWJvdXQgTm90YXRpb24KCiAgIFRoZSBrZXkgd29yZHMgIk1V U1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNI T1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwi IGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBp biBbcmZjLTIxMTldLgoKCjIuICBTZXJ2ZXIgYW5kIENsaWVudCBCZWhhdmlvcgoKMi4xLiAgUmVz cG9uc2UgSGVhZGVyIEZpZWxkIFN5bnRheAoKICAgVG8gc2V0IGEgcGluLCBob3N0cyB1c2UgYSBu ZXcgSFRUUCBoZWFkZXIgZmllbGQsIFB1YmxpYy1LZXktUGlucywgaW4KICAgdGhlaXIgSFRUUCBy ZXNwb25zZXMuICBGaWd1cmUgMSBkZXNjcmliZXMgdGhlIHN5bnRheCBvZiB0aGUgaGVhZGVyCiAg IGZpZWxkLgoKICAgUHVibGljLUtleS1QaW5zID0gIlB1YmxpYy1LZXktUGlucyIgIjoiIExXUyBk aXJlY3RpdmVzCgogICBkaXJlY3RpdmVzICAgICAgPSBtYXgtYWdlIExXUyAiOyIgTFdTIGZpbmdl cnByaW50cwogICAgICAgICAgICAgICAgICAgICAvIGZpbmdlcnByaW50cyBMV1MgIjsiIExXUyBt YXgtYWdlCgogICBtYXgtYWdlICAgICAgICAgPSAibWF4LWFnZSIgTFdTICI9IiBMV1MgZGVsdGEt c2Vjb25kcwoKICAgcGlucyAgICAgICAgICAgID0gInBpbnMiIExXUyAiPSIgTFdTIGZpbmdlcnBy aW50cwoKICAgZmluZ2VycHJpbnRzICAgID0gZmluZ2VycHJpbnQKICAgICAgICAgICAgICAgICAg ICAgLyBmaW5nZXJwcmludCAiLCIgZmluZ2VycHJpbnRzCgogICBmaW5nZXJwcmludCAgICAgPSBm cC10eXBlICItIiBiYXNlNjQtZGlnaXRzCgogICBmcC10eXBlICAgICAgICAgPSAic2hhMSIKICAg ICAgICAgICAgICAgICAgICAgLyAic2hhMjU2IgoKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgRmlndXJlIDEKCiAgIEZpZ3VyZSAyIHNob3dzIHNvbWUgZXhhbXBsZSByZXNwb25zZSBo ZWFkZXIgZmllbGRzIHVzaW5nIHRoZSBwaW5zCiAgIGV4dGVuc2lvbiAoZm9sZGVkIGZvciBjbGFy aXR5KS4KCiAgIFB1YmxpYy1LZXktUGluczogbWF4LWFnZT01MDA7CiAgICAgICBwaW5zPXNoYTEt NG45NzJIZlYzNTRLUDU2MHl3NHVxZS9iYVhjPSwKICAgICAgIHNoYTEtSXZHZUxzYnF6UHhkSTBi MHd1ajJ4VlRkWGdjPQoKICAgUHVibGljLUtleS1QaW5zOiBtYXgtYWdlPTMxNTM2MDAwOwogICAg ICAgcGlucz1zaGExLTRuOTcySGZWMzU0S1A1NjB5dzR1cWUvYmFYYz0sCiAgICAgICBzaGEyNTYt TFBKTnVsK3dvdzRtNkRzcXhibmluaHNXSGx3ZnAwSmVjd1F6WXBPTG1DUT0KCiAgIFB1YmxpYy1L ZXktUGluczogcGlucz1zaGExLTRuOTcySGZWMzU0S1A1NjB5dzR1cWUvYmFYYz0sCiAgICAgICBz aGExLXF2VEdIZHpGNktMYXZ0NFBPMGdzMmE2cFEwMD0sCiAgICAgICBzaGEyNTYtTFBKTnVsK3dv dzRtNkRzcXhibmluaHNXSGx3ZnAwSmVjd1F6WXBPTG1DUT0gOwogICAgICAgbWF4LWFnZT0yNTky MDAwCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMgoKMi4yLiAgU2Vt YW50aWNzIG9mIFBpbnMKCiAgIFRoZSBmaW5nZXJwcmludCBpcyB0aGUgU0hBLTEgb3IgU0hBLTI1 NiBoYXNoIG9mIHRoZSBERVItZW5jb2RlZCBBU04uMQogICByZXByZXNlbnRhdGlvbiBvZiB0aGUg U3ViamVjdFB1YmxpY0tleUluZm8gKFNQS0kpIGZpZWxkIG9mIHRoZSBYLjUwOQogICBjZXJ0aWZp Y2F0ZS4gIEZpZ3VyZSAzIHJlcHJvZHVjZXMgdGhlIGRlZmluaXRpb24gb2YgdGhlCiAgIFN1Ympl Y3RQdWJsaWNLZXlJbmZvIHN0cnVjdHVyZSBpbiBbcmZjLTUyODBdLgoKICAgU3ViamVjdFB1Ymxp Y0tleUluZm8gIDo6PSAgU0VRVUVOQ0UgIHsKICAgICAgIGFsZ29yaXRobSAgICAgICAgICAgIEFs Z29yaXRobUlkZW50aWZpZXIsCiAgICAgICBzdWJqZWN0UHVibGljS2V5ICAgICBCSVQgU1RSSU5H ICB9CgogICBBbGdvcml0aG1JZGVudGlmaWVyICA6Oj0gIFNFUVVFTkNFICB7CiAgICAgICBhbGdv cml0aG0gICAgICAgICAgICBPQkpFQ1QgSURFTlRJRklFUiwKICAgICAgIHBhcmFtZXRlcnMgICAg ICAgICAgIEFOWSBERUZJTkVEIEJZIGFsZ29yaXRobSBPUFRJT05BTCAgfQoKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDMKCiAgIFRoZSBTUEtJIGhhc2ggaXMgdGhlbiBl bmNvZGVkIGluIGJhc2UtNjQgZm9yIHVzZSBpbiBhbiBIVFRQIGhlYWRlci4KICAgKFNlZSBbcmZj LTQ2NDhdLikKCiAgIFdlIHBpbiBwdWJsaWMga2V5cywgcmF0aGVyIHRoYW4gZW50aXJlIGNlcnRp ZmljYXRlcywgdG8gZW5hYmxlCiAgIG9wZXJhdG9ycyB0byBnZW5lcmF0ZSBuZXcgY2VydGlmaWNh dGVzIGNvbnRhaW5pbmcgb2xkIHB1YmxpYyBrZXlzCiAgIChzZWUgW3doeS1waW4ta2V5XSkuCgog ICBTZWUgQXBwZW5kaXggQSBmb3IgYW4gZXhhbXBsZSBub24tbm9ybWF0aXZlIHByb2dyYW0gdGhh dCBnZW5lcmF0ZXMKICAgcHVibGljIGtleSBmaW5nZXJwcmludHMgZnJvbSBTdWJqZWN0UHVibGlj S2V5SW5mbyBmaWVsZHMgaW4KICAgY2VydGlmaWNhdGVzLgoKMi4zLiAgTm90aW5nIFBpbnMKCiAg IFVwb24gcmVjZWlwdCBvZiB0aGUgUHVibGljLUtleS1QaW5zIHJlc3BvbnNlIGhlYWRlciBmaWVs ZCwgdGhlIFVBCiAgIG5vdGVzIHRoZSBob3N0IGFzIGEgUGlubmVkIEhvc3QsIHN0b3JpbmcgdGhl IHBpbnMgYW5kIHRoZWlyCiAgIGFzc29jaWF0ZWQgbWF4LWFnZSBpbiBub24tdm9sYXRpbGUgc3Rv cmFnZSAoZm9yIGV4YW1wbGUsIGFsb25nIHdpdGgKICAgdGhlIEhTVFMgbWV0YWRhdGEpLiAgVGhl IHBpbnMgYW5kIHRoZWlyIGFzc29jaWF0ZWQgbWF4LWFnZSBhcmUKICAgY29sbGVjdGl2ZWx5IGtu b3duIGFzIFBpbm5pbmcgTWV0YWRhdGEuCgogICBUaGUgVUEgTVVTVCBvYnNlcnZlIHRoZXNlIGNv bmRpdGlvbnMgd2hlbiBub3RpbmcgYSBob3N0OgoKICAgbyAgVGhlIFVBIE1VU1Qgbm90ZSB0aGUg cGlucyBpZiBhbmQgb25seSBpZiBpdCByZWNlaXZlZCB0aGUgUHVibGljLQogICAgICBLZXktUGlu cyByZXNwb25zZSBoZWFkZXIgZmllbGQgb3ZlciBhbiBlcnJvci1mcmVlIFRMUyBjb25uZWN0aW9u LgoKICAgbyAgVGhlIFVBIE1VU1Qgbm90ZSB0aGUgcGlucyBpZiBhbmQgb25seSBpZiB0aGUgVExT IGNvbm5lY3Rpb24gd2FzCiAgICAgIGF1dGhlbnRpY2F0ZWQgd2l0aCBhIGNlcnRpZmljYXRlIGNo YWluIGNvbnRhaW5pbmcgYXQgbGVhc3Qgb25lIG9mCiAgICAgIHRoZSBTUEtJIHN0cnVjdHVyZXMg aW5kaWNhdGVkIGJ5IGF0IGxlYXN0IG9uZSBvZiB0aGUgZ2l2ZW4KICAgICAgZmluZ2VycHJpbnRz LiAgKFNlZSBTZWN0aW9uIDIuNC4pCgogICBvICBUaGUgVUEgTVVTVCBub3RlIHRoZSBwaW5zIGlm IGFuZCBvbmx5IGlmIHRoZSBnaXZlbiBzZXQgb2YgcGlucwogICAgICBjb250YWlucyBhdCBsZWFz dCBvbmUgcGluIHRoYXQgZG9lcyBOT1QgcmVmZXIgdG8gYW4gU1BLSSBpbiB0aGUKICAgICAgY2Vy dGlmaWNhdGUgY2hhaW4uICAoVGhhdCBpcywgdGhlIGhvc3QgbXVzdCBzZXQgYSBCYWNrdXAgUGlu OyBzZWUKICAgICAgU2VjdGlvbiAzLjEuKQoKICAgSWYgdGhlIFB1YmxpYy1LZXktUGlucyByZXNw b25zZSBoZWFkZXIgZmllbGQgZG9lcyBub3QgbWVldCBhbGwgdGhyZWUKICAgb2YgdGhlc2UgY3Jp dGVyaWEsIHRoZSBVQSBNVVNUIE5PVCBub3RlIHRoZSBob3N0IGFzIGEgUGlubmVkIEhvc3QsCiAg IGFuZCBNVVNUIGRpc2NhcmQgYW55IHByZXZpb3VzbHkgc2V0IFBpbm5pbmcgTWV0YWRhdGEgZm9y IHRoYXQgaG9zdCBpbgogICBpdHMgbm9uLXZvbGF0aWxlIHN0b3JlLiAgUHVibGljLUtleS1QaW5z IHJlc3BvbnNlIGhlYWRlciBmaWVsZHMgdGhhdAogICBtZWV0IGFsbCB0aGVzZSBjcml0ZXJhIGFy ZSBrbm93biBhcyBWYWxpZCBQaW5uaW5nIEhlYWRlcnMuCgogICBXaGVuZXZlciBhIFVBIHJlY2Vp dmVzIGEgVmFsaWQgUGlubmluZyBIZWFkZXIsIGl0IE1VU1Qgc2V0IGl0cwogICBQaW5uaW5nIE1l dGFkYXRhIHRvIHRoZSBleGFjdCBwaW5zIGFuZCBtYXgtYWdlIGdpdmVuIGluIHRoZSBtb3N0CiAg IHJlY2VudGx5IHJlY2VpdmVkIFZhbGlkIFBpbm5pbmcgSGVhZGVyLgoKMi4zLjEuICBtYXgtYWdl CgogICBtYXgtYWdlIHNwZWNpZmllcyB0aGUgbnVtYmVyIG9mIHNlY29uZHMsIGFmdGVyIHRoZSBy ZWNlcHRpb24gb2YgdGhlCiAgIFB1YmxpYy1LZXktUGlucyBIVFRQIFJlc3BvbnNlIEhlYWRlciwg ZHVyaW5nIHdoaWNoIHRoZSBVQSByZWdhcmRzIHRoZQogICBob3N0IGFzIGEgUGlubmVkIEhvc3Qu ICBUaGUgZGVsdGEtc2Vjb25kcyBwcm9kdWN0aW9uIGlzIHNwZWNpZmllZCBpbgogICBbcmZjLTI2 MTZdLgoKICAgTm90ZSB0aGF0IGJ5IHNldHRpbmcgYSBsb3cgb3IgMCB2YWx1ZSBmb3IgbWF4LWFn ZSwgaG9zdHMgZWZmZWN0aXZlbHkKICAgaW5zdHJ1Y3QgVUFzIHRvIGNlYXNlIHJlZ2FyZGluZyB0 aGVtIGFzIFBpbm5lZCBIb3N0cy4KCjIuNC4gIFZhbGlkYXRpbmcgUGlubmVkIENvbm5lY3Rpb25z CgogICBXaGVuIGEgVUEgY29ubmVjdHMgdG8gYSBQaW5uZWQgSG9zdCwgaWYgdGhlIFRMUyBjb25u ZWN0aW9uIGhhcwogICBlcnJvcnMsIGl0IGFwcGxpZXMgaXRzIHVzdWFsIHBvbGljeS4gIEZvciBl eGFtcGxlLCBkZXBlbmRpbmcgb24gdGhlCiAgIHR5cGUgb2YgZmFpbHVyZSwgdGhlIFVBIG1pZ2h0 IG9yIG1pZ2h0IG5vdyBhbGxvdyB0aGUgdXNlciB0aGUgb3B0aW9uCiAgIG9mIGNvbnRpbnVpbmcg d2l0aCB0aGUgY29ubmVjdGlvbiBhbnl3YXkuICBGb3IgaG9zdHMgdGhhdCBhcmUgS25vd24KICAg SFNUUyBIb3N0cyB0aGUgVUEgTVVTVCB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24gaW4gY2FzZSBv ZiBUTFMKICAgZXJyb3JzLCBhcyByZXF1aXJlZCBieSBbaHN0cy1kcmFmdF0uCgogICBJZiB0aGUg Y29ubmVjdGlvbiBoYXMgbm8gZXJyb3JzLCB0aGUgVUEgd2lsbCB0aGVuIGFwcGx5IGEgbmV3CiAg IGNvcnJlY3RuZXNzIGNoZWNrOiBQaW4gVmFsaWRhdGlvbi4gIFRvIHBlcmZvcm0gUGluIFZhbGlk YXRpb24sIHRoZSBVQQogICB3aWxsIGNvbXB1dGUgdGhlIGZpbmdlcnByaW50cyBvZiB0aGUgU1BL SSBzdHJ1Y3R1cmVzIGluIGVhY2gKICAgY2VydGlmaWNhdGUgaW4gdGhlIGhvc3QncyBjZXJ0aWZp Y2F0ZSBjaGFpbi4gIFRoZSBVQSB3aWxsIHRoZW4gY2hlY2sKICAgdGhhdCB0aGUgc2V0IG9mIHRo ZXNlIGZpbmdlcnByaW50cyBpbnRlcnNlY3RzIHRoZSBzZXQgb2YgZmluZ2VycHJpbnRzCiAgIGlu IHRoYXQgaG9zdCdzIFBpbm5pbmcgTWV0YWRhdGEuICBJZiB0aGVyZSBpcyBzZXQgaW50ZXJzZWN0 aW9uLCB0aGUKICAgVUEgY29udGludWVzIHdpdGggdGhlIGNvbm5lY3Rpb24gYXMgbm9ybWFsLiAg T3RoZXJ3aXNlLCB0aGUgVUEgTVVTVAogICB0cmVhdCB0aGlzIFBpbiBGYWlsdXJlIGFzIGEgbm9u LXJlY292ZXJhYmxlIGVycm9yLgoKICAgTm90ZSB0aGF0LCBhbHRob3VnaCB0aGUgVUEgaGFzIHBy ZXZpb3VzbHkgcmVjZWl2ZWQgcHVibGljIGtleSBwaW5zIGF0CiAgIHRoZSBIVFRQIGxheWVyLCBp dCBjYW4gYW5kIE1VU1QgcGVyZm9ybSBQaW4gVmFsaWRhdGlvbiBhdCB0aGUgVExTCiAgIGxheWVy LCBiZWZvcmUgYmVnaW5uaW5nIGFuIEhUVFAgY29udmVyc2F0aW9uIG92ZXIgdGhlIFRMUyBjaGFu bmVsLgogICBUaGUgVExTIGxheWVyIHRodXMgZXZhbHVhdGVzIFRMUyBjb25uZWN0aW9ucyB3aXRo IHBpbm5pbmcgaW5mb3JtYXRpb24KICAgdGhlIFVBIHJlY2VpdmVkIHByZXZpb3VzbHksIHJlZ2Fy ZGxlc3Mgb2YgbWVjaGFuaXNtOiBzdGF0aWNhbGx5CiAgIHByZWxvYWRlZCwgdmlhIEhUVFAgaGVh ZGVyLCBvciBzb21lIG90aGVyIG1lYW5zIChwb3NzaWJseSBpbiB0aGUgVExTCiAgIGxheWVyIGl0 c2VsZikuCgoyLjUuICBJbnRlcmFjdGlvbnMgV2l0aCBQcmVsb2FkZWQgUGluIExpc3RzCgogICBV QXMgTUFZIGNob29zZSB0byBpbXBsZW1lbnQgYnVpbHQtaW4gcHVibGljIGtleSBwaW5zLCBhbG9u Z3NpZGUgYW55CiAgIGJ1aWx0LWluIEhTVFMgb3B0LWluIGxpc3QuICBVQXMgTVVTVCBhbGxvdyB1 c2VycyB0byBvdmVycmlkZSBhCiAgIGJ1aWx0LWluIHBpbiBsaXN0LCBpbmNsdWRpbmcgdHVybmlu ZyBpdCBvZmYuCgogICBVQXMgTVVTVCB1c2UgdGhlIG5ld2VzdCBpbmZvcm1hdGlvbiAtLSBidWls dC1pbiBvciBzZXQgdmlhIFZhbGlkCiAgIFBpbm5pbmcgSGVhZGVyIC0tIHdoZW4gcGVyZm9ybWlu ZyBQaW4gVmFsaWRhdGlvbiBmb3IgdGhlIGhvc3QuCgoyLjYuICBQaW5uaW5nIFNlbGYtU2lnbmVk IEVuZCBFbnRpdGllcwoKICAgVG8gdGhlIGV4dGVudCB0aGF0IFVBcyBhbGxvdyBvciBlbmFibGUg aG9zdHMgdG8gYXV0aGVudGljYXRlCiAgIHRoZW1zZWx2ZXMgd2l0aCBzZWxmLXNpZ25lZCBlbmQg ZW50aXR5IGNlcnRpZmljYXRlcywgdGhleSBNQVkgYWxzbwogICBhbGxvdyBob3N0cyB0byBwaW4g dGhlIHB1YmxpYyBrZXlzIGluIHN1Y2ggY2VydGlmaWNhdGVzLiAgVGhlCiAgIHVzYWJpbGl0eSBh bmQgc2VjdXJpdHkgaW1wbGljYXRpb25zIG9mIHRoaXMgcHJhY3RpY2UgYXJlIG91dHNpZGUgdGhl CiAgIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4KCgozLiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMKCiAgIFBpbm5pbmcgcHVibGljIGtleXMgaGVscHMgaG9zdHMgYXNzZXJ0IHRoZWlyIGNy eXB0b2dyYXBoaWMgaWRlbnRpdHksCiAgIGJ1dCB0aGVyZSBpcyBzb21lIHJpc2sgdGhhdCBhIGhv c3Qgb3BlcmF0b3IgY291bGQgbG9zZSBvciBsb3NlCiAgIGNvbnRyb2wgb2YgdGhlaXIgaG9zdCdz IHByaXZhdGUga2V5LiAgSW4gdGhpcyBjYXNlLCB0aGUgb3BlcmF0b3IKICAgd291bGQgbm90IGJl IGFibGUgdG8gc2VydmUgdGhlaXIgd2ViIHNpdGUgb3IgYXBwbGljYXRpb24gaW4gYSB3YXkKICAg dGhhdCBVQXMgd291bGQgdHJ1c3QgZm9yIHRoZSBkdXJhdGlvbiBvZiB0aGVpciBwaW4ncyBtYXgt YWdlLgogICAoUmVjYWxsIHRoYXQgVUFzIE1VU1QgY2xvc2UgdGhlIGNvbm5lY3Rpb24gdG8gYSBo b3N0IHVwb24gUGluCiAgIEZhaWx1cmUuKQoKMy4xLiAgQmFja3VwIFBpbnMKCiAgIFRoZSBwcmlt YXJ5IHdheSB0byBjb3BlIHdpdGggdGhlIHJpc2sgb2YgaW5hZHZlcnRhbnQgUGluIEZhaWx1cmUg aXMKICAgdG8ga2VlcCBhIEJhY2t1cCBQaW4uIEEgQmFja3VwIFBpbiBpcyBhIGZpbmdlcnByaW50 IGZvciB0aGUgcHVibGljCiAgIGtleSBvZiBhIHNlY29uZGFyeSwgbm90LXlldC1kZXBsb3llZCBr ZXkgcGFpci4gIFRoZSBvcGVyYXRvciBrZWVwcwogICB0aGUgYmFja3VwIGtleSBwYWlyIG9mZmxp bmUsIGFuZCBzZXRzIGEgcGluIGZvciBpdCBpbiB0aGUgUHVibGljLUtleS0KICAgUGlucyBoZWFk ZXIuICBUaGVuLCBpbiBjYXNlIHRoZSBvcGVyYXRvciBsb3NlcyBjb250cm9sIG9mIHRoZWlyCiAg IHByaW1hcnkgcHJpdmF0ZSBrZXksIHRoZXkgY2FuIGRlcGxveSB0aGUgYmFja3VwIGtleSBwYWly LiAgVUFzLCB3aG8KICAgaGF2ZSBoYWQgdGhlIGJhY2t1cCBrZXkgcGFpciBwaW5uZWQgKHdoZW4g aXQgd2FzIHNldCBpbiBwcmV2aW91cwogICBWYWxpZCBQaW5uaW5nIEhlYWRlcnMpLCBjYW4gY29u bmVjdCB0byB0aGUgaG9zdCB3aXRob3V0IGVycm9yLgoKICAgQmVjYXVzZSBoYXZpbmcgYSBiYWNr dXAga2V5IHBhaXIgaXMgc28gaW1wb3J0YW50IHRvIHJlY292ZXJ5LCBVQXMKICAgTVVTVCByZXF1 aXJlIHRoYXQgaG9zdHMgc2V0IGEgQmFja3VwIFBpbi4gKFNlZSBTZWN0aW9uIDIuMy4pCgoKNC4g IFVzYWJpbGl0eSBDb25zaWRlcmF0aW9ucwoKICAgV2hlbiBwaW5uaW5nIHdvcmtzIHRvIGRldGVj dCBpbXBvc3RvciBQaW5uZWQgSG9zdHMsIHVzZXJzIHdpbGwKICAgZXhwZXJpZW5jZSBkZW5pYWwg b2Ygc2VydmljZS4gIFVBcyBNVVNUIGV4cGxhaW4gdGhlIHJlYXNvbiB3aHksIGkuZS4KICAgdGhh dCBpdCB3YXMgaW1wb3NzaWJsZSB0byB2ZXJpZnkgdGhlIGNvbmZpcm1lZCBjcnlwdG9ncmFwaGlj IGlkZW50aXR5CiAgIG9mIHRoZSBob3N0LgoKICAgVUFzIE1VU1QgaGF2ZSBhIHdheSBmb3IgdXNl cnMgdG8gY2xlYXIgY3VycmVudCBwaW5zIHRoYXQgd2VyZSBzZXQgYnkKICAgSFNUUy4gIFVBcyBT SE9VTEQgaGF2ZSBhIHdheSBmb3IgdXNlcnMgdG8gcXVlcnkgdGhlIGN1cnJlbnQgc3RhdGUgb2YK ICAgUGlubmVkIEhvc3RzLgoKCjUuICBBY2tub3dsZWRnZW1lbnRzCgogICBUaGFua3MgdG8gSmVm ZiBIb2RnZXMsIEFkYW0gTGFuZ2xleSwgTmljb2xhcyBMaWR6Ym9yc2tpLCBTTSwgYW5kIFlvYXYK ICAgTmlyIGZvciBzdWdnZXN0aW9ucyBhbmQgZWRpdHMgdGhhdCBjbGFyaWZpZWQgdGhlIHRleHQu ICBUaGFua3MgdG8KICAgVHJldm9yIFBlcnJpbiBmb3Igc3VnZ2VzdGluZyBhIG1lY2hhbmlzbSB0 byBhZmZpcm1hdGl2ZWx5IGJyZWFrIHBpbnMKICAgKFtwaW4tYnJlYWstY29kZXNdKS4gIEFkYW0g TGFuZ2xleSBwcm92aWRlZCB0aGUgU1BLSSBmaW5nZXJwcmludAogICBnZW5lcmF0aW9uIGNvZGUu CgoKNi4gIFdoYXQncyBDaGFuZ2VkCgogICBSZW1vdmVkIHRoZSBzZWN0aW9uIG9uIHBpbiBicmVh ayBjb2RlcyBhbmQgdmVyaWZpZXJzLCBpbiBmYXZvciB0aGUgb2YKICAgbW9zdC1yZWNlbnRseS1y ZWNlaXZlZCBwb2xpY3kgKFNlY3Rpb24gMi4zKS4KCiAgIE5vdyB1c2luZyBhIG5ldyBoZWFkZXIg ZmllbGQsIFB1YmxpYy1LZXktUGlucywgc2VwYXJhdGUgZnJvbSBIU1RTLgogICBUaGlzIGFsbG93 cyBob3N0cyB0byB1c2UgcGlubmluZyBzZXBhcmF0ZWx5IGZyb20gU3RyaWN0IFRyYW5zcG9ydAog ICBTZWN1cml0eS4KCiAgIEV4cGxpY2l0bHkgcmVxdWlyaW5nIHRoYXQgVUFzIHBlcmZvcm0gUGlu IFZhbGlkYXRpb24gYmVmb3JlIHRoZSBIVFRQCiAgIGNvbnZlcnNhdGlvbiBiZWdpbnMuCgogICBC YWNrdXAgUGlucyBhcmUgbm93IHJlcXVpcmVkLgoKICAgU2VwYXJhdGVkIG5vcm1hdGl2ZSBmcm9t IG5vbi1ub3JtYXRpdmUgbWF0ZXJpYWwuICBSZW1vdmVkIHRhbmdlbnRpYWwKICAgYW5kIG91dC1v Zi1zY29wZSBub24tbm9ybWF0aXZlIGRpc2N1c3Npb24uCgoKNy4gIFJlZmVyZW5jZXMKCiAgIFto c3RzLWRyYWZ0XQogICAgICAgICAgICAgIEhvZGdlcywgSi4sIEphY2tzb24sIEMuLCBhbmQgQS4g QmFydGgsICJIVFRQIFN0cmljdAogICAgICAgICAgICAgIFRyYW5zcG9ydCBTZWN1cml0eSAoSFNU UykiLCBPY3RvYmVyIDIwMTEsIDxodHRwOi8vCiAgICAgICAgICAgICAgdG9vbHMuaWV0Zi5vcmcv aHRtbC8KICAgICAgICAgICAgICBkcmFmdC1pZXRmLXdlYnNlYy1zdHJpY3QtdHJhbnNwb3J0LXNl Yy0wMz4uCgogICBbd2h5LXBpbi1rZXldCiAgICAgICAgICAgICAgTGFuZ2xleSwgQS4sICJQdWJs aWMgS2V5IFBpbm5pbmciLCBNYXkgMjAxMSwKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5pbXBl cmlhbHZpb2xldC5vcmcvMjAxMS8wNS8wNC9waW5uaW5nLmh0bWw+LgoKICAgW3Bpbi1icmVhay1j b2Rlc10KICAgICAgICAgICAgICBQZXJyaW4sIFQuLCAiU2VsZi1Bc3NlcnRlZCBLZXkgUGlubmlu ZyIsIFNlcHRlbWJlciAyMDExLAogICAgICAgICAgICAgIDxodHRwOi8vdHJldnAubmV0L1NBS1Av Pi4KCiAgIFtyZmMtMjExOV0KICAgICAgICAgICAgICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBm b3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZl bHMiLCBNYXJjaCAxOTk3LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LmlldGYub3JnL3JmYy9y ZmMyMTE5LnR4dD4uCgogICBbcmZjLTI2MTZdCiAgICAgICAgICAgICAgRmllbGRpbmcsIFIuLCBH ZXR0eXMsIEouLCBNb2d1bCwgSi4sIEZyeXN0eWssIEguLAogICAgICAgICAgICAgIE1hc2ludGVy LCBMLiwgTGVhY2gsIFAuLCBhbmQgVC4gQmVybmVycy1MZWUsICJIeXBlcnRleHQKICAgICAgICAg ICAgICBUcmFuc2ZlciBQcm90b2NvbCAtLSBIVFRQLzEuMSIsIEp1bmUgMTk5OSwKICAgICAgICAg ICAgICA8aHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjMjYxNi50eHQ+LgoKICAgW3JmYy00NjQ4 XQogICAgICAgICAgICAgIEpvc2Vmc3NvbiwgUy4sICJUaGUgQmFzZTE2LCBCYXNlMzIsIGFuZCBC YXNlNjQgRGF0YQogICAgICAgICAgICAgIEVuY29kaW5ncyIsIE9jdG9iZXIgMjAwNiwKICAgICAg ICAgICAgICA8aHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjNDY0OC50eHQ+LgoKICAgW3JmYy01 MjQ2XQogICAgICAgICAgICAgIFJlc2NvcmxhLCBFLiBhbmQgVC4gRGllcmtzLCAiVGhlIFRyYW5z cG9ydCBMYXllciBTZWN1cml0eQogICAgICAgICAgICAgIChUTFMpIFByb3RvY29sIFZlcnNpb24g MS4yIiwgQXVndXN0IDIwMDgsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj L3JmYzUyNDYudHh0Pi4KCiAgIFtyZmMtNTI4MF0KICAgICAgICAgICAgICBDb29wZXIsIEQuLCBT YW50ZXNzb24sIFMuLCBGYXJyZWxsLCBTLiwgQm9leWVuLCBTLiwKICAgICAgICAgICAgICBIb3Vz bGV5LCBSLiwgYW5kIFcuIFBvbGssICJJbnRlcm5ldCBYLjUwOSBQdWJsaWMgS2V5CiAgICAgICAg ICAgICAgSW5mcmFzdHJ1Y3R1cmUgQ2VydGlmaWNhdGUgYW5kIENlcnRpZmljYXRlIFJldm9jYXRp b24gTGlzdAogICAgICAgICAgICAgIChDUkwpIFByb2ZpbGUiLCBNYXkgMjAwOCwKICAgICAgICAg ICAgICA8aHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjNTI4MC50eHQ+LgoKCkFwcGVuZGl4IEEu ICBGaW5nZXJwcmludCBHZW5lcmF0aW9uCgogICBUaGlzIEdvIHByb2dyYW0gZ2VuZXJhdGVzIHB1 YmxpYyBrZXkgZmluZ2VycHJpbnRzLCBzdWl0YWJsZSBmb3IgdXNlCiAgIGluIHBpbm5pbmcsIGZy b20gUEVNLWVuY29kZWQgY2VydGlmaWNhdGVzLiAgSXQgaXMgbm9uLW5vcm1hdGl2ZS4KCiAgIHBh Y2thZ2UgbWFpbgoKICAgaW1wb3J0ICgKICAgICAgICAgICJpby9pb3V0aWwiCiAgICAgICAgICAi b3MiCiAgICAgICAgICAiY3J5cHRvL3NoYTEiCiAgICAgICAgICAiY3J5cHRvL3g1MDkiCiAgICAg ICAgICAiZW5jb2RpbmcvYmFzZTY0IgogICAgICAgICAgImVuY29kaW5nL3BlbSIKICAgICAgICAg ICJmbXQiCiAgICkKCiAgIGZ1bmMgbWFpbigpIHsKICAgICAgICAgIGlmIGxlbihvcy5BcmdzKSA8 IDIgewogICAgICAgICAgICAgICAgICBmbXQuUHJpbnRmKCJVc2FnZTogJXMgUEVNLWZpbGVuYW1l XG4iLCBvcy5BcmdzWzBdKQogICAgICAgICAgICAgICAgICBvcy5FeGl0KDEpCiAgICAgICAgICB9 CiAgICAgICAgICBwZW1CeXRlcywgZXJyIDo9IGlvdXRpbC5SZWFkRmlsZShvcy5BcmdzWzFdKQog ICAgICAgICAgaWYgZXJyICE9IG5pbCB7CiAgICAgICAgICAgICAgICAgIHBhbmljKGVyci5TdHJp bmcoKSkKICAgICAgICAgIH0KICAgICAgICAgIGJsb2NrLCBfIDo9IHBlbS5EZWNvZGUocGVtQnl0 ZXMpCiAgICAgICAgICBpZiBibG9jayA9PSBuaWwgewogICAgICAgICAgICAgICAgICBwYW5pYygi Tm8gUEVNIHN0cnVjdHVyZSBmb3VuZCIpCiAgICAgICAgICB9CiAgICAgICAgICBkZXJCeXRlcyA6 PSBibG9jay5CeXRlcwogICAgICAgICAgY2VydHMsIGVyciA6PSB4NTA5LlBhcnNlQ2VydGlmaWNh dGVzKGRlckJ5dGVzKQogICAgICAgICAgaWYgZXJyICE9IG5pbCB7CiAgICAgICAgICAgICAgICAg IHBhbmljKGVyci5TdHJpbmcoKSkKICAgICAgICAgIH0KICAgICAgICAgIGNlcnQgOj0gY2VydHNb MF0KICAgICAgICAgIGggOj0gc2hhMS5OZXcoKQogICAgICAgICAgaC5Xcml0ZShjZXJ0LlJhd1N1 YmplY3RQdWJsaWNLZXlJbmZvKQogICAgICAgICAgZGlnZXN0IDo9IGguU3VtKCkKCiAgICAgICAg ICBmbXQuUHJpbnRmKCJIZXg6ICV4XG5CYXNlNjQ6ICVzXG4iLCBkaWdlc3QsCiAgICAgICAgICAg ICAgICAgIGJhc2U2NC5TdGRFbmNvZGluZy5FbmNvZGVUb1N0cmluZyhkaWdlc3QpKQogICB9Cgog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNAoKCkFwcGVuZGl4IEIuICBE ZXBsb3ltZW50IEd1aWRhbmNlCgogICBUaGlzIHNlY3Rpb24gaXMgbm9uLW5vcm1hdGl2ZSBndWlk YW5jZSB3aGljaCBtYXkgc21vb3RoIHRoZSBhZG9wdGlvbgogICBvZiBwdWJsaWMga2V5IHBpbm5p bmcuCgogICBvICBPcGVyYXRvcnMgU0hPVUxEIGdldCB0aGUgYmFja3VwIHB1YmxpYyBrZXkgc2ln bmVkIGJ5IGEgZGlmZmVyZW50CiAgICAgIChyb290IGFuZC9vciBpbnRlcm1lZGlhcnkpIENBIHRo YW4gdGhlaXIgcHJpbWFyeSBjZXJ0aWZpY2F0ZSwgYW5kCiAgICAgIHN0b3JlIHRoZSBiYWNrdXAg a2V5IHBhaXIgc2FmZWx5IG9mZmxpbmUuCgogICBvICBJdCBpcyBtb3N0IGVjb25vbWljYWwgdG8g aGF2ZSB0aGUgYmFja3VwIGNlcnRpZmljYXRlIHNpZ25lZCBieSBhCiAgICAgIGNvbXBsZXRlbHkg ZGlmZmVyZW50IHNpZ25hdHVyZSBjaGFpbiB0aGFuIHRoZSBsaXZlIGNlcnRpZmljYXRlLCB0bwog ICAgICBtYXhpbWl6ZSByZWNvdmVyYWJpbGl0eSBpbiB0aGUgZXZlbnQgb2YgZWl0aGVyIHJvb3Qg b3IKICAgICAgaW50ZXJtZWRpYXJ5IHNpZ25lciBjb21wcm9taXNlLgoKICAgbyAgT3BlcmF0b3Jz IFNIT1VMRCBwZXJpb2RpY2FsbHkgZXhlcmNpc2UgdGhlaXIgQmFja3VwIFBpbiBwbGFuIC0tIGFu CiAgICAgIHVudGVzdGVkIGJhY2t1cCBpcyBubyBiYWNrdXAgYXQgYWxsLgoKICAgbyAgT3BlcmF0 b3JzIFNIT1VMRCBzdGFydCBzbWFsbC4gIE9wZXJhdG9ycyBTSE9VTEQgZmlyc3QgZGVwbG95CiAg ICAgIHB1YmxpYyBrZXkgcGlubmluZyBieSBzZXR0aW5nIGEgbWF4LWFnZSBvZiBtaW51dGVzIG9y IGEgZmV3IGhvdXJzLAogICAgICBhbmQgZ3JhZHVhbGx5IGluY3JlYXNlIG1heC1hZ2UgYXMgdGhl eSBnYWluIGNvbmZpZGVuY2UgaW4gdGhlaXIKICAgICAgb3BlcmF0aW9uYWwgY2FwYWJpbGl0eS4K CgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIENocmlzIEV2YW5zCiAgIEdvb2dsZSwgSW5jLgogICAx NjAwIEFtcGhpdGhlYXRyZSBQa3d5CiAgIE1vdW50YWluIFZpZXcsIENBICA5NDA0MwogICBVUwoK ICAgRW1haWw6IGNldmFuc0Bnb29nbGUuY29tCgoKICAgQ2hyaXMgUGFsbWVyCiAgIEdvb2dsZSwg SW5jLgogICAxNjAwIEFtcGhpdGhlYXRyZSBQa3d5CiAgIE1vdW50YWluIFZpZXcsIENBICA5NDA0 MwogICBVUwoKICAgRW1haWw6IHBhbG1lckBnb29nbGUuY29tCgo= --0016e6de14edcf384104b141ed16-- From tom@ritter.vg Tue Nov 8 16:32:00 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3736E11E8086 for ; Tue, 8 Nov 2011 16:32:00 -0800 (PST) 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 KIYICjrynxOB for ; Tue, 8 Nov 2011 16:31:59 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0B611E8081 for ; Tue, 8 Nov 2011 16:31:59 -0800 (PST) Received: by iaeo4 with SMTP id o4so1478853iae.31 for ; Tue, 08 Nov 2011 16:31:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZLurUIKWQYBIp+k6DpqsYOedLGIfWKYePfzrOx5wrOQ=; b=L36UMaZyfaEb4THJT+HWT2x5uDOz6pimIY3Kuz9gwACVJ0zyC9Tfv6jwe5Q+uPSi/Z x5Ka+binJYOOXWJ6uuWkhKBR3adSCvM9vv6yOsxQjOoJ7QXkovfE6UnQG+reMgvBvl4U uxILdxJY7s1P+JtND8XjFVliWUpKcvKdmbVjE= Received: by 10.42.108.136 with SMTP id h8mr51274icp.43.1320798718048; Tue, 08 Nov 2011 16:31:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.44.5 with HTTP; Tue, 8 Nov 2011 16:31:37 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Tue, 8 Nov 2011 19:31:37 -0500 Message-ID: To: Chris Palmer Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Fette , Chris Evans , IETF WebSec WG , Wan-Teh Chang Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 00:32:00 -0000 My notes: I believe the BNF (pseudo-BNF?) is incorrect: Public-Key-Pins = "Public-Key-Pins" ":" LWS directives directives = max-age LWS ";" LWS fingerprints / fingerprints LWS ";" LWS max-age max-age = "max-age" LWS "=" LWS delta-seconds pins = "pins" LWS "=" LWS fingerprints fingerprints = fingerprint / fingerprint "," fingerprints fingerprint = fp-type "-" base64-digits fp-type = "sha1" / "sha256" I believe 'directives' should replace "fingerprints" with "pins": directives = max-age LWS ";" LWS pins / pins LWS ";" LWS max-age ================ I think this paragraph is misworded: UAs MUST have a way for users to clear current pins that were set by HSTS. UAs SHOULD have a way for users to query the current state of Pinned Hosts. Instead of HSTS, should that be "Public Key Pinning"? If not, pins set during HSTS must be flagged and treated differently - why? ================ Miscellany: - There is no directive or suggestion to User Agents about saving or not saving pins received in a private browsing mode. Maybe there shouldn't be, but if a User-Agent does save them, the same 304/ETag trick malicious sites use to track users can be created using certs and subdomains. - The "Pinning Self-Signed End Entities" section was a bit confusing, I had to read it a couple times to be sure you were talking about a server's self-signed cert, and not a client cert. - The Pin-Break mechanism gets more complicated which each revision. I know it's being shopped around for both this and the approach to put pinning in the TLS layer (TACK), but does its removal implies pin break codes are not intended to go into the final version of this document, or will it be added later after the first bit is worked out? Thanks Chris(es)! -tom From palmer@google.com Tue Nov 8 17:30:54 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63321F0C51 for ; Tue, 8 Nov 2011 17:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.977 X-Spam-Level: X-Spam-Status: No, score=-103.977 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 8h21l2Sa3x9W for ; Tue, 8 Nov 2011 17:30:54 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E665E1F0C3B for ; Tue, 8 Nov 2011 17:30:53 -0800 (PST) Received: by wwi36 with SMTP id 36so1198514wwi.13 for ; Tue, 08 Nov 2011 17:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=QpC7ECxZtxqE/6lV0ejrgk2tdGCkSdFPXFAEOwZ4YLg=; b=mk29QSyEjshmotNdIhICD31157T8rT5rzVzWoEOxyvYT4XupR1v1hUJmhdKNoTNfRl p1Bp2jjoSXWVy0xM5kqg== Received: by 10.216.141.155 with SMTP id g27mr5041740wej.19.1320802252718; Tue, 08 Nov 2011 17:30:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.141.155 with SMTP id g27mr5041729wej.19.1320802252251; Tue, 08 Nov 2011 17:30:52 -0800 (PST) Received: by 10.216.216.205 with HTTP; Tue, 8 Nov 2011 17:30:52 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Nov 2011 17:30:52 -0800 Message-ID: From: Chris Palmer To: Tom Ritter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Ian Fette , Chris Evans , IETF WebSec WG , Wan-Teh Chang Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 01:30:54 -0000 On Tue, Nov 8, 2011 at 4:31 PM, Tom Ritter wrote: > I believe 'directives' should replace "fingerprints" with "pins": > > =C2=A0 directives =C2=A0 =C2=A0 =C2=A0=3D max-age LWS ";" LWS pins > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 / p= ins LWS ";" LWS max-age You are right. Fixed. > I think this paragraph is misworded: > > UAs MUST have a way for users to clear current pins that were set by > =C2=A0 HSTS. =C2=A0UAs SHOULD have a way for users to query the current s= tate of > =C2=A0 Pinned Hosts. > > Instead of HSTS, should that be "Public Key Pinning"? =C2=A0If not, pins > set during HSTS must be flagged and treated differently - why? You are right. I now say: UAs MUST have a way for users to clear current pins for Pinned Hosts. UAs SHOULD have a way for users to query the current state of Pinned Hosts. > =C2=A0- There is no directive or suggestion to User Agents about saving o= r > not saving pins received in a private browsing mode. =C2=A0Maybe there > shouldn't be, but if a User-Agent does save them, the same 304/ETag > trick malicious sites use to track users can be created using certs > and subdomains. Yes, another person raised this concern, and it is real. I don't see a way to resolve this problem; perhaps I am not smart enough, but I can't see a way to have both dynamic pinning AND avoid this tracking attack. I am willing to add a paragraph about what browsers should do in private browsing mode, and I am willing to go either way on what the requirement should be. I don't know what is best. > =C2=A0- The "Pinning Self-Signed End Entities" section was a bit confusin= g, > I had to read it a couple times to be sure you were talking about a > server's self-signed cert, and not a client cert. Now I say: If UAs accept hosts that authenticate themselves with self-signed end entity certificates, they MAY also allow hosts to pin the public keys in such certificates. The usability and security implications of this practice are outside the scope of this specification. Is that better? > =C2=A0- The Pin-Break mechanism gets more complicated which each revision= . Yeah, that's why I just dropped it. > I know it's being shopped around for both this and the approach to put > pinning in the TLS layer (TACK), but does its removal implies pin > break codes are not intended to go into the final version of this > document, or will it be added later after the first bit is worked out? For now my plan is to ship a trial implementation of HTTP header-based dynamic pinning without pin break codes, and see how people like it. It might turn out that nobody likes pinning at all, or that people like X.509-based dynamic pinning better, and either approach with or without TACK/pin break codes. To get that trial implementation off the ground, I'm doing The Simplest Thing That Could Possibly Work. If it happens that (a) we standardize it without pin break codes and (b) after a year everyone says, "this is great but it really needs pin break codes to be awesome", we'll just update the spec and the implementations. From asteingruebl@paypal-inc.com Tue Nov 8 19:48:20 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDD911E80CC for ; Tue, 8 Nov 2011 19:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 PYDWVTwzZk1Z for ; Tue, 8 Nov 2011 19:48:19 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id BF64C1F0C3B for ; Tue, 8 Nov 2011 19:48:04 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=hGK4OCVOGMd/UP7RyveGtz5iQDZA9MHdMptDIHLwLBdh7RzmftdxRLho 80fxDQl81XXWjYwEelIvu8yh687ZRWYbRisE7hzhO9Y3giWM/i/Zv/0rL WsqE0T3Mh8uR2g6; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1320810485; x=1352346485; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WJgePE0M2QnKfQjPkQ3Fko6K+p8ldkEIxJereYMlt5o=; b=QzvvbwdEbL5wCsr8WBLSzopQhn6poG5RDE83GIs2weIMHO7i/doViV0Y K8xWslEXBf1pRDGQKA0a046jAoXMzlfKbBKe1tzPpZXHQFffenC9U7OIF +xroCeBMVR0Ng8o; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.69,481,1315206000"; d="scan'208";a="4591495" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 08 Nov 2011 19:48:04 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([192.101.150.21]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Tue, 8 Nov 2011 20:48:03 -0700 From: "Steingruebl, Andy" To: Chris Palmer , Tom Ritter Date: Tue, 8 Nov 2011 20:48:02 -0700 Thread-Topic: [websec] New draft of HTTP header-based public key pinning Thread-Index: Acyef1nRALoKchPIQXOqvqePN/ZhyQAEofiw Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEBED718018@DEN-MEXMS-001.corp.ebay.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: M6dVQj4pCy7k87Ny+kjrPA== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter: Scanned Cc: IETF WebSec WG , Chris Evans , Ian Fette , Wan-Teh Chang Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 03:48:20 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiAgQ2hyaXMgUGFsbWVyDQoNCg0K PiA+IMKgLSBUaGVyZSBpcyBubyBkaXJlY3RpdmUgb3Igc3VnZ2VzdGlvbiB0byBVc2VyIEFnZW50 cyBhYm91dCBzYXZpbmcgb3INCj4gPiBub3Qgc2F2aW5nIHBpbnMgcmVjZWl2ZWQgaW4gYSBwcml2 YXRlIGJyb3dzaW5nIG1vZGUuIMKgTWF5YmUgdGhlcmUNCj4gPiBzaG91bGRuJ3QgYmUsIGJ1dCBp ZiBhIFVzZXItQWdlbnQgZG9lcyBzYXZlIHRoZW0sIHRoZSBzYW1lIDMwNC9FVGFnDQo+ID4gdHJp Y2sgbWFsaWNpb3VzIHNpdGVzIHVzZSB0byB0cmFjayB1c2VycyBjYW4gYmUgY3JlYXRlZCB1c2lu ZyBjZXJ0cw0KPiA+IGFuZCBzdWJkb21haW5zLg0KPiANCj4gWWVzLCBhbm90aGVyIHBlcnNvbiBy YWlzZWQgdGhpcyBjb25jZXJuLCBhbmQgaXQgaXMgcmVhbC4gSSBkb24ndCBzZWUgYSB3YXkgdG8N Cj4gcmVzb2x2ZSB0aGlzIHByb2JsZW07IHBlcmhhcHMgSSBhbSBub3Qgc21hcnQgZW5vdWdoLCBi dXQgSSBjYW4ndCBzZWUgYSB3YXkgdG8NCj4gaGF2ZSBib3RoIGR5bmFtaWMgcGlubmluZyBBTkQg YXZvaWQgdGhpcyB0cmFja2luZyBhdHRhY2suDQo+IA0KPiBJIGFtIHdpbGxpbmcgdG8gYWRkIGEg cGFyYWdyYXBoIGFib3V0IHdoYXQgYnJvd3NlcnMgc2hvdWxkIGRvIGluIHByaXZhdGUNCj4gYnJv d3NpbmcgbW9kZSwgYW5kIEkgYW0gd2lsbGluZyB0byBnbyBlaXRoZXIgd2F5IG9uIHdoYXQgdGhl IHJlcXVpcmVtZW50DQo+IHNob3VsZCBiZS4gSSBkb24ndCBrbm93IHdoYXQgaXMgYmVzdC4NCg0K V2UgYmF0dGxlZCB0aGlzIHByb2JsZW0gd2l0aCBIU1RTIGFzIHdlbGwuICBJIHRoaW5rIHdoYXQg TW96aWxsYSBzZXR0bGVkIG9uIChhbmQgSSBkb24ndCByZW1lbWJlciB0aGUgQ2hyb21lIHNvbHV0 aW9uKSBpcyB0byB1c2UgYSBkaWZmZXJlbnQgc3RvcmFnZSBtZWNoYW5pc20gd2hlbiBIU1RTIGlz ICpzZXQqIGR1cmluZyBwcml2YXRlIGJyb3dzaW5nIG1vZGUsIGFuZCBjbGVhciBvbiBleGl0IGZy b20gcHJpdmF0ZSBicm93c2luZy4gIA0KDQpDbGVhcmluZyBoaXN0b3J5L2Nvb2tpZXMgb24gdGhl IGJyb3dzZXIgaXMgc2ltaWxhcmx5IHByb2JsZW1hdGljIGZvciBIU1RTIGFuZCBwaW5uaW5nLiAg VGhpcyBpcyB1bmZvcnR1bmF0ZSBpbiB0aGF0IHdlJ2QgcmVhbGx5IGxpa2UgaXQgdG8gYmUgaGFy ZCBmb3IgdXNlcnMgdG8gY2xlYXIgSFNUUyBzdGF0ZSBiZWNhdXNlIGl0IGlzICJnb29kIGZvciB0 aGVtIi4gIE5vdCBjbGVhciB3aGV0aGVyIHRoaXMgYmVsb25ncyBpbiB0aGUgc3BlYywgb3IgYSBz ZXQgb2YgaW1wbGVtZW50YXRpb24gZ3VpZGVsaW5lcy4gIEZvbGtzIGdvdCBzcXVlYW1pc2ggaGVy ZSBhYm91dCB0YWxraW5nIGFib3V0IGV4YWN0IFVBIGJlaGF2aW9yLCBldGMuDQoNClRoZXJlIGlz IGEgRmlyZWZveCBidWd6aWxsYSBidWcgYWJvdXQgdGhpcyBpc3N1ZSwgSSdsbCB0cnkgdG8gZ28g ZmluZCBpdCBhbmQgcG9zdCBiYWNrIGhlcmUgdW5sZXNzIHNvbWVvbmUgYmVhdHMgbWUgdG8gaXQu DQoNCi0gQW5keQ0KDQo= From cevans@google.com Tue Nov 8 19:59:59 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A403811E80D7 for ; Tue, 8 Nov 2011 19:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, 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 5LsJkLa3fc3W for ; Tue, 8 Nov 2011 19:59:58 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE84E21F8511 for ; Tue, 8 Nov 2011 19:59:58 -0800 (PST) Received: by ywt2 with SMTP id 2so1559173ywt.31 for ; Tue, 08 Nov 2011 19:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=5qsPdkB0wghE7O5iPiVfwLhcQejW1mq8UKhcF7QA3PU=; b=jAmkj4Zpj9aDmP8MGd3g2vDyOsiXKpWl8M4qaJZ/QBQddNmuXm1SSPBxtYMBboiRdH UbP7+fQjabrrfjZUR5Yg== Received: by 10.100.49.27 with SMTP id w27mr330259anw.134.1320811198150; Tue, 08 Nov 2011 19:59:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.49.27 with SMTP id w27mr330242anw.134.1320811197950; Tue, 08 Nov 2011 19:59:57 -0800 (PST) Received: by 10.150.227.6 with HTTP; Tue, 8 Nov 2011 19:59:57 -0800 (PST) In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEBED718018@DEN-MEXMS-001.corp.ebay.com> References: <5EE049BA3C6538409BBE6F1760F328ABEBED718018@DEN-MEXMS-001.corp.ebay.com> Date: Tue, 8 Nov 2011 19:59:57 -0800 Message-ID: From: Chris Evans To: "Steingruebl, Andy" Content-Type: multipart/alternative; boundary=001485f87bb044ece404b145521f X-System-Of-Record: true X-Mailman-Approved-At: Tue, 08 Nov 2011 21:35:43 -0800 Cc: Ian Fette , IETF WebSec WG , Wan-Teh Chang Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 04:00:18 -0000 --001485f87bb044ece404b145521f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 8, 2011 at 7:48 PM, Steingruebl, Andy < asteingruebl@paypal-inc.com> wrote: > > -----Original Message----- > > From: Chris Palmer > > > > > - There is no directive or suggestion to User Agents about saving or > > > not saving pins received in a private browsing mode. Maybe there > > > shouldn't be, but if a User-Agent does save them, the same 304/ETag > > > trick malicious sites use to track users can be created using certs > > > and subdomains. > > > > Yes, another person raised this concern, and it is real. I don't see a > way to > > resolve this problem; perhaps I am not smart enough, but I can't see a > way to > > have both dynamic pinning AND avoid this tracking attack. > > > > I am willing to add a paragraph about what browsers should do in private > > browsing mode, and I am willing to go either way on what the requirement > > should be. I don't know what is best. > > We battled this problem with HSTS as well. I think what Mozilla settled > on (and I don't remember the Chrome solution) is to use a different storage > mechanism when HSTS is *set* during private browsing mode, and clear on > exit from private browsing. > I recently fixed Chrome's behaviour here to be (barring regressions): - _New_ HSTS metadata encountered in incognito mode is saved in-memory for the duration of the incognito session, but never persisted to disk, or seen outside of the incognito windows. - Incognito mode _will_ use HSTS metadata that was already persisted to disk at the start of the incognito session. That seemed like a solid balance between the various privacy vs. security concerns. > Clearing history/cookies on the browser is similarly problematic for HSTS > and pinning. This is unfortunate in that we'd really like it to be hard > for users to clear HSTS state because it is "good for them". Not clear > whether this belongs in the spec, or a set of implementation guidelines. > Folks got squeamish here about talking about exact UA behavior, etc. > For Chrome, I believe it is tied to cookies: "Cookies and other site data". Last I talked with Sid at Firefox, they were thinking of splitting off cookies from other site data. I'm not sure where that went. It also gets complicated: is HTML5 database / indexed storage "cookies" or "other site data", etc. etc. I'd recommend we stay out of providing exact UA requirements here other than a "SHOULD" for providing _some_ user-friendly way to clear HSTS metadata. Realistically, it's a pretty small percentage of the browsing population that go in and fiddle with storage settings. Cheers Chris > There is a Firefox bugzilla bug about this issue, I'll try to go find it > and post back here unless someone beats me to it. > > - Andy > > --001485f87bb044ece404b145521f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 8, 2011 at 7:48 PM, Steingruebl, Andy <asteingruebl@paypal-inc.com= > wrote:
> -----Original Message-----
> From: =A0Chris Palmer


> > =A0- There is no directive or suggestion to User Agents about sav= ing or
> > not saving pins received in a private browsing mode. =A0Maybe the= re
> > shouldn't be, but if a User-Agent does save them, the same 30= 4/ETag
> > trick malicious sites use to track users can be created using cer= ts
> > and subdomains.
>
> Yes, another person raised this concern, and it is real. I don't s= ee a way to
> resolve this problem; perhaps I am not smart enough, but I can't s= ee a way to
> have both dynamic pinning AND avoid this tracking attack.
>
> I am willing to add a paragraph about what browsers should do in priva= te
> browsing mode, and I am willing to go either way on what the requireme= nt
> should be. I don't know what is best.

We battled this problem with HSTS as well. =A0I think what Mozilla se= ttled on (and I don't remember the Chrome solution) is to use a differe= nt storage mechanism when HSTS is *set* during private browsing mode, and c= lear on exit from private browsing.

I recently fixed Chrome's behaviour he= re to be (barring regressions):
- _New_ HSTS metadata encountered= in incognito mode is saved in-memory for the duration of the incognito ses= sion, but never persisted to disk, or seen outside of the incognito windows= .
- Incognito mode _will_ use HSTS metadata that was already persisted t= o disk at the start of the incognito session.

That= seemed like a solid balance between the various privacy vs. security conce= rns.


Clearing history/cookies on the browser is similarly problematic for HSTS a= nd pinning. =A0This is unfortunate in that we'd really like it to be ha= rd for users to clear HSTS state because it is "good for them". = =A0Not clear whether this belongs in the spec, or a set of implementation g= uidelines. =A0Folks got squeamish here about talking about exact UA behavio= r, etc.

For Chrome, I believe it is tied to cookie= s: "Cookies and other site data". Last I talked with Sid at Firef= ox, they were thinking of splitting off cookies from other site data. I'= ;m not sure where that went. It also gets complicated: is HTML5 database / = indexed storage "cookies" or "other site data", etc. et= c.

I'd recommend we stay out of providing exact UA req= uirements here other than a "SHOULD" for providing _some_ user-fr= iendly way to clear HSTS metadata. Realistically, it's a pretty small p= ercentage of the browsing population that go in and fiddle with storage set= tings.


Cheers
Chris


There is a Firefox bugzilla bug about this issue, I'll try to go find i= t and post back here unless someone beats me to it.

- Andy


--001485f87bb044ece404b145521f-- From ynir@checkpoint.com Tue Nov 8 23:14:41 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6FD11E80B7 for ; Tue, 8 Nov 2011 23:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.329 X-Spam-Level: X-Spam-Status: No, score=-10.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 1IB+cXSJ2Zw2 for ; Tue, 8 Nov 2011 23:14:41 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8425011E80A6 for ; Tue, 8 Nov 2011 23:14:38 -0800 (PST) X-CheckPoint: {4EBA27EA-10002-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pA97EZxg027971; Wed, 9 Nov 2011 09:14:35 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 9 Nov 2011 09:14:35 +0200 From: Yoav Nir To: Chris Palmer , IETF WebSec WG , Chris Evans Date: Wed, 9 Nov 2011 09:09:51 +0200 Thread-Topic: [websec] New draft of HTTP header-based public key pinning Thread-Index: AcyerzuuuvQwjO/0SpGPTGyha6W0Tw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ian Fette , Wan-Teh Chang Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 07:14:41 -0000 On 11/9/11 1:57 AM, "Chris Palmer" wrote: >Hi all, > >I tried to get this in by the deadline last week, but I had formatting >errors at the last minute (the draft name had changed to reflect its >non-HSTS nature, so the submission form rejected my version of -01! >Sigh), and then it cuts you off at 5:00 PST. Ah well. I've attached >the .txt form of the latest draft, and Ian Fette and Wan-Teh Chang >will be with you in Taipei. Only Ian has officially signed on to >represent this proposal at the meeting, though. Hi Chris. In case you don't know, the embargo on submitting drafts is lifted when IETF week starts, so that's next Monday, plenty of time before the meeting on Wednesday. I don't really understand the logic of this, but you can. Yoav From julian.reschke@gmx.de Wed Nov 9 00:34:52 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDDF21F8B4C for ; Wed, 9 Nov 2011 00:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.451 X-Spam-Level: X-Spam-Status: No, score=-104.451 tagged_above=-999 required=5 tests=[AWL=-1.852, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miMCs46JwUGu for ; Wed, 9 Nov 2011 00:34:51 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id C13C721F8B73 for ; Wed, 9 Nov 2011 00:34:50 -0800 (PST) Received: (qmail invoked by alias); 09 Nov 2011 08:34:48 -0000 Received: from p5DCCB151.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.177.81] by mail.gmx.net (mp057) with SMTP; 09 Nov 2011 09:34:48 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+pkhREJ1up9tEGGgi/XbgobQKhuiVN0z730lk0Q9 bI/rmRhO/Me8sv Message-ID: <4EBA3B24.5060602@gmx.de> Date: Wed, 09 Nov 2011 09:34:44 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Tom Ritter References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG , Chris Evans , Ian Fette , Wan-Teh Chang Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 08:34:52 -0000 On 2011-11-09 01:31, Tom Ritter wrote: > My notes: > > I believe the BNF (pseudo-BNF?) is incorrect: > > Public-Key-Pins = "Public-Key-Pins" ":" LWS directives > > directives = max-age LWS ";" LWS fingerprints > / fingerprints LWS ";" LWS max-age > > max-age = "max-age" LWS "=" LWS delta-seconds > > pins = "pins" LWS "=" LWS fingerprints > > fingerprints = fingerprint > / fingerprint "," fingerprints > > fingerprint = fp-type "-" base64-digits > > fp-type = "sha1" > / "sha256" > > I believe 'directives' should replace "fingerprints" with "pins": > > directives = max-age LWS ";" LWS pins > / pins LWS ";" LWS max-age > > ================ > ... By all means *please* consider re-using the syntax of an existing header field. In particular, please read So decide whether you want to allow multiple header fields (in which case you should use the ABNF list notation used in 2616/HTTPbis), *or* define the syntax so that a "," introduced by header field recombination can be detected by recipients. Best regards, Julian From ietf@adambarth.com Wed Nov 9 01:21:02 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806B721F8B5B for ; Wed, 9 Nov 2011 01:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.474, 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 MJCOI2GyHGl9 for ; Wed, 9 Nov 2011 01:21:01 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8151221F8B59 for ; Wed, 9 Nov 2011 01:21:01 -0800 (PST) Received: by iaeo4 with SMTP id o4so1981027iae.31 for ; Wed, 09 Nov 2011 01:21:00 -0800 (PST) Received: by 10.42.197.195 with SMTP id el3mr1434743icb.54.1320830460120; Wed, 09 Nov 2011 01:21:00 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id p16sm6082240ibk.6.2011.11.09.01.20.58 (version=SSLv3 cipher=OTHER); Wed, 09 Nov 2011 01:20:58 -0800 (PST) Received: by iaeo4 with SMTP id o4so1980995iae.31 for ; Wed, 09 Nov 2011 01:20:58 -0800 (PST) Received: by 10.231.73.196 with SMTP id r4mr360822ibj.19.1320830458131; Wed, 09 Nov 2011 01:20:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.50.14 with HTTP; Wed, 9 Nov 2011 01:20:27 -0800 (PST) In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEBED718018@DEN-MEXMS-001.corp.ebay.com> References: <5EE049BA3C6538409BBE6F1760F328ABEBED718018@DEN-MEXMS-001.corp.ebay.com> From: Adam Barth Date: Wed, 9 Nov 2011 01:20:27 -0800 Message-ID: To: "Steingruebl, Andy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Chris Evans , IETF WebSec WG , Ian Fette , Wan-Teh Chang Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 09:21:02 -0000 On Tue, Nov 8, 2011 at 7:48 PM, Steingruebl, Andy wrote: >> -----Original Message----- >> From: =A0Chris Palmer >> > =A0- There is no directive or suggestion to User Agents about saving o= r >> > not saving pins received in a private browsing mode. =A0Maybe there >> > shouldn't be, but if a User-Agent does save them, the same 304/ETag >> > trick malicious sites use to track users can be created using certs >> > and subdomains. >> >> Yes, another person raised this concern, and it is real. I don't see a w= ay to >> resolve this problem; perhaps I am not smart enough, but I can't see a w= ay to >> have both dynamic pinning AND avoid this tracking attack. >> >> I am willing to add a paragraph about what browsers should do in private >> browsing mode, and I am willing to go either way on what the requirement >> should be. I don't know what is best. > > We battled this problem with HSTS as well. =A0I think what Mozilla settle= d on (and I don't remember the Chrome solution) is to use a different stora= ge mechanism when HSTS is *set* during private browsing mode, and clear on = exit from private browsing. It's been a while since I wrote that code, but I'm pretty sure that's how it works in Chrome too. There's a separate memory-only HSTS store that's used for incognito. That's consistent with how we handle other host-specific data stored by the network layer, such as cookies. Adam > Clearing history/cookies on the browser is similarly problematic for HSTS= and pinning. =A0This is unfortunate in that we'd really like it to be hard= for users to clear HSTS state because it is "good for them". =A0Not clear = whether this belongs in the spec, or a set of implementation guidelines. = =A0Folks got squeamish here about talking about exact UA behavior, etc. > > There is a Firefox bugzilla bug about this issue, I'll try to go find it = and post back here unless someone beats me to it. > > - Andy > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From asteingruebl@paypal-inc.com Wed Nov 9 08:38:19 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC0C21F8A7E for ; Wed, 9 Nov 2011 08:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 6hRoKdSfgMEK for ; Wed, 9 Nov 2011 08:38:15 -0800 (PST) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id 1570C21F8ADC for ; Wed, 9 Nov 2011 08:38:15 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=RbcC+f9ZktUtZsaLEI0mlyKwTvqOM/rBhLOBXDJHV0xOtK6cX458EuLM JtcXosRPI94HQIc/hLIR1S3+bulE3ryYxJ9Gnd4JFugLSlAOqRzb5Ym0U 8ZuE2NPkR5Qt0gU; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1320856695; x=1352392695; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=E84OurJE/o7CZ5mkHN/x6vQhcUn7b3OPhzMkMNAEOWg=; b=NgUXA5gNT2nKgMIHHe6mmfmIJcW7CvW2eoyHVG6W50Fem4caF9ZWLVbz dV2HhLqgjDVMcJt2Rf0601VGADZ+RkhjBkQDPDJi4JrG9kTVGAuPwVcRO WArJfAa4u+nLsNV; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.69,484,1315206000"; d="scan'208";a="4105835" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 09 Nov 2011 08:38:15 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([192.101.150.21]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Wed, 9 Nov 2011 09:38:14 -0700 From: "Steingruebl, Andy" To: Adam Barth Date: Wed, 9 Nov 2011 09:38:13 -0700 Thread-Topic: [websec] New draft of HTTP header-based public key pinning Thread-Index: AcyewQpRTroclxM/R2ip3xP77iZtBQAPMB6w Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEBED718198@DEN-MEXMS-001.corp.ebay.com> References: <5EE049BA3C6538409BBE6F1760F328ABEBED718018@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: u6bst9XfLv/9kO+SEhES+g== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: Chris Evans , IETF WebSec WG , Ian Fette , Wan-Teh Chang Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 16:38:19 -0000 > -----Original Message----- > From: Adam Barth [mailto:ietf@adambarth.com] > > We battled this problem with HSTS as well. =A0I think what Mozilla sett= led on > (and I don't remember the Chrome solution) is to use a different storage > mechanism when HSTS is *set* during private browsing mode, and clear on > exit from private browsing. >=20 > It's been a while since I wrote that code, but I'm pretty sure that's how= it > works in Chrome too. There's a separate memory-only HSTS store that's > used for incognito. That's consistent with how we handle other host-spec= ific > data stored by the network layer, such as cookies. Is this documented anywhere? Where should it be? Maybe add a section to t= he browser security handbook, if nowhere else, so at least we all have it w= ritten down what the browsers have implemented? And, since we decided these specifics don't belong in the IETF HSTS spec, = where could we document them for real? - Andy From ietf@adambarth.com Wed Nov 9 09:03:54 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9AB11E8083 for ; Wed, 9 Nov 2011 09:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.453, 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 UFb+wylShn3v for ; Wed, 9 Nov 2011 09:03:53 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59E2221F8C70 for ; Wed, 9 Nov 2011 09:03:53 -0800 (PST) Received: by iaeo4 with SMTP id o4so2498443iae.31 for ; Wed, 09 Nov 2011 09:03:53 -0800 (PST) Received: by 10.42.19.195 with SMTP id d3mr3922801icb.21.1320858232981; Wed, 09 Nov 2011 09:03:52 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id l28sm7601277ibc.3.2011.11.09.09.03.50 (version=SSLv3 cipher=OTHER); Wed, 09 Nov 2011 09:03:50 -0800 (PST) Received: by iaeo4 with SMTP id o4so2498380iae.31 for ; Wed, 09 Nov 2011 09:03:50 -0800 (PST) Received: by 10.231.73.196 with SMTP id r4mr933426ibj.19.1320858230092; Wed, 09 Nov 2011 09:03:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.50.14 with HTTP; Wed, 9 Nov 2011 09:03:19 -0800 (PST) In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEBED718198@DEN-MEXMS-001.corp.ebay.com> References: <5EE049BA3C6538409BBE6F1760F328ABEBED718018@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEBED718198@DEN-MEXMS-001.corp.ebay.com> From: Adam Barth Date: Wed, 9 Nov 2011 09:03:19 -0800 Message-ID: To: "Steingruebl, Andy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Chris Evans , IETF WebSec WG , Ian Fette , Wan-Teh Chang Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 17:03:54 -0000 On Wed, Nov 9, 2011 at 8:38 AM, Steingruebl, Andy wrote: >> -----Original Message----- >> From: Adam Barth [mailto:ietf@adambarth.com] >> > We battled this problem with HSTS as well. =A0I think what Mozilla set= tled on >> (and I don't remember the Chrome solution) is to use a different storage >> mechanism when HSTS is *set* during private browsing mode, and clear on >> exit from private browsing. >> >> It's been a while since I wrote that code, but I'm pretty sure that's ho= w it >> works in Chrome too. =A0There's a separate memory-only HSTS store that's >> used for incognito. =A0That's consistent with how we handle other host-s= pecific >> data stored by the network layer, such as cookies. > > Is this documented anywhere? =A0Where should it be? =A0Maybe add a sectio= n to the browser security handbook, if nowhere else, so at least we all hav= e it written down what the browsers have implemented? I don't believe it's documented anywhere. > And, since we decided these specifics don't belong in the IETF =A0HSTS sp= ec, where could we document them for real? Typically, incognito mode hasn't been standardized anywhere. The general concept is that it should follow all the other standards, but act as a short-lived user agent. For example, you can imagine that the user agent is created when the user enters incognito and destroyed when the user leaves incognito. If we were to standardize the mode, we'd probably do it in a working group similar to http://www.w3.org/2006/WSC/. However, I'm not sure how much interest there is around that task. Adam From stpeter@stpeter.im Wed Nov 9 09:29:16 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A35721F8C2A for ; Wed, 9 Nov 2011 09:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vffzY6zTC9ch for ; Wed, 9 Nov 2011 09:29:12 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 19B9721F8C30 for ; Wed, 9 Nov 2011 09:29:12 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1B7DC404FF; Wed, 9 Nov 2011 10:35:08 -0700 (MST) Message-ID: <4EBAB866.2020209@stpeter.im> Date: Wed, 09 Nov 2011 10:29:10 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Tobias Gondrom References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> <4EA6143D.8060009@it.aoyama.ac.jp> <4EA65768.60205@it.aoyama.ac.jp> <4EA65A59.6010005@gondrom.org> In-Reply-To: <4EA65A59.6010005@gondrom.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: websec@ietf.org Subject: Re: [websec] font sniffing X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 17:29:16 -0000 On 10/25/11 12:42 AM, Tobias Gondrom wrote: > On 25/10/11 07:30, "Martin J. Dürst" wrote: >> On 2011/10/25 11:34, Anne van Kesteren wrote: >>> On Tue, 25 Oct 2011 10:43:25 +0900, Martin J. Dürst >>> wrote: >>>>> But who is at fault is not what we are interested in here I think. We >>>>> are interested in defining when implementations have to sniff. They >>>>> very >>>>> much have to sniff for fonts. >>>> >>>> Yes. If somebody has enough energy, it would still make sense to >>>> register font types. >>> >>> Because..? >> >> - Font formats, as well as other Mime types, are not only used by Web >> browsers. >> - There may be new formats, for which no sniffing is done yet. >> - Servers may prefer to declare what they are sending out rather than >> to be silent about it, even if not all clients use that information. >> - Once we have registered types, sniffing could in the long term maybe >> even go away. >> >> Regards, Martin. > +1 for that. Based on discussion here and at the W3C TPAC last week, I raised this issue on the apps-discuss list: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03447.html The immediate reaction was: "do you mean fonts or typefaces?" Before taking on this work, it would be helpful to understand exactly what typographic entities are being sent around by browsers and other applications. Peter -- Peter Saint-Andre https://stpeter.im/ From ietf@adambarth.com Wed Nov 9 09:31:12 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E85911E8083 for ; Wed, 9 Nov 2011 09:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.434, 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 pND1BbakEXrB for ; Wed, 9 Nov 2011 09:31:08 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3C921F8BE8 for ; Wed, 9 Nov 2011 09:31:08 -0800 (PST) Received: by iaeo4 with SMTP id o4so2533072iae.31 for ; Wed, 09 Nov 2011 09:31:08 -0800 (PST) Received: by 10.50.12.231 with SMTP id b7mr4276637igc.8.1320859867991; Wed, 09 Nov 2011 09:31:07 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id p16sm7667719ibk.6.2011.11.09.09.31.06 (version=SSLv3 cipher=OTHER); Wed, 09 Nov 2011 09:31:06 -0800 (PST) Received: by iaeo4 with SMTP id o4so2533034iae.31 for ; Wed, 09 Nov 2011 09:31:06 -0800 (PST) Received: by 10.231.62.75 with SMTP id w11mr969195ibh.6.1320859866126; Wed, 09 Nov 2011 09:31:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.50.14 with HTTP; Wed, 9 Nov 2011 09:30:35 -0800 (PST) In-Reply-To: <4EBAB866.2020209@stpeter.im> References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> <4EA6143D.8060009@it.aoyama.ac.jp> <4EA65768.60205@it.aoyama.ac.jp> <4EA65A59.6010005@gondrom.org> <4EBAB866.2020209@stpeter.im> From: Adam Barth Date: Wed, 9 Nov 2011 09:30:35 -0800 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] font sniffing X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 17:31:12 -0000 On Wed, Nov 9, 2011 at 9:29 AM, Peter Saint-Andre wrot= e: > On 10/25/11 12:42 AM, Tobias Gondrom wrote: >> >> On 25/10/11 07:30, "Martin J. D=FCrst" wrote: >>> >>> On 2011/10/25 11:34, Anne van Kesteren wrote: >>>> >>>> On Tue, 25 Oct 2011 10:43:25 +0900, Martin J. D=FCrst >>>> wrote: >>>>>> >>>>>> But who is at fault is not what we are interested in here I think. W= e >>>>>> are interested in defining when implementations have to sniff. They >>>>>> very >>>>>> much have to sniff for fonts. >>>>> >>>>> Yes. If somebody has enough energy, it would still make sense to >>>>> register font types. >>>> >>>> Because..? >>> >>> - Font formats, as well as other Mime types, are not only used by Web >>> browsers. >>> - There may be new formats, for which no sniffing is done yet. >>> - Servers may prefer to declare what they are sending out rather than >>> to be silent about it, even if not all clients use that information. >>> - Once we have registered types, sniffing could in the long term maybe >>> even go away. >>> >>> Regards, =A0 Martin. >> >> +1 for that. > > Based on discussion here and at the W3C TPAC last week, I raised this iss= ue > on the apps-discuss list: > > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03447.html > > The immediate reaction was: "do you mean fonts or typefaces?" > > Before taking on this work, it would be helpful to understand exactly wha= t > typographic entities are being sent around by browsers and other > applications. Mechanically, resource representations that might get shoved into @font-face rules. Adam From stpeter@stpeter.im Wed Nov 9 09:40:03 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F06221F8C39 for ; Wed, 9 Nov 2011 09:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wWafKGA++ta for ; Wed, 9 Nov 2011 09:39:58 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D994C21F8C34 for ; Wed, 9 Nov 2011 09:39:58 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E4DB341FC7; Wed, 9 Nov 2011 10:45:54 -0700 (MST) Message-ID: <4EBABAEC.6000907@stpeter.im> Date: Wed, 09 Nov 2011 10:39:56 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Adam Barth References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> <4EA6143D.8060009@it.aoyama.ac.jp> <4EA65768.60205@it.aoyama.ac.jp> <4EA65A59.6010005@gondrom.org> <4EBAB866.2020209@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: websec@ietf.org Subject: Re: [websec] font sniffing X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 17:40:03 -0000 On 11/9/11 10:30 AM, Adam Barth wrote: > On Wed, Nov 9, 2011 at 9:29 AM, Peter Saint-Andre wrote: >> On 10/25/11 12:42 AM, Tobias Gondrom wrote: >>> >>> On 25/10/11 07:30, "Martin J. Dürst" wrote: >>>> >>>> On 2011/10/25 11:34, Anne van Kesteren wrote: >>>>> >>>>> On Tue, 25 Oct 2011 10:43:25 +0900, Martin J. Dürst >>>>> wrote: >>>>>>> >>>>>>> But who is at fault is not what we are interested in here I think. We >>>>>>> are interested in defining when implementations have to sniff. They >>>>>>> very >>>>>>> much have to sniff for fonts. >>>>>> >>>>>> Yes. If somebody has enough energy, it would still make sense to >>>>>> register font types. >>>>> >>>>> Because..? >>>> >>>> - Font formats, as well as other Mime types, are not only used by Web >>>> browsers. >>>> - There may be new formats, for which no sniffing is done yet. >>>> - Servers may prefer to declare what they are sending out rather than >>>> to be silent about it, even if not all clients use that information. >>>> - Once we have registered types, sniffing could in the long term maybe >>>> even go away. >>>> >>>> Regards, Martin. >>> >>> +1 for that. >> >> Based on discussion here and at the W3C TPAC last week, I raised this issue >> on the apps-discuss list: >> >> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03447.html >> >> The immediate reaction was: "do you mean fonts or typefaces?" >> >> Before taking on this work, it would be helpful to understand exactly what >> typographic entities are being sent around by browsers and other >> applications. > > Mechanically, resource representations that might get shoved into > @font-face rules. Based on Anne's previous message to this list [1], it seems that we're actually talking about font representation formats (his examples are TrueType Collection, OpenType, TrueType, and Web Open Font Format) instead of particular fonts (e.g., "12pt Georgia Bold Italic") or typefaces (e.g., "Georgia"). Correct? /psa [1] http://www.ietf.org/mail-archive/web/websec/current/msg00235.html From annevk@opera.com Wed Nov 9 09:42:56 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5D221F8C47 for ; Wed, 9 Nov 2011 09:42:56 -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 ivkPnZsCwJH1 for ; Wed, 9 Nov 2011 09:42:55 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 532C421F8C41 for ; Wed, 9 Nov 2011 09:42:55 -0800 (PST) Received: from annevk-macbookpro.local (c-98-210-155-154.hsd1.ca.comcast.net [98.210.155.154]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pA9HgmYY013740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Nov 2011 17:42:51 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Adam Barth" , "Peter Saint-Andre" References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> <4EA6143D.8060009@it.aoyama.ac.jp> <4EA65768.60205@it.aoyama.ac.jp> <4EA65A59.6010005@gondrom.org> <4EBAB866.2020209@stpeter.im> <4EBABAEC.6000907@stpeter.im> Date: Wed, 09 Nov 2011 09:42:47 -0800 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Anne van Kesteren" Organization: Opera Software Message-ID: In-Reply-To: <4EBABAEC.6000907@stpeter.im> User-Agent: Opera Mail/11.52 (MacIntel) Cc: websec@ietf.org Subject: Re: [websec] font sniffing X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 17:42:56 -0000 On Wed, 09 Nov 2011 09:39:56 -0800, Peter Saint-Andre wrote: > Based on Anne's previous message to this list [1], it seems that we're > actually talking about font representation formats (his examples are > TrueType Collection, OpenType, TrueType, and Web Open Font Format) > instead of particular fonts (e.g., "12pt Georgia Bold Italic") or > typefaces (e.g., "Georgia"). > > Correct? Yes. Font formats, not font families. > [1] http://www.ietf.org/mail-archive/web/websec/current/msg00235.html -- Anne van Kesteren http://annevankesteren.nl/ From stpeter@stpeter.im Wed Nov 9 09:44:24 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7519821F8C65 for ; Wed, 9 Nov 2011 09:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz9WeSAcpHQr for ; Wed, 9 Nov 2011 09:44:23 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C4A3C21F8C5C for ; Wed, 9 Nov 2011 09:44:23 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D667F41FC7; Wed, 9 Nov 2011 10:50:19 -0700 (MST) Message-ID: <4EBABBF6.4060009@stpeter.im> Date: Wed, 09 Nov 2011 10:44:22 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Anne van Kesteren References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> <4EA6143D.8060009@it.aoyama.ac.jp> <4EA65768.60205@it.aoyama.ac.jp> <4EA65A59.6010005@gondrom.org> <4EBAB866.2020209@stpeter.im> <4EBABAEC.6000907@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] font sniffing X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 17:44:24 -0000 On 11/9/11 10:42 AM, Anne van Kesteren wrote: > On Wed, 09 Nov 2011 09:39:56 -0800, Peter Saint-Andre > wrote: >> Based on Anne's previous message to this list [1], it seems that we're >> actually talking about font representation formats (his examples are >> TrueType Collection, OpenType, TrueType, and Web Open Font Format) >> instead of particular fonts (e.g., "12pt Georgia Bold Italic") or >> typefaces (e.g., "Georgia"). >> >> Correct? > > Yes. Font formats, not font families. Thanks for the clarification. That makes like much easier. :) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Nov 9 09:45:56 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9459721F8C67 for ; Wed, 9 Nov 2011 09:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd6O0OEVTR6t for ; Wed, 9 Nov 2011 09:45:56 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED1921F8C65 for ; Wed, 9 Nov 2011 09:45:56 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 67BA541FC7; Wed, 9 Nov 2011 10:51:52 -0700 (MST) Message-ID: <4EBABC53.4060505@stpeter.im> Date: Wed, 09 Nov 2011 10:45:55 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Anne van Kesteren References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> <4EA6143D.8060009@it.aoyama.ac.jp> <4EA65768.60205@it.aoyama.ac.jp> <4EA65A59.6010005@gondrom.org> <4EBAB866.2020209@stpeter.im> <4EBABAEC.6000907@stpeter.im> <4EBABBF6.4060009@stpeter.im> In-Reply-To: <4EBABBF6.4060009@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] font sniffing X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 17:45:56 -0000 On 11/9/11 10:44 AM, Peter Saint-Andre wrote: > On 11/9/11 10:42 AM, Anne van Kesteren wrote: >> On Wed, 09 Nov 2011 09:39:56 -0800, Peter Saint-Andre >> wrote: >>> Based on Anne's previous message to this list [1], it seems that we're >>> actually talking about font representation formats (his examples are >>> TrueType Collection, OpenType, TrueType, and Web Open Font Format) >>> instead of particular fonts (e.g., "12pt Georgia Bold Italic") or >>> typefaces (e.g., "Georgia"). >>> >>> Correct? >> >> Yes. Font formats, not font families. > > Thanks for the clarification. That makes like much easier. :) s/like/life/ There's still the general question of how useful it would be to define either a top-level content type or subtypes like application/woff, but at least we've constrained the problem space quite a bit here... /psa From paul.hoffman@vpnc.org Wed Nov 9 10:04:35 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2E021F8C78 for ; Wed, 9 Nov 2011 10:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIdsy1OUwl+5 for ; Wed, 9 Nov 2011 10:04:35 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 103AB21F8C6B for ; Wed, 9 Nov 2011 10:04:35 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pA9I4WcP002859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2011 11:04:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Wed, 9 Nov 2011 10:04:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0C1B01C9-5D98-4F0C-B5CF-E5F4CEEF864A@vpnc.org> References: <5EE049BA3C6538409BBE6F1760F328ABEBED718018@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEBED718198@DEN-MEXMS-001.corp.ebay.com> To: Adam Barth X-Mailer: Apple Mail (2.1251.1) Cc: IETF WebSec WG Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 18:04:35 -0000 On Nov 9, 2011, at 9:03 AM, Adam Barth wrote: > On Wed, Nov 9, 2011 at 8:38 AM, Steingruebl, Andy > wrote: >>> -----Original Message----- >>> From: Adam Barth [mailto:ietf@adambarth.com] >>>> We battled this problem with HSTS as well. I think what Mozilla = settled on >>> (and I don't remember the Chrome solution) is to use a different = storage >>> mechanism when HSTS is *set* during private browsing mode, and clear = on >>> exit from private browsing. >>>=20 >>> It's been a while since I wrote that code, but I'm pretty sure = that's how it >>> works in Chrome too. There's a separate memory-only HSTS store = that's >>> used for incognito. That's consistent with how we handle other = host-specific >>> data stored by the network layer, such as cookies. >>=20 >> Is this documented anywhere? Where should it be? Maybe add a = section to the browser security handbook, if nowhere else, so at least = we all have it written down what the browsers have implemented? >=20 > I don't believe it's documented anywhere. >=20 >> And, since we decided these specifics don't belong in the IETF HSTS = spec, where could we document them for real? >=20 > Typically, incognito mode hasn't been standardized anywhere. The > general concept is that it should follow all the other standards, but > act as a short-lived user agent. For example, you can imagine that > the user agent is created when the user enters incognito and destroyed > when the user leaves incognito. >=20 > If we were to standardize the mode, we'd probably do it in a working > group similar to http://www.w3.org/2006/WSC/. However, I'm not sure > how much interest there is around that task. Another option is a short Internet Draft that would become an = independent submission RFC that says "here is how a few browser vendors = define the problem and solve it, at the time that this is published". = That is *exactly* what the independent submission RFCs are good for. No = wide IETF review, no need to listen to anyone who thinks you should do = it differently; just "here is what we do, and why". --Paul Hoffman From ietf@adambarth.com Wed Nov 9 10:14:34 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7605811E8085 for ; Wed, 9 Nov 2011 10:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.417, 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 6Fy8svqjYZ4B for ; Wed, 9 Nov 2011 10:14:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC4EF11E8083 for ; Wed, 9 Nov 2011 10:14:33 -0800 (PST) Received: by iaeo4 with SMTP id o4so2583859iae.31 for ; Wed, 09 Nov 2011 10:14:33 -0800 (PST) Received: by 10.42.158.9 with SMTP id f9mr4321443icx.31.1320862472663; Wed, 09 Nov 2011 10:14:32 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id dd36sm7797068ibb.7.2011.11.09.10.14.27 (version=SSLv3 cipher=OTHER); Wed, 09 Nov 2011 10:14:27 -0800 (PST) Received: by iaeo4 with SMTP id o4so2583716iae.31 for ; Wed, 09 Nov 2011 10:14:27 -0800 (PST) Received: by 10.231.73.196 with SMTP id r4mr1014110ibj.19.1320862467097; Wed, 09 Nov 2011 10:14:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.50.14 with HTTP; Wed, 9 Nov 2011 10:13:56 -0800 (PST) In-Reply-To: <4EBABAEC.6000907@stpeter.im> References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> <4EA6143D.8060009@it.aoyama.ac.jp> <4EA65768.60205@it.aoyama.ac.jp> <4EA65A59.6010005@gondrom.org> <4EBAB866.2020209@stpeter.im> <4EBABAEC.6000907@stpeter.im> From: Adam Barth Date: Wed, 9 Nov 2011 10:13:56 -0800 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] font sniffing X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 18:14:34 -0000 On Wed, Nov 9, 2011 at 9:39 AM, Peter Saint-Andre wrot= e: > On 11/9/11 10:30 AM, Adam Barth wrote: >> >> On Wed, Nov 9, 2011 at 9:29 AM, Peter Saint-Andre >> =A0wrote: >>> >>> On 10/25/11 12:42 AM, Tobias Gondrom wrote: >>>> >>>> On 25/10/11 07:30, "Martin J. D=FCrst" wrote: >>>>> >>>>> On 2011/10/25 11:34, Anne van Kesteren wrote: >>>>>> >>>>>> On Tue, 25 Oct 2011 10:43:25 +0900, Martin J. D=FCrst >>>>>> =A0wrote: >>>>>>>> >>>>>>>> But who is at fault is not what we are interested in here I think. >>>>>>>> We >>>>>>>> are interested in defining when implementations have to sniff. The= y >>>>>>>> very >>>>>>>> much have to sniff for fonts. >>>>>>> >>>>>>> Yes. If somebody has enough energy, it would still make sense to >>>>>>> register font types. >>>>>> >>>>>> Because..? >>>>> >>>>> - Font formats, as well as other Mime types, are not only used by Web >>>>> browsers. >>>>> - There may be new formats, for which no sniffing is done yet. >>>>> - Servers may prefer to declare what they are sending out rather than >>>>> to be silent about it, even if not all clients use that information. >>>>> - Once we have registered types, sniffing could in the long term mayb= e >>>>> even go away. >>>>> >>>>> Regards, =A0 Martin. >>>> >>>> +1 for that. >>> >>> Based on discussion here and at the W3C TPAC last week, I raised this >>> issue >>> on the apps-discuss list: >>> >>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03447.html >>> >>> The immediate reaction was: "do you mean fonts or typefaces?" >>> >>> Before taking on this work, it would be helpful to understand exactly >>> what >>> typographic entities are being sent around by browsers and other >>> applications. >> >> Mechanically, resource representations that might get shoved into >> @font-face rules. > > Based on Anne's previous message to this list [1], it seems that we're > actually talking about font representation formats (his examples are > TrueType Collection, OpenType, TrueType, and Web Open Font Format) instea= d > of particular fonts (e.g., "12pt Georgia Bold Italic") or typefaces (e.g.= , > "Georgia"). > > Correct? Yep. Adam From ietf@adambarth.com Wed Nov 9 10:16:00 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631EC21F86C3 for ; Wed, 9 Nov 2011 10:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.401, 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 k8o5B+IiTQla for ; Wed, 9 Nov 2011 10:15:59 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94BBA21F8678 for ; Wed, 9 Nov 2011 10:15:59 -0800 (PST) Received: by iaeo4 with SMTP id o4so2585585iae.31 for ; Wed, 09 Nov 2011 10:15:59 -0800 (PST) Received: by 10.42.197.195 with SMTP id el3mr4245946icb.54.1320862559045; Wed, 09 Nov 2011 10:15:59 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id z10sm7791223ibv.9.2011.11.09.10.15.58 (version=SSLv3 cipher=OTHER); Wed, 09 Nov 2011 10:15:58 -0800 (PST) Received: by iaeo4 with SMTP id o4so2585557iae.31 for ; Wed, 09 Nov 2011 10:15:57 -0800 (PST) Received: by 10.231.24.160 with SMTP id v32mr1014529ibb.45.1320862557619; Wed, 09 Nov 2011 10:15:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.50.14 with HTTP; Wed, 9 Nov 2011 10:15:26 -0800 (PST) In-Reply-To: <0C1B01C9-5D98-4F0C-B5CF-E5F4CEEF864A@vpnc.org> References: <5EE049BA3C6538409BBE6F1760F328ABEBED718018@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEBED718198@DEN-MEXMS-001.corp.ebay.com> <0C1B01C9-5D98-4F0C-B5CF-E5F4CEEF864A@vpnc.org> From: Adam Barth Date: Wed, 9 Nov 2011 10:15:26 -0800 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 18:16:00 -0000 On Wed, Nov 9, 2011 at 10:04 AM, Paul Hoffman wrote= : > On Nov 9, 2011, at 9:03 AM, Adam Barth wrote: >> On Wed, Nov 9, 2011 at 8:38 AM, Steingruebl, Andy >> wrote: >>>> -----Original Message----- >>>> From: Adam Barth [mailto:ietf@adambarth.com] >>>>> We battled this problem with HSTS as well. =A0I think what Mozilla se= ttled on >>>> (and I don't remember the Chrome solution) is to use a different stora= ge >>>> mechanism when HSTS is *set* during private browsing mode, and clear o= n >>>> exit from private browsing. >>>> >>>> It's been a while since I wrote that code, but I'm pretty sure that's = how it >>>> works in Chrome too. =A0There's a separate memory-only HSTS store that= 's >>>> used for incognito. =A0That's consistent with how we handle other host= -specific >>>> data stored by the network layer, such as cookies. >>> >>> Is this documented anywhere? =A0Where should it be? =A0Maybe add a sect= ion to the browser security handbook, if nowhere else, so at least we all h= ave it written down what the browsers have implemented? >> >> I don't believe it's documented anywhere. >> >>> And, since we decided these specifics don't belong in the IETF =A0HSTS = spec, where could we document them for real? >> >> Typically, incognito mode hasn't been standardized anywhere. =A0The >> general concept is that it should follow all the other standards, but >> act as a short-lived user agent. =A0For example, you can imagine that >> the user agent is created when the user enters incognito and destroyed >> when the user leaves incognito. >> >> If we were to standardize the mode, we'd probably do it in a working >> group similar to http://www.w3.org/2006/WSC/. =A0However, I'm not sure >> how much interest there is around that task. > > Another option is a short Internet Draft that would become an independent= submission RFC that says "here is how a few browser vendors define the pro= blem and solve it, at the time that this is published". That is *exactly* w= hat the independent submission RFCs are good for. No wide IETF review, no n= eed to listen to anyone who thinks you should do it differently; just "here= is what we do, and why". That sounds like a reasonable plan. Collin Jackson has written up a detailed analysis of the current state of affairs in this paper: http://www.collinjackson.com/research/private-browsing.pdf Adam From palmer@google.com Wed Nov 9 12:10:00 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C881F0C4C for ; Wed, 9 Nov 2011 12:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.727 X-Spam-Level: X-Spam-Status: No, score=-103.727 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 2K-Rdr8M8j3h for ; Wed, 9 Nov 2011 12:09:58 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2B8E1F0C59 for ; Wed, 9 Nov 2011 12:09:56 -0800 (PST) Received: by wyf28 with SMTP id 28so113928wyf.31 for ; Wed, 09 Nov 2011 12:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record; bh=QiDQaIXK1eEiZJs9htQW1prmgyctrtYx0TLggSc29mc=; b=IsmFVscLEb4clbnSfpuhUHkyB9pCynu9eFclYwe8UTSMTVITVLPOONo8W+P1GW/56A qMz1sbysFGYqtXkU2nvg== Received: by 10.216.138.29 with SMTP id z29mr68462wei.4.1320869392625; Wed, 09 Nov 2011 12:09:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.138.29 with SMTP id z29mr68457wei.4.1320869392462; Wed, 09 Nov 2011 12:09:52 -0800 (PST) Received: by 10.216.216.205 with HTTP; Wed, 9 Nov 2011 12:09:52 -0800 (PST) In-Reply-To: <4EBA3B24.5060602@gmx.de> References: <4EBA3B24.5060602@gmx.de> Date: Wed, 9 Nov 2011 12:09:52 -0800 Message-ID: From: Chris Palmer To: IETF WebSec WG Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:10:00 -0000 On Wed, Nov 9, 2011 at 12:34 AM, Julian Reschke wrote: > > > So decide whether you want to allow multiple header fields (in which case > you should use the ABNF list notation used in 2616/HTTPbis), *or* define the > syntax so that a "," introduced by header field recombination can be > detected by recipients. I'm sorry, I don't know what you mean by "a ',' introduced by header field recombination". What grammar do you prefer? From julian.reschke@gmx.de Wed Nov 9 12:25:03 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FED1F0C77 for ; Wed, 9 Nov 2011 12:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.424 X-Spam-Level: X-Spam-Status: No, score=-104.424 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E12+aADo1V5u for ; Wed, 9 Nov 2011 12:25:02 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2E9F21F0C53 for ; Wed, 9 Nov 2011 12:25:01 -0800 (PST) Received: (qmail invoked by alias); 09 Nov 2011 20:25:00 -0000 Received: from p5DCC32E8.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.50.232] by mail.gmx.net (mp066) with SMTP; 09 Nov 2011 21:25:00 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18AyHsPKzsAuHu9Y0DIvVUacWXx26zvz4S1C9pBoO 3EYtaqBLttRxuY Message-ID: <4EBAE198.3020406@gmx.de> Date: Wed, 09 Nov 2011 21:24:56 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Chris Palmer References: <4EBA3B24.5060602@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:25:03 -0000 On 2011-11-09 21:09, Chris Palmer wrote: > On Wed, Nov 9, 2011 at 12:34 AM, Julian Reschke wrote: > >> >> >> So decide whether you want to allow multiple header fields (in which case >> you should use the ABNF list notation used in 2616/HTTPbis), *or* define the >> syntax so that a "," introduced by header field recombination can be >> detected by recipients. > > I'm sorry, I don't know what you mean by "a ',' introduced by header > field recombination". > What grammar do you prefer? I would recommend a syntax that uses a single delimiter. If you use ";", you'd be able to detect the case mentioned above. If you use ",", you could support multiple header fields (if this is desired). By using both however, you gain nothing (IHMO), and create potential problems. Let's assume it's ";". In that case I would write: directives = max-age LWS *( ";" LWS [ fingerprint ] ) thus require max-age to be always first (your grammar allows it at the beginning and at the end, but not inbetween; this is likely to cause confusion. Then make fingerprint a proper name/value pair, as in other HTTP parameters, and put the name of the hash into the parameter name. So instead of Public-Key-Pins: max-age=31536000; pins=sha1-4n972HfV354KP560yw4uqe/baXc=, sha256-LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ= you'd have Public-Key-Pins: max-age=31536000; pins-sha1=4n972HfV354KP560yw4uqe/baXc=; pins-sha256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ= Finally, allow quoted-string notation, Public-Key-Pins: max-age=31536000; pins-sha1="4n972HfV354KP560yw4uqe/baXc="; pins-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=" so that characters not allowed (such as "/") in HTTP tokens work. Best regards, Julian Best regards, Julian From palmer@google.com Wed Nov 9 13:28:34 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7169721F869E for ; Wed, 9 Nov 2011 13:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.577 X-Spam-Level: X-Spam-Status: No, score=-103.577 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 QDpXEb3VwAHm for ; Wed, 9 Nov 2011 13:28:34 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id AB4E921F85A4 for ; Wed, 9 Nov 2011 13:28:33 -0800 (PST) Received: by wwf22 with SMTP id 22so8387333wwf.1 for ; Wed, 09 Nov 2011 13:28:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=jv5jQTrpXQtGTl+7PTSiA7181UgOMQedm3waAp6F3Hw=; b=w/ZykRZmeXQ81Ofdb6yiqazojdBX8S62kWRqcB3YpqBXgeLwokBAuaDhoy6TBAIgE3 KsOkbAMmyouyVAdopn0Q== Received: by 10.216.138.29 with SMTP id z29mr126266wei.4.1320874112788; Wed, 09 Nov 2011 13:28:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.138.29 with SMTP id z29mr126261wei.4.1320874112686; Wed, 09 Nov 2011 13:28:32 -0800 (PST) Received: by 10.216.216.205 with HTTP; Wed, 9 Nov 2011 13:28:32 -0800 (PST) In-Reply-To: <4EBAE198.3020406@gmx.de> References: <4EBA3B24.5060602@gmx.de> <4EBAE198.3020406@gmx.de> Date: Wed, 9 Nov 2011 13:28:32 -0800 Message-ID: From: Chris Palmer To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: IETF WebSec WG Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 21:28:34 -0000 >From what I can gather, there is a thing called "header field recombination", in which a proxy or something collapses two or more headers of the same type into one, and joins their values with a ",". Therefore, I should not list multiple pins separated with a "," in the PKP header. OK. (This is new to me. Are there MITMs that really do this? Why?) (FWIW, the only relevant hit in the first page of Google results for [ header field recombination ] is http://svn.tools.ietf.org/wg/httpbis/trac/ticket/231.) > =C2=A0 Public-Key-Pins: max-age=3D31536000; > =C2=A0 =C2=A0 =C2=A0 pins-sha1=3D4n972HfV354KP560yw4uqe/baXc=3D; > =C2=A0 =C2=A0 =C2=A0 pins-sha256=3DLPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYp= OLmCQ=3D OK. I suppose now we might as well get rid of the "pins-" too. > Finally, allow quoted-string notation, > > =C2=A0 Public-Key-Pins: max-age=3D31536000; > =C2=A0 =C2=A0 =C2=A0 pins-sha1=3D"4n972HfV354KP560yw4uqe/baXc=3D"; > =C2=A0 =C2=A0 =C2=A0 pins-sha256=3D"LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzY= pOLmCQ=3D" > > so that characters not allowed (such as "/") in HTTP tokens work. But if "/" is not allowed in HTTP tokens, we have to require quoted-string notation, and not merely allow it. Right? Could anyone propose exact ABNF grammar that is acceptable given the above constraints? Currently, I have it as: Public-Key-Pins =3D "Public-Key-Pins" ":" LWS directives directives =3D max-age LWS ";" LWS pins / pins LWS ";" LWS max-age max-age =3D "max-age" LWS "=3D" LWS delta-seconds pins =3D "pins" LWS "=3D" LWS fingerprints fingerprints =3D fingerprint / fingerprint "," fingerprints fingerprint =3D fp-type "-" base64-digits fp-type =3D "sha1" / "sha256" Thanks! From julian.reschke@gmx.de Wed Nov 9 13:45:14 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F4711E80AF for ; Wed, 9 Nov 2011 13:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.398 X-Spam-Level: X-Spam-Status: No, score=-104.398 tagged_above=-999 required=5 tests=[AWL=-1.799, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWEaPNwycb8o for ; Wed, 9 Nov 2011 13:45:13 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1F30711E8093 for ; Wed, 9 Nov 2011 13:45:12 -0800 (PST) Received: (qmail invoked by alias); 09 Nov 2011 21:45:09 -0000 Received: from p5DCC32E8.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.50.232] by mail.gmx.net (mp013) with SMTP; 09 Nov 2011 22:45:09 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/+5f1ySB/+cbCowteapaaL1U6FgWpksT1+wPBHRA rgKO/OSgd47clI Message-ID: <4EBAF460.50009@gmx.de> Date: Wed, 09 Nov 2011 22:45:04 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Chris Palmer References: <4EBA3B24.5060602@gmx.de> <4EBAE198.3020406@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 21:45:14 -0000 On 2011-11-09 22:28, Chris Palmer wrote: >> From what I can gather, there is a thing called "header field > recombination", in which a proxy or something collapses two or more > headers of the same type into one, and joins their values with a ",". > Therefore, I should not list multiple pins separated with a "," in the > PKP header. OK. > > (This is new to me. Are there MITMs that really do this? Why?) I know of *libraries* that do this, and I wouldn't rule out intermediates using those. > (FWIW, the only relevant hit in the first page of Google results for [ > header field recombination ] is > http://svn.tools.ietf.org/wg/httpbis/trac/ticket/231.) > >> Public-Key-Pins: max-age=31536000; >> pins-sha1=4n972HfV354KP560yw4uqe/baXc=; >> pins-sha256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ= > > OK. I suppose now we might as well get rid of the "pins-" too. Unless you need an extension point for other parameters. >> Finally, allow quoted-string notation, >> >> Public-Key-Pins: max-age=31536000; >> pins-sha1="4n972HfV354KP560yw4uqe/baXc="; >> pins-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=" >> >> so that characters not allowed (such as "/") in HTTP tokens work. > > But if "/" is not allowed in HTTP tokens, we have to require > quoted-string notation, and not merely allow it. Right? Indeed. But they are used in base64, unless you switch to . > Could anyone propose exact ABNF grammar that is acceptable given the > above constraints? Currently, I have it as: > ... I made a proposal; is there something specific you didn't like? Best regards, Julian From palmer@google.com Wed Nov 9 13:50:20 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BFD11E80B4 for ; Wed, 9 Nov 2011 13:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.477 X-Spam-Level: X-Spam-Status: No, score=-103.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 irRzhkKJt62Z for ; Wed, 9 Nov 2011 13:50:20 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C97D511E8080 for ; Wed, 9 Nov 2011 13:50:19 -0800 (PST) Received: by wyf28 with SMTP id 28so208604wyf.31 for ; Wed, 09 Nov 2011 13:50:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=L/JEjQKCm2YtOcEgT4ussYx3mw2ZecDuu+Ea3obcJTg=; b=yb+Vxu8gWjAJebv40/h70zhVQyHBZIrXTqpMqiky/Hy3l8I9lSZ3Or78SEfWh8yZP/ 0ir00Dm/ozj0Y+pdMyzA== Received: by 10.216.52.143 with SMTP id e15mr2543801wec.34.1320875418470; Wed, 09 Nov 2011 13:50:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.52.143 with SMTP id e15mr2543793wec.34.1320875418346; Wed, 09 Nov 2011 13:50:18 -0800 (PST) Received: by 10.216.216.205 with HTTP; Wed, 9 Nov 2011 13:50:18 -0800 (PST) In-Reply-To: <4EBAF460.50009@gmx.de> References: <4EBA3B24.5060602@gmx.de> <4EBAE198.3020406@gmx.de> <4EBAF460.50009@gmx.de> Date: Wed, 9 Nov 2011 13:50:18 -0800 Message-ID: From: Chris Palmer To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: IETF WebSec WG Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 21:50:20 -0000 On Wed, Nov 9, 2011 at 1:45 PM, Julian Reschke wrot= e: >> Could anyone propose exact ABNF grammar that is acceptable given the >> above constraints? Currently, I have it as: >> ... > > I made a proposal; is there something specific you didn't like? Your proposal is fine =E2=80=94 thank you! It's just that I am almost certainly going to write the ABNF wrong, and then we'll have a whole long thread about that. :) From ryan-ietfhasmat@sleevi.com Wed Nov 9 14:03:28 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2630F11E809B for ; Wed, 9 Nov 2011 14:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfh9jyby6cPD for ; Wed, 9 Nov 2011 14:03:27 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 870B911E8096 for ; Wed, 9 Nov 2011 14:03:27 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 7CC7526C073; Wed, 9 Nov 2011 14:03:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= sleevi.com; b=TqyuvbzVsBi9mScKaQT8LvCCjpl6Djusl0BkQhwD4JSGfOcDPi 12TgsaFk6ys8ItMDtCbPZ9H7hASyZcy08psmwPZISUkW5+bY8HpQ/Kb20RvugxP1 bOstxN9JKwv0rSMGWctyrFv5k7LJCpcza3bsrneK5fBLnm11LLIjUsLfU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=5dAoxdJWUKMLecxq1uWrnq/OXGo=; b=l7iBH6GpVSZ6youlg FRLvNorTBQqOniYLaNBQ58whFSg1pQR4RcIqm+aeuh+13LkGyc0QZykqPzPUw2OG izLcR6ZDYD5NnHvybQg+6WCSAppQ0w7SIBWPm9YZJjBjftAkiagaYr1X3+VuQpAo 0DJJidh1wTbrCSUaSI1H+/2LFw= Received: from webmail.sleevi.com (ahfbbjcaiaae.dreamhost.com [75.119.208.4]) (Authenticated sender: ryan@sleevi.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPA id 2885626C072; Wed, 9 Nov 2011 14:03:22 -0800 (PST) Received: from 72.189.105.152 (proxying for 72.189.105.152) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.sleevi.com with HTTP; Wed, 9 Nov 2011 17:03:22 -0500 Message-ID: In-Reply-To: References: <4EBA3B24.5060602@gmx.de> <4EBAE198.3020406@gmx.de> <4EBAF460.50009@gmx.de> Date: Wed, 9 Nov 2011 17:03:22 -0500 From: "Ryan Sleevi" To: "Chris Palmer" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 22:03:28 -0000 > On Wed, Nov 9, 2011 at 1:45 PM, Julian Reschke > wrote: > > >> Could anyone propose exact ABNF grammar that is acceptable given the > >> above constraints? Currently, I have it as: > >> ... > > > > I made a proposal; is there something specific you didn't like? > > Your proposal is fine =E2=80=94 thank you! It's just that I am almost > certainly going to write the ABNF wrong, and then we'll have a whole > long thread about that. :) While revisiting the ABNF, should "fp-type" be made into 'token' instead of an explicit list ( "sha1" / "sha256" )? Rather than dealing with the minimal set of "must-implements" in the grammar, define it in the text fo= r processing rules. This is similar to the conversation that happened for the STS grammar rules. I'm just wondering how legacy parsers would be expected to handle future versions with say, SHA-3. Defining it as a token would at least allow it to be syntactically valid and parsed, even if fingerprints of that type are not understood/supported. From palmer@google.com Thu Nov 10 11:35:48 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF9821F8B7E for ; Thu, 10 Nov 2011 11:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.406 X-Spam-Level: X-Spam-Status: No, score=-103.406 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 v0JEO4-CQFbf for ; Thu, 10 Nov 2011 11:35:47 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFB521F8B7B for ; Thu, 10 Nov 2011 11:35:47 -0800 (PST) Received: by wyf28 with SMTP id 28so1406369wyf.31 for ; Thu, 10 Nov 2011 11:35:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=niLoBj4OdLP5vQDVMdb/pVCsqkww3G1sva3b3GUHjWI=; b=tNvfbLcKuKOBzNp8LfEcF+pcr3XINrDVyGO8w4HUodZHhHIao2sAp3SGJr3sGXZRJp ZMwcNNScBafULs5kvZqA== Received: by 10.216.153.137 with SMTP id f9mr19930wek.4.1320953746724; Thu, 10 Nov 2011 11:35:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.153.137 with SMTP id f9mr19921wek.4.1320953746521; Thu, 10 Nov 2011 11:35:46 -0800 (PST) Received: by 10.216.216.205 with HTTP; Thu, 10 Nov 2011 11:35:46 -0800 (PST) In-Reply-To: References: <4EBA3B24.5060602@gmx.de> <4EBAE198.3020406@gmx.de> <4EBAF460.50009@gmx.de> Date: Thu, 10 Nov 2011 11:35:46 -0800 Message-ID: From: Chris Palmer To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: IETF WebSec WG Subject: Re: [websec] New draft of HTTP header-based public key pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 19:35:48 -0000 On Wed, Nov 9, 2011 at 2:03 PM, Ryan Sleevi wrote: > While revisiting the ABNF, should "fp-type" be made into 'token' instead > of an explicit list ( "sha1" / "sha256" )? Rather than dealing with the > minimal set of "must-implements" in the grammar, define it in the text for > processing rules. This is similar to the conversation that happened for > the STS grammar rules. Here is what I have now:
Public-Key-Pins = "Public-Key-Pins" ":" LWS directives directives = max-age LWS ";" LWS pins / pins LWS ";" LWS max-age max-age = "max-age" LWS "=" LWS delta-seconds pins = pin / pin LWS ";" LWS pins pin = "pin-" token LWS "=" LWS quoted-string
In the pin rule, the token is the name of a cryptographic hash algorithm, and MUST be either "sha1" or "sha256". (Future versions of this specification may change the hash functions.) The quoted-string is a sequence of base64 digits: a base64-encoded hash. See . From palmer@google.com Mon Nov 14 13:44:28 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34A811E8102 for ; Mon, 14 Nov 2011 13:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.352 X-Spam-Level: X-Spam-Status: No, score=-103.352 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 2HSc+mqyM5Wa for ; Mon, 14 Nov 2011 13:44:27 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC63111E8100 for ; Mon, 14 Nov 2011 13:44:26 -0800 (PST) Received: by wwe5 with SMTP id 5so3644599wwe.13 for ; Mon, 14 Nov 2011 13:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-system-of-record; bh=TnAgVP4MtfIZKGB3ylmou5VY4i6azL/qOCYeWj3Y4Tg=; b=qL1jsstvjXDk78O4Mdv8oGducFmeaji4NiuPGf842hWTaZff1ys73b6dxfWakjwSwY aRmUx1MdH1texg88OlmQ== Received: by 10.216.54.134 with SMTP id i6mr1490280wec.19.1321307064551; Mon, 14 Nov 2011 13:44:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.54.134 with SMTP id i6mr1490274wec.19.1321307064466; Mon, 14 Nov 2011 13:44:24 -0800 (PST) Received: by 10.216.216.205 with HTTP; Mon, 14 Nov 2011 13:44:24 -0800 (PST) In-Reply-To: <20111114213908.10768.82188.idtracker@ietfa.amsl.com> References: <20111114213908.10768.82188.idtracker@ietfa.amsl.com> Date: Mon, 14 Nov 2011 13:44:24 -0800 Message-ID: From: Chris Palmer To: IETF WebSec WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Subject: [websec] Fwd: New Version Notification for draft-evans-palmer-key-pinning-00.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 21:44:28 -0000 FYI. ---------- Forwarded message ---------- From: Date: Mon, Nov 14, 2011 at 1:39 PM Subject: New Version Notification for draft-evans-palmer-key-pinning-00.txt To: palmer@google.com Cc: cevans@google.com, palmer@google.com A new version of I-D, draft-evans-palmer-key-pinning-00.txt has been successfully submitted by Chris Palmer and posted to the IETF repository. Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-evans-palmer-key-pinning Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000 Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Public Key Pinning Extension for = HTTP Creation date: =C2=A0 2011-11-14 WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission Number of pages: 7 Abstract: =C2=A0 This memo describes an extension to the HTTP protocol allowing web =C2=A0 host operators to instruct user agents (UAs) to remember ("pin&= quot;) the =C2=A0 hosts' cryptographic identities for a given period of time. =C2= =A0During =C2=A0 that time, UAs will require that the host present a certificate chai= n =C2=A0 including at least one Subject Public Key Info structure whose =C2=A0 fingerprint matches one or more of the pinned fingerprints for that =C2=A0 host. =C2=A0By effectively reducing the scope of authorities who can =C2=A0 authenticate the domain during the lifetime of the pin, pinning may =C2=A0 reduce the incidence of man-in-the-middle attacks due to compromised =C2=A0 Certification Authorities and other authentication errors and =C2=A0 attacks. The IETF Secretariat From alexey.melnikov@isode.com Mon Nov 14 17:57:07 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3463111E82BA for ; Mon, 14 Nov 2011 17:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mwIWDAyDTTs for ; Mon, 14 Nov 2011 17:57:06 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5434511E82B1 for ; Mon, 14 Nov 2011 17:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1321322225; d=isode.com; s=selector; i=@isode.com; bh=iuvq9ADToMRKgNq4X28vZanySekg5eWoVnUbVdmTO9k=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=MxMbsPomEPduDCY397glkEdx+p6F7HkIpTz/OHF7tLEg/G1CraFtz5GAI3Vq+WlHo7GE7Y E5mp5JKoV0ai3xDWTfcTv1rq9o/E99uDMbli/CtvaaK3lfWvnxb18Tl1LwuVGBzc1OG6pp FGB5Wf93b1gKOrlTrfvk4hv0fYA62AM=; Received: from [192.168.174.158] (60-251-183-229.HINET-IP.hinet.net [60.251.183.229]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 15 Nov 2011 01:57:04 +0000 Message-ID: <4EC1C6EF.6000904@isode.com> Date: Tue, 15 Nov 2011 01:57:03 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: IETF WebSec WG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] Testsuite for MIME sniffing X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:57:07 -0000 Hi, Larry Masinter has suggested creation of a test suite in order to help figure out what exactly different browsers do when guessing MIME types. Tobias and I discussed this yesterday and we concur that this is a good idea. If there is anybody interested in working/helping out on this, can you please contact Tobias Gondrom and myself directly? Thank you, Alexey, on behalf of WebSec WG chairs From trac+websec@trac.tools.ietf.org Mon Nov 14 18:50:54 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698D31F0D58 for ; Mon, 14 Nov 2011 18:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joDfSxqY7sAN for ; Mon, 14 Nov 2011 18:50:53 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 516611F0D47 for ; Mon, 14 Nov 2011 18:50:52 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RQ96j-0002pv-Fz; Mon, 14 Nov 2011 21:50:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-mime-sniff@tools.ietf.org, ietf@adambarth.com, masinter@adobe.com X-Trac-Project: websec Date: Tue, 15 Nov 2011 02:50:45 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/16#comment:2 Message-ID: <082.21e40fb992c0be70c1b854e9ab4f5b31@trac.tools.ietf.org> References: <067.0c626f20ba70069d5bffe870f0af308a@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <067.0c626f20ba70069d5bffe870f0af308a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, ietf@adambarth.com, masinter@adobe.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111115025053.516611F0D47@ietfa.amsl.com> Resent-Date: Mon, 14 Nov 2011 18:50:52 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #16: lack of explanatory text and no justifications for the normative language X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:50:54 -0000 #16: lack of explanatory text and no justifications for the normative language Comment (by masinter@…): I think a test suite (with links to, copy of, or at least documentation of) real, deployed, useful sites which need each sniffing configuration will go a long way toward justifying what we have. Frankly, I suspect that some cases of sniffing which were valid in 2009 may no longer be valid in 2011. -- -----------------------------+--------------------------------------------- Reporter: | Owner: draft-ietf-websec-mime-sniff@… tobias.gondrom@… | Status: new Type: defect | Milestone: Priority: major | Version: Component: mime-sniff | Resolution: Severity: Active WG | Document | Keywords: | -----------------------------+--------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Mon Nov 14 18:55:45 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E351F0D53 for ; Mon, 14 Nov 2011 18:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us8vfRw-puny for ; Mon, 14 Nov 2011 18:55:45 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB7F1F0D3D for ; Mon, 14 Nov 2011 18:55:45 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RQ9BW-0003JJ-DI; Mon, 14 Nov 2011 21:55:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-mime-sniff@tools.ietf.org, masinter@adobe.com X-Trac-Project: websec Date: Tue, 15 Nov 2011 02:55:42 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/17#comment:1 Message-ID: <074.72d7651024a6b67682c4e1a1c46ecfa5@trac.tools.ietf.org> References: <059.70846bca9f857812ac02d38043b050ef@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <059.70846bca9f857812ac02d38043b050ef@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, masinter@adobe.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111115025545.4FB7F1F0D3D@ietfa.amsl.com> Resent-Date: Mon, 14 Nov 2011 18:55:45 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #17: Use the "magic numbers" in the media type IANA registry instead of an explicit table X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:55:45 -0000 #17: Use the "magic numbers" in the media type IANA registry instead of an explicit table Comment (by masinter@…): The IANA registry of magic numbers contains a lot of garbage unsuitable for a normative algorithm for sniffing. I don't think the IANA registry can be used as-is. Rather, the information currently in tables in this document should be moved/copied/duplicated in an IANA registry which is either part of, or linked to, the IANA media type registry. This might not be necessary if the scope of the document (issue #15) were limited to "HTTP responses which contain content-type headers", but since the scope is much broader, accomdating new media types is necessary and only having a registry for that extensibility point would allow this document to move to standards track. (Unless this document is moved to BCP?) -- ------------------------+--------------------------------------------- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff | Version: Severity: - | Resolution: Keywords: | ------------------------+--------------------------------------------- Ticket URL: websec From tobias.gondrom@gondrom.org Tue Nov 15 02:07:16 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76F511E81AE for ; Tue, 15 Nov 2011 02:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.778 X-Spam-Level: X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 1hDaZj+jyduh for ; Tue, 15 Nov 2011 02:07:16 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id ED56011E80C0 for ; Tue, 15 Nov 2011 02:07:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=s/X5MAgLCxePSvJN5DiEKhkP60+t6lvjvvWC9JZiRWr5bx1PAQ4W9pEPv7xOzFtfy4Gzetqn2O8Qidp+QxX0D8Eg5ytOvT4/DBUZT5n3NyqwWZW+eKuZKjlS9OSIavFW; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; Received: (qmail 13979 invoked from network); 15 Nov 2011 11:06:10 +0100 Received: from dhcp-5209.meeting.ietf.org (HELO ?130.129.82.9?) (130.129.82.9) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Nov 2011 11:06:10 +0100 Message-ID: <4EC2398F.2050201@gondrom.org> Date: Tue, 15 Nov 2011 10:06:07 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: websec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] meeting slides X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 10:07:17 -0000 Hello dear websec fellows, please find the slides for our meeting tomorrow (Wednesday) at 13:00 (Taipei time) in room 201 ABC are uploaded to the Meeting Materials Server: https://datatracker.ietf.org/meeting/82/materials.html (the slides for HSTS will be uploaded later tonight.) Best regards and looking forward to interesting discussions and seeing you all tomorrow. Tobias (websec chair) From trac+websec@trac.tools.ietf.org Tue Nov 15 04:58:58 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027D421F8B9D for ; Tue, 15 Nov 2011 04:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uO8sTgXoGuQw for ; Tue, 15 Nov 2011 04:58:57 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8274B21F8BA6 for ; Tue, 15 Nov 2011 04:58:56 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RQIb4-0005gY-95; Tue, 15 Nov 2011 07:58:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 15 Nov 2011 12:58:42 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/26 Message-ID: <070.45b3e36f2fc91121b4d5c6938f180a3e@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111115125857.8274B21F8BA6@ietfa.amsl.com> Resent-Date: Tue, 15 Nov 2011 04:58:56 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #26: reference IDNA2008 as well as IDNA2003 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 12:58:58 -0000 #26: reference IDNA2008 as well as IDNA2003 Re: [websec] Strict-Transport-Security syntax and effective request URI def [StPeter] https://www.ietf.org/mail-archive/web/websec/current/msg00476.html SECTION 7 We have a normative reference to RFC 3490, which has been obsoleted by RFC 5890 and friends. Why not cite the definition of A-label from Section 2.3.2.1 of RFC 5890? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: major | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Tue Nov 15 05:02:00 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8473E21F8CFC for ; Tue, 15 Nov 2011 05:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHd1IkwHsZuz for ; Tue, 15 Nov 2011 05:02:00 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 080DD21F8BAB for ; Tue, 15 Nov 2011 05:02:00 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RQIeA-00037g-Dc; Tue, 15 Nov 2011 08:01:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 15 Nov 2011 13:01:54 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/27 Message-ID: <070.4240e75d9bcd1a27acd9fe924417061f@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111115130200.080DD21F8BAB@ietfa.amsl.com> Resent-Date: Tue, 15 Nov 2011 05:02:00 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 13:02:00 -0000 #27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken HSTS header ABNF in -02 HSTS spec revision is a hybrid of RFC2616 and httpbis and is overly complex and broken See these messages for details Strict-Transport-Security syntax redux [Ryan Sleevi] https://www.ietf.org/mail-archive/web/websec/current/msg00614.html Strict-Transport-Security syntax redux [Julian Reschke] https://www.ietf.org/mail-archive/web/websec/current/msg00673.html -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: major | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Tue Nov 15 05:05:15 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC87B21F8E18 for ; Tue, 15 Nov 2011 05:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+yXG0p8ZQw5 for ; Tue, 15 Nov 2011 05:05:15 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB4721F8E17 for ; Tue, 15 Nov 2011 05:05:15 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RQIhL-0003IX-Tn; Tue, 15 Nov 2011 08:05:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 15 Nov 2011 13:05:11 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/28 Message-ID: <070.3a39431f6b25ef97957a720cb34b8bc4@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111115130515.6BB4721F8E17@ietfa.amsl.com> Resent-Date: Tue, 15 Nov 2011 05:05:15 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #28: HSTS spec unclear about the denotation of "HSTS policy" X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 13:05:16 -0000 #28: HSTS spec unclear about the denotation of "HSTS policy" Strict-Transport-Security syntax and effective request URI def [StPeter] https://www.ietf.org/mail-archive/web/websec/current/msg00476.html The document is a bit unclear about the denotation of "HSTS policy". Sometimes it refers to the site's policy and sometimes to the overall recommendations defined in the spec. This specification also incorporates notions from [JacksonBarth2008] in that the HSTS policy is applied on an "entire-host" basis: it applies to all TCP ports on the host. Additionally, HSTS policy can be applied to the entire domain name subtree rooted at a given host name. This enables HSTS to protect so-called "domain cookies", which are applied to all subdomains of a given domain. Perhaps it would be helpful to contrast the all ports and entire subtree principles with the same origin policy also being worked on in this WG, with an informational reference to the appropriate spec. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Tue Nov 15 05:06:20 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2473221F8E1F for ; Tue, 15 Nov 2011 05:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7KkWcuLKbHI for ; Tue, 15 Nov 2011 05:06:19 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A58BB21F8E18 for ; Tue, 15 Nov 2011 05:06:19 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RQIiO-0003JD-Nv; Tue, 15 Nov 2011 08:06:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 15 Nov 2011 13:06:16 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/29 Message-ID: <070.1a3da0b8fa7ba44ba84d532e60c04267@trac.tools.ietf.org> X-Trac-Ticket-ID: 29 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111115130619.A58BB21F8E18@ietfa.amsl.com> Resent-Date: Tue, 15 Nov 2011 05:06:19 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #29: HSTS: dismbiguate "mixed content" term & provide reference X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 13:06:20 -0000 #29: HSTS: dismbiguate "mixed content" term & provide reference Strict-Transport-Security syntax and effective request URI def [StPeter] https://www.ietf.org/mail-archive/web/websec/current/msg00476.html SECTION 2.3.1.3 The term "mixed content" threw me off because it is also used in XML: http://www.w3.org/TR/2008/REC-xml-20081126/#sec-mixed-content Also, it might be good to consistently use and prefer the term "mixed security context" in this specification. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Tue Nov 15 05:08:37 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E838411E8073 for ; Tue, 15 Nov 2011 05:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suorsbQ9eoMh for ; Tue, 15 Nov 2011 05:08:36 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 742C521F8E75 for ; Tue, 15 Nov 2011 05:08:36 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RQIkY-0003KU-8G; Tue, 15 Nov 2011 08:08:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 15 Nov 2011 13:08:30 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/30 Message-ID: <070.9bcc15f64797e545d79084876df10189@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111115130836.742C521F8E75@ietfa.amsl.com> Resent-Date: Tue, 15 Nov 2011 05:08:36 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #30: HSTS: add an informational reference to RFC 4732: Denial-of-Service Considerations X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 13:08:37 -0000 #30: HSTS: add an informational reference to RFC 4732: Denial-of-Service Considerations Strict-Transport-Security syntax and effective request URI def [StPeter] https://www.ietf.org/mail-archive/web/websec/current/msg00476.html SECTION 12.2 Let's add an informational reference to RFC 4732. Can we add some more details to the description of the denial of service attack? IMHO it's a bit thin. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Tue Nov 15 05:13:10 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4A421F8EAB for ; Tue, 15 Nov 2011 05:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAT7zjdzeZTt for ; Tue, 15 Nov 2011 05:13:09 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5B621F8E0B for ; Tue, 15 Nov 2011 05:13:08 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RQIou-0003Qu-96; Tue, 15 Nov 2011 08:13:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 15 Nov 2011 13:13:00 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/31 Message-ID: <070.68b3117d50f361935101f81dd18f1c89@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111115131309.6D5B621F8E0B@ietfa.amsl.com> Resent-Date: Tue, 15 Nov 2011 05:13:08 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #31: HSTS: mention case insesitivity in prose for "max-age" and "includeSubDomains" X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 13:13:10 -0000 #31: HSTS: mention case insesitivity in prose for "max-age" and "includeSubDomains" Re: [websec] Strict-Transport-Security syntax redux [JulianR] https://www.ietf.org/mail-archive/web/websec/current/msg00765.html Also, identifiers "max-age" and "includeSubDomains" are case-insensitive, right? This follows from the ABNF, but might be worth saying again in prose; in particular because it also needs to be the case for all future extensions. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: websec From Jeff.Hodges@KingsMountain.com Tue Nov 15 05:58:49 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F54921F8D4A for ; Tue, 15 Nov 2011 05:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.309 X-Spam-Level: X-Spam-Status: No, score=-99.309 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, TRACKER_ID=2.003, 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 jBbaLpr5dJhu for ; Tue, 15 Nov 2011 05:58:45 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id D5C3C21F8D3E for ; Tue, 15 Nov 2011 05:58:44 -0800 (PST) Received: (qmail 25582 invoked by uid 0); 15 Nov 2011 13:58:44 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 15 Nov 2011 13:58:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=38W0NlHnGR+E/xP8saLeVbYczI4geKghb+j839q+PoA=; b=rKz/DNbz7YyiQQucqa+bA2N3E49mXv0pzjLPO/CjDnJP1z9fNkfCbSpXDNM0Y+/nbGUbsnUvkxZs6MMXJreD8ElBytp7Yeuf3/oGgUnzY+reCs8O+K40jr4twKXIP11q; Received: from dhcp-4744.meeting.ietf.org ([130.129.71.68]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RQJX8-0006RN-Rl; Tue, 15 Nov 2011 06:58:43 -0700 Message-ID: <4EC2700E.8060004@KingsMountain.com> Date: Tue, 15 Nov 2011 05:58:38 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Tobias Gondrom , IETF WebSec WG Content-Type: multipart/mixed; boundary="------------070002090109050803000401" X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.71.68 authed with jeff.hodges+kingsmountain.com} Subject: [websec] hodges-ietf-82-websec-HSTS-Status X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 13:58:49 -0000 This is a multi-part message in MIME format. --------------070002090109050803000401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit pls see attached -- my preso for tomorrow wrt HSTS status thx =JeffH --------------070002090109050803000401 Content-Type: application/pdf; name="hodges-ietf-82-websec-HSTS-Status.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="hodges-ietf-82-websec-HSTS-Status.pdf" JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nJWRS0sDQRCE7/Mr+hzI2j3vgWUgm8fBW2DBg3jTKBIFc/Hv W9NrFDV7kIGl6an6tqabO6F380ZMS+4speK6SKEE1KcHc7OgVyPUzunRcLugF9NESesjTbV6 j2dIK6bbJ3NYKLwdEIbRuAK9b7Lxnq52QHsaDz1LHZ/NdjT7P/rQhf8YhHOXySWGTR2WXITj Fha27OpSevbV9hw4cuKsjdAaHo1SXc+ZV9odUK3RHKC10K7Vg7qpJ9IGl1utdpAEFcNU78br S+lsthiwzblz53Q2azph+HyV2NKBJzLHcC5gaz8ZPDGsOpEsgleXHk+p+lxJ06MFbHzDHBsj wH4u5hNl+6pPFYmIO8xG9BEAGxKC/sIkxeSWpciqTTtqpEFmh+aw/kzW+a6cafJJK1XYt11g bAmLiG15STZIi0l+XXOqocdubdsbb75/tKcPCjqkQQplbmRzdHJlYW0KZW5kb2JqCgozIDAg b2JqCjMzOAplbmRvYmoKCjUgMCBvYmoKPDwvTGVuZ3RoIDYgMCBSL0ZpbHRlci9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nJVVS4vcMAy+51f4vDCpJfmRwGCYZCaH3hYGeii9dbelbAvdS/9+ 9XAy2Vd2loDjKLL8Sfo+27fg/jV/nXc736LLPbXJxT7y/PGu+XLj/jTg5Hn80Xj54X434pR1 /uBsrmsf5iAysb8/m/sbDS4PRxjODfXsH8Tt/N19mjh0cOf7vYdy/tWczs3tC//Yxo8sQMK2 c9GnNtgKdEFWfN3DyXd+LDvY8/tY+BXLDvcAMKkR/cRGSB6LugxqHcq38+fXNgodYwpEDE/3 IUbWbmPLUqyAiccKjVCh8QpGwgjIB8/Yfeb9I8+T70tiMPr7oONQv0Ydk8BESUXX52rmGEVf HFINx7r2pO+pblfdLMSTsOhhtOq8lb8mQ73naj9LRvdAS+mAAko3QFptw1WvKI51G3YIde9o ASDZtyFBr2MqOcr4BqoOuSsU/dx97goypbe6Aj5LJiFcGIOdZoJaVeAHDToXkFMhSQK1aUGQ M01QQGoabBJeCZ+ERiQFpT1KQ8XwxCOLx4jZQlbjUCN21ZtNk/1C0iBWLvnuyy5KFC0jl1N6 evldf1hUASz+/XuMJv9BPmPfzeJcKACnWq9x1fKMB7aAAWRudzMVVuQ2imhJqherUnBn/uL1 pByfVgQb1MssiJVqr5BLKK0f19AaE7b0LCccfOQOrORkKCu5pf143CwtQv/B0gK+LG2uWh4X FZveTpfSlqXm71e41gknnDY1BRlmpV+tKUix7Z9pirzopC9UZ6oHYXYxcEEE162pHNGESNJG wsKaO2xDxX7u3vVQkS4dr1BBYYQCSUa7N1TNK/niwcSrHGPaixMRgt0fZAez6ZGCKFpcIG/i 75YL4mr43eoYntEbmAV5vdWONQU9e46QDBsjEoSRjVphLTiMyOyC4b07IMxX4EUrzCbegeZ7 JxrNmG5y35gQKW0LkYXOGlkHxzAL8aTHn8r6IAE1t1z4MBzkloHlgF7OQj0cj5qqNUOB6O2X hHSkBWBRWWvVpkc6enPM2dzXGr91/wEIevmeCmVuZHN0cmVhbQplbmRvYmoKCjYgMCBvYmoK NzY5CmVuZG9iagoKOCAwIG9iago8PC9MZW5ndGggOSAwIFIvRmlsdGVyL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCnicpVZLi9tADL77V/i8kHQkzYxtMIY4iQ+9LQR6KL2121K2he6lf796zNiT bJ1NWgKTeUga6dMnjd0W6t/Vr9rVG7fFuuloG+vQBZ6/fKk+PNQ/K6jl9/K1cnJQ/6hEqNH5 c21z1X3ORmRip9+qpwc1Lj+2MJ4q6ljei9jpc/1uYtO+Pj31DobT9+p4qh5fyYdtuEcBfbP1 dXCRR9XA2ovGx56Ca11w5Jphgz0irwCA3LCB3gXZczTkKYIbh0+n93+7wrfsjSdix/QGYp+2 171qBCaPkcfkFKE5hXpx67qB2CceqAW523zY6X83bJreNex8GERYVUBGFg18sMfGzOgY3AiA owvUsj0+PqhoNAW2ekwzdJMqTHafqbNJM3OwK5IvB5xwWkOkRUaE2rilGRFkIl1DBFzDYFDr sg7W2CokKEEyFJyKDA454Fg8+6bJ4iX/8uEoHlJv6dTzRnQPaaFho6PI7vN6PQiAjquBvC+i aDUGXIvBg8TA48w1TFzr5C7YcyS0k2HUtXnEjnsBm733uqHTYvcgw17nohJ6aESOAsfFhAkM kZpGZ4OYHpOwwCPqY1p0ObMgmAYDdhaUMUmu3yGqchPFN6BzMt4FHZcpXIFufwEd0oKXRglW Dxk+lgooBPI9AWmkuwUXpcVYgGTgokyZiLslCw3Hr7ZNgssk5yphdcym6TCoswKdrDHmlJ9h fMjOznGgNhprN3zDUTbUA/PyaqWhj0Xvua3SkHtouKg06AYADndKvu5c+z8VdrytwtD5wvtb aIIOJMY1mij3zypslBaXibJPmMNSWtZdEo20JMvS2elUcm46obAcZsbM5QkzDedMT0t6c6ZD YtU0SyXdc26FnibwUoNO+h0HGdMUFp5Mc4PUPOyF7q1kiN6AHmKXH9IboYcYiwb9CnrvLqHP /GBfR3m4oOQ1RAO1BAZKJGnKOiLuYcgtsShGCbeAsbAhDx2kDZqWjEFODibrduRz1hVUNFh3 g0+wQpHkNVQNI/6oCRcY3dHkr2eMi/fOjDm/kjGK+c04yxgtFF46lKXnsKBuFb+Eo7TNeCYb YekN0xwiZbL+4+s3253W+69x52hPRo6UCXoV2uY+XGN3BdR4+VAlXC5ZudID9unNNpqe9di8 r3/NcIYyk7Xt582gn456WKYovYtzjlUcU2ssOpMxf/nmKLJXBlO8TI/1H5DunagKZW5kc3Ry ZWFtCmVuZG9iagoKOSAwIG9iago5MDEKZW5kb2JqCgoxMSAwIG9iago8PC9MZW5ndGggMTIg MCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nJVVwW7bMAy9+yt0LhCPpCRLBgwB cRwfditgYIdht7Ubhm7Aetnvj6Qk22ubrKlRRpZIiuR7pKFF86f5bcAcoCUTett2xvee188P zac786tBI8/ztwbkwPxsRCno+snktdo+VSeyyKffm8c7dS4PexiXxvas70Rt+Wo+zOzameVx AEzLj+a8NPev9H3rbzEgH9nAQ9e6bEHGicXnwYZ0oIGOiQaIQAkHsMR/sotoIR14x8sbWPCE MKYvy8e37nCRw3HW8kV6heWg2uthBamTo45licqSRoWz3kgalS5HlXk9qfRJIiwH593xiXcD 9ekQyj5nY8th2X7pp2xgzhoCTIh41L2wj8KBBuYwdaJnd27Y4FJlNE3bQxtfpGnVlCxQ9rtG d8FRJC6x9VBR5BITU/NaiTkZudy5DXmKerlc5geYgXLtOH7B+gSznPScuZBhws7Zy6kp6EyM 2yCnPlbqbpArkAQqORjoucal7Me11uedHBWpcaMHszNuvOXfnjMoSyxGMxEbnWRtI9Picmpa bPKhovbuYpPHDelSbDhrd2kkry5sPWDfVR++4/Hzpo8+RRFOROcHmhUwTt0Kh2bgIsFE1tpy kqG8hhxGrEC8FzsMOyoV7JzLtc3tRzpSCrd98oFzdp7/i1au/l5LagO+alU/mxa3Ilb3c4FT sKfa8VsjBzpWEsirJ7tZUe7vruz5zJr/9C3aWCfamm+lWybn/u2f+YJbHMdMuPxy2g0rzTut nA5lmmQZZG5NOeiSdhl3+8QR63RKhOuMWj3TyJCxuRvQybRnskxXOc/NiTdSvqdqsrEVy2Cx HFf5iLDsBMnI3xuOQ+gKI3QlJf7u8GEZS6VbVJ80aojcsG5Y1fN44ifkinGJqJwSJ7+leG/+ AucdquwKZW5kc3RyZWFtCmVuZG9iagoKMTIgMCBvYmoKNjc1CmVuZG9iagoKMTQgMCBvYmoK PDwvTGVuZ3RoIDE1IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyVVEuL2zAQ vvtX6LwQd0YzsiQwgjqPQ28LgR5Kb+22lG2he+nf78xIjp20CQkGWY95fPPNA3p0f7rfDtwG eu9ipn5wIQfZv33tPj65Xx06/d6+daAP7menQtH2r67uTfd1NqKb+vq9e3ky4/qJhenYURZ5 VrHjF/fuIKbZHV9GwHL80e2P3fM/8qEPDymIB3IBhp6rhnesGp9GzAUhjXBApACH8vn44X8G OIkvDjDrk3jsb/uMSgKzctdckjeX5MvGj5CA7O9hgCAn73PZxBGxYDJYSAJLRSiYoO39Hia7 m65BTV6hAs3kCFSvGG5ARYiClXKcdbzzqdJzKOITQRCgQpMVoqGZYJL7pGhoeZFl1w6m4gmS RjRoRJQlWlMm2PqoMeupynOsf+/VCLWnAZJdUCo8e5GVhQ3YFWXxJg00wEz//TQElvWcBmIF tQcUYBaXRaX/SW4TbBsJAmhv6DS0E2Et35rfoKFVmhqPOxzWhEEL3yxectRETH8RqJdX6wEx Sz8TpjkqYSIZD/4aD4zKA4YVD61bkuZdSFfgugQLKRaNq2UvjC1jS/RKiNaREICafdWsJJzt cCjrSGfDViqr8KcmYmYW66tbA+BXGdi2qjKN6pBXVNaHFbmHGuBNXq3AvKzpwQLzcejzZZ/F Vk3WTtpYDflgTQ+0bxHyqeTOunFuOmr/Gl2CXNLMQS5Wl5aIqF6uh2bTTubSaoTcNe0w52XA tmmH7y0CFN6DrxMv1bmnHNvoq0etDu3xOt9O9/fNOwz5wSxgIGmL8yywFfbhrNnaiTOnZQYy F6vjmo7VcKSd1dllATLd7k7EOIO5sztRMoIX3cnZGLMKbtN36YtBwXqQi1MtBS0BtpGFtYdg y4uKrCfQz+4vjM647gplbmRzdHJlYW0KZW5kb2JqCgoxNSAwIG9iago2NzAKZW5kb2JqCgox OCAwIG9iago8PC9MZW5ndGggMTkgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDM3 NTY4Pj4Kc3RyZWFtCnic1Lx5YBRV1jd87629uqq7el/T6U6nOyEdIJAECLSkkE2WsIhAAgSC 7DthExAkyGpEQUcR3ABXUJEAAcPigMi4M+C44yg4xnWM8swgMwrp/s6tbhDnme/73n/fVKru rf3ec8/yO+fc6gXzFk5CCqpDDNInzBo/9/09j61HCL2DELZNWLQg9OBfF5yF+nmE+KLJc6fM GvlEgRUhUUOIa5gyc8lk/OY/PkZIPY7QgDNTJ42f2K3HGgtCVZvgGZ2mwoGtyTsF2H8D9nOn zlqwOCdk8sL+D/DM/JlzJoyvP7i5CaHRDji/edb4xXOnyntY2H8B9kOzx8+aNOT1U3fBPrQn /u7cOfMXbEYFKYTWbafn586bNPexJY/7YB/eL7fCMQwL/VOgytN9wrAcL4iSbFJUs0Wz2uwO p8vt8fr8gaxgdiicE8mNxvLy2xTEC9u2a1/UoWNxSWmnzl3KunZL3NC9XO9xY89evfv0vakf +r/0jzuMvLD6uGeRl40hD0Kpb2D9lpbJaalv6Xlaku/h4qbMitBOtBtPQ7vRMXQCX4C79qBD qBG9gdyoF3oULUMPoHWIR6PgyF3oZlg4OP4A9qYaUXu0A3hpBzoF145Ed6DDyIU9qe/QCrSG eQ/uWoNUlIN6oCFoDroHD0wtRGPQOXYV6owGotloLq5LVabuTd2fego9jQ4xb6RakQn50ARY TqV+5D5O/RW1hTseRFvROXy/dADp8JY6uPIxNA89zFSzODUl9Su0IIxugzawqAKdwsdJHJ4+ CX2DPXgZ0xOe8mSqIXUSrgqgajQVPYwO41Lcl4S5MamK1CnkgncshqduRfvQQVia0MvoLFa4 C6mnUheQFxWiftCfRvRnfJxJtq5MllNCA5XaoDI4Mwf9Eb2OzuAIfoXM4RSuI6dzS1PvIwfq gIZDa5+FO7/G/yJ3wLKCeY3tk7oRmYEu91Fqoz+hL7APt8eD8QjShswhjzPzkAhv7ADLRDQN 6L0Fnv45juODRCGnmSfZ59nLfFbyfMoMIxJDj6DH0CtYhZ6G8Hx8J/4Qf0l6knHkEfI35gF2 F/sXYTz0eiyahe5Bz6N/YRvugofi0XgqXobX4fvwVnwKn8Hfkh7kFjKD/MRMZWqZl9kbYRnG zmdXcWu5u/lvk5XJk8l3k/9KdUytRUOBH1ZC6x9Ej0PPDqHT6BNYzqG/YQ6bsBmWEA7j4fh2 WO7A9+An8E68CzfCW87gv+Hv8D/wz/gyQbDwxE/CJAeWCJlHbiMPkEfJaVjOkB/IL4ybyWHi TCmTYKqYOdCqdcwmWA4wX7A+9jSbAjp35DZz27id3PPcCe4Crwh3ikh858qTrQWtnydRcn1y c3JfsjH1BXLCGPqACtkoAa0fD8t0GO/NwHF70HtYAdr5cAHujgcCZcbh6bgWLwZKrsYP46eN tr+IjwKVPsI/QZtVEjDa3I6UkhvJYFjGkkmklmwi95NG8iH5lREYE2NhnEwB05epZiYxC5gl zGamgXmH+Yz5G3OJuQJLipXZbDaHjbFxti87jl3IPs5+w37DjeHe5r7iZX4Wv5Zv4v9H6CR0 F4YIQ4VqYaNwUHhfrAHufBUdQC9dL/P4PLOS6c0cQPeSYtZL/kz+DPw8Dk1kKghwKtmJ15Pl uJHkcov5bqQbHoQusDGg9WtkG7lEujEVeAAehqaTDumn8Q72OSgS7KuohT0KffszPHkxr+A7 yE+8gvZhRMrgnX9iitg48zY6y5zDArsDfcrK2I1byLPMEOCCl9nuXCUKM4+iF5lavBwdIL1B Y18WNwAfD8LPgV64BXfE/2ZSiCGDgIs6M1+iVWgG+Ri1gByvRw/hiewUdC8qxsvQN+gZkIo2 3Gy+gHfiN8k0tp7YcSMi7C7oXRnOxQznQKtxNfMw/xP5BC1Ep1kZfc68AK0/TV5kKtgL3M14 KkjAcrQW1aZWoiVcJfsXPAUxeASKsudBuy1jOrJhKFeAVhkDOu0gSPdh0AM9mAo44gHOGQh8 MRw0xMOwbAE9wQIHTQMZHwla7M+okb+FNKEpnBmD1kGIfTt5MxqVegZtTU1Bs1P3o7agD9al lsETd6Kv0Ea0E69J3o7moiBIzud4INeHnOb6pNqSevIJGUY2/358gdpR7EHfw/Ii6oO6c0dQ PfsRGobKUxtSHwB354OG3YpuRf1RM/TyR3jDTcxxVJwcRPam+jBzob/n0NDUs6lsLKOpqZlo MDqKnhY4NF6I6z166OXdb0h061rWpXNpSXHHDkXt27UtjBe0yc+LRXMjOeFQdjAr4Pd5PW6X 02G3WTWLWVVMsiQKPMcyBKPC3pE+NaGGWE0DG4vcdFNbuh8ZDwfGX3egpiEEh/r8/pqGUI1x Wej3V+pw5eT/uFJPX6lfuxJroQRKtC0M9Y6EGk71ioSa8KihlVC/p1ekKtTQYtQrjPomo65C PRyGG0K9PVN7hRpwTah3Q59FU+t71/SCx+01yT0jPSfJbQvRXtkEVRPUGtyRuXuxuzs2KsTd u+tegkQVGtXgi/Tq3eCN9KItaGCivcdPbBgytLJ3L384XNW2sAH3nBC5tQFFbmywxI1LUE/j NQ18zwbBeE1oGu0Nuju0t/B4/YYmDd1aE1cmRiaOH1PZwIyvou+wxuG9vRrcS5s9v+3Cw209 K9ddf9bP1Pf2TAvR3fr6daGG7UMrrz8bptuqKngG3EuifWrq+8CrNwARBwwLwdvImqrKBrwG XhmiPaG9SvdvUqQ3PVIzPdQgRW6MTK2fXgND46tvQDcvCe/z+fRDqfPI1ztUf0tlJNxQ7o9U je8V2OtA9Tcv2e/VQ97fn2lbuFezpgm712zJVBT1+sqka+eMmnE5rQ24+RplMW1RpB8wRENo QghaUhmBPnWhm0ldUP2ELnAZ/FVhuKthIozItAapZ0291pUep/c3cFEtEqr/GQEHRFp++P2R 8ZkjfFT7GdEq5ZNrrAbnr9Yb4vGGggLKIkJPGFNoY3djv7Rt4aImEonM1UJQAPnQEKDt+Kqu 7YH84TAd4LubdHQr7DTUDa1M74fQrf59SG8fr2ogNfTM8atnnMPpmbqrZ67dXhMBTm40wK+z QYxd+7doLnvvqV0bsOv/4/Sk9PkBwyIDho6qDPWur8nQdsAtv9tLn+9y7Vym1mDvWcn4SaZG /IxxFphyzLWL6U6l0sBG4Z83mHpikyACVxpHcKhPg1ZzU3pbJYfD/4c3NaUu0LuM4rfbMs1s 6Br//X633+3/rnlKPQMNBiM44JZR9fXy784Bq6Vf2C9TAMejWyrDoZ4NaDhIZhT+m1LHu9C1 yt+gA8l60guA/9KHMru/u9CfqVfBH+XOtoV9QNHV1/eJhPrU19SPb0rV3RoJaZH6Q+QEOVE/ t3fNVcZpSh2+29/QZ0MV0Goq7toWEWyATw4BmhXQjY0EN/NCE9mq2xHHNjNIFthmjLwizzUT 5igYdQkgXjvkiWuXEq2JQdrFREVrApVDXbsCmw5FYWvYGoUNBpN2JcQcv6Jz6DIKscfBuKI+ qW+Zc+AzWFEW+lB/XiasGlVL1F4qV+ooDYwkt8g3O4YFppCJ3CRpgqMmcDz7fe4D+2fer+xf OX5y/937Vdb57FS2Kzs77ku4Er4BvrnZm7KFdiRXbefqSkrVAaS32sfRLzBSHqFOUb/iv3H9 ii+aNexkzCbNgvwBk2BFsjPAmDzFGEWtlqimnbFizapba6x1Vta6wJZ7TDgtnBNSApstlAuD BUbwBkuGeOLQ1eraipbW6tqE1qK1JppReUt5gq7WMqutrEMRqsa11ag2XMpHcmKx0hJbp+KO Lre12IodruKOnUpLYpEcnuky6eSKDxZOf39Vzeb2+1tDLyxc9PTO2xfvWPv4hstPbsNM/dAe xPxrH2J7561XXjv7zkmQuTVAuNfY7kCzVXq39nassTjClrA9AVBPZhewvGQVJVFS7VZJRYyI TQFeAN9VlvI3iVjMCdmxneRYoxgBw+jO4k4lF6gch9AZdB5GaJCt70k6ltW18URrs1Z9cR70 q7y8xVpWBv8YOlaGtDfXmZefpB2ch6uLrcXOTtAzt0C7I/BO65onuk8rHz22+403dhvrCLKx HbU3dX02r295zbzW9+mY9099ywag/fmoM87S75VUqcCr+graqAUFZWonZ2d/14J+BdVqdcF0 dVpBTVG9urbNw65HfLtU5zPe5/IPeo/kn/Sezv+L87N8sZcLZ7uzPfHCgpIytqywH3tT4Qix Kj5ZnBZfpKxT3lR+UX+JWzuXmDGrtc8tcXcMOzzj2sxpQ9oE2pvLzRvN28wpM7fNvMf8k5kx mwOMu4k8p7s8DzoCAQH1zpM7Ame0Ga+NR9FwbhMZrWt5OoppsVCsKLYnxsU6lFEiZgcjJUVl x8vI9jJc5o56ctrnHuNP8ySbL+cJ36ELpWbLxRYNaHqpuuViovWrryivNJe3tDYDQdvD2Voo KW2BwO7fWCfKU9YpLenUqbOxlJbkGUTO606AlVwAmJwOlzsSY3jBTJwGV8FFTGLioel7jvad f1PpjLNTcHHv9SuWZDV4Zp+5a/1zQzTJnXM04L715JwxHWdNm/pELGvV8D7Prxm0cpDDrPpy o/LstjdU1Xpq7x6gj+/fbvGFy2tu6II/yw9o+RXtb6oZPfiG24Bb7DCMddx74JHv14MOCVu8 7b1FXt071/uI8qi6SxV9ar7a4D3uZb2UPvm+7JIsUWUUS0DGThJ32FkGGHKbAztSdp11R1lA 6fdjgyP3d+hSYnCmHMgu2QTvetLjPYoPg/t9CcClJw4UjMcToGW0RIvW0lINzJlIgJ4pbwH+ 7FDUc4nu0Ky8JPAikF6TbH5k5S1+8AriBStX4jhQdV6xNVJaXFrS+TeudTqLnRHrvm3b7L5V iwaO8XfpeHOv06eZhzfUzijpM9L2mNyn5tYNVyZDa3JT/yAF3Fboed0hJENzI7ESiTa3B1Tq vBhhRZUxg1yaFLfIvAvYx6LloBys2qIKTglib6l3jTBXqBM2CSwSQsJ2oUE4LpwReOEwmY48 uNPeyWnxu9istVAl2nwxYSiWVlArwCPFxdqbHYowECHqTusV2htrZyvtgcMFLEA038DErTML V6/ef+CAPZ4f3LFN6z7pCTJhAxZmJu/Z0PqHikIfjWz1wE1kOpkFer4Qho7MZUgFriAERxDx cXPhAi879x6q55qrta9R+4oW4MtaXG0vDTt7kDa46cABKs3r4VEJ0ODUWizXqwdLm6TtUoN0 XDonXZAEJGVLc6U6aVvm0HkpJcnZEtBJYAkj8cwdGPEcz8q8EOUQu43dzjawx9nzLH+cvcAS xIbYM7DHsoPEvkPShJmXoPaFalpDG9GVEmRerb202MmAel3f2NjI/v306ctONnb5LG3jANA4 QdA4TrAyn+sTs1HASYYz1Vy1NNw0iZnBzZEmmUQNaVgjebZPuF8dl3xCB1tXb4dAD1uFr0dg qG2M9+bAeNss3/jAYn6x8xK55NGQC1tUt3uIq8Y118W4ApZN2naNaBrrD8gConpEwg/aA6zJ rauUQ6S8gpIGFau+bMrm0VgJLfUsqjuycbarWMsV9NyCkuuMTOe0kYlXtDYP0mqB9WvjFS2I ao3yFqo2Eq21CYMGNoMCVGnMw26qM5BVQ8UdkdUhhClLdMLhmKE5mLGHC3889F3yJ+z46wfY jK98K+9bM2FD61kyVOky4q5lu/AI95ONOBszWMH5yc+Tv2ihPYen4gfX9pz6DOUZHrDBS2wM 2cheXbM4cAHbRib9raOt91oZKwAnXcoOl2iBrDwqFRf03dm5JSyvSHbeL3ltHItY3iSZzKJN Q3bGIQREvynLnIuiQoEYN5egUqGr2M3ci+nL60KFOMDU09LX2t822nKzbYYwUZxiW8IvFRaI h/jDloO2n/nLUr7Jmo/y1TxzviXP1t7RBXW23SauFbcwDynP4p1kp+kZ5QA6yB82v8F+yH8i fct+a/nGdpH/VQrYGI4jvCBwkiyLJkWRNavV0pQasJ9DtlBTqp8+WbaYQ69aBTEkWG22OCc4 OE4wy4oSVc0OVTWLVoslLosOuB1xhIA5dYACA/Qk2FjRYlXMqmyVWcamKoooCgKIFW+zWMxm JDsuaSquUeeqdSqjNuFndTk0WMZz5BUykZvIcF0abMVzrCusxEr3TBqHa7i5XB3HcHDxAXzJ fmmywRfeiovV1R6AH/Dv87ZC/WuAXRos6S1dwJhkGIRab9iuq2gXX7f85Lp2nv9dxOPxdWbt pGDWEnSldboOaMgeVtmohpQQOQruGIbVnDrTiIosIVtT6jzukvmrGtBQMqzyEBJTZ/YKRdg4 EB42oKEYwDI9en6vEEoftcHRoHEUHnTQEqLPFptSZ/YJRfSJ+1AXcjj9pmsPv3af27jPmjq/ Xw6xIURPAO8DsKcPe/+grQwVwtqUen+vvQw6VAX6AgpUW42rw7jY7u7U2Q5b2OAIk8fgAckj h3eVs8W7Dm0rveHgnmTjkV1tPmJjrY80W98is1u3vH2KTL58liw7cOU06JG1oEeyQddpBlp9 AXOKJZcr5XpzXHl2QzbJzs4JFAduDFAMyne1U0A60DXQVy1Wq5WWatdY33RxpjrVMts123c8 +xPlrPus92/2H9w/eL80UKw3xLW3tHcUceUWnRtoGcJN5s5m/cz+qima08zyBNAqIDkAq2aT J/eMCWsm3VRjqjOxpgXYWoyKmSghxzHehLfjBnwBs9m4HA8GSfYG+2Y0CejOCq0VLAuwDFUk gOvKfwOrcBrQagQ0KBjGIHFqKJKTxzjcv4FV3PbZxnl7b91Tqyf/8fLRGaRk+H2LXnh64aIX uMOtP28cvPGt+cmfkh8+hjcfG373qbfPvHYKNEY5IPy9oHuL8Cf67WyOI6er1F/qlTsiZ1LO MuleaXXuM/bnC08wquT2edxFAwo/dHN+MpwQrSOWPWPEMdIYeYxpjDJGnS5Ol6bL003Tlelq Y6wxz5IXy83LbdMpd5RcZZoYm5i/ILIgty73D/Kjyv35DxU+WPSUvEt5Mu+p/P2xP8VcWU2p z3VbsGyUmBdVZNYXijlZU7ssH9XTgWxvuXewd5x3j/e0l7d4s71zvOe8bLZ3o5d4j5DhYDcQ XKZpWMdEw2cwQVjDBFM97nCV0FIPmq0lGLcbkzUzi2QFnAIbaGfK9mFfrle3e0q8gB33CbkF cOVLgbIzBbjA15HeFQObUNPxeEdS3rGuI+moYYxzUSjXknMO4XI0GFjO2+GqGaitAAjZMm+Q ASOpJbgYb5lHB7GlFoxBPA7DZwzsvOY0lsxASUBEel7bYIRzFMasmk2zawyfo4b8SMoX/Jhr C5ugA3bD5ogf5URURWwj+3F+niTzcdaPsrUsP0bxONUm6Q0GeYoXxFeuXIngndTwVts7u9JM khfLa0cArxrYCgCqEDPgFfAQLMBSDgPQlu+z3HX7ssWl0T+8tnVwjy4F9w1b/vIoa4Myf9qy 6S5Xe//qYw+NmPba8tOf4BsCM+ZN6nVDxBPt2G/loL5L8rPjN90+xXPzmJs7RwJZdjm3uMey MaO2jXyB2qYhwGktwGk+dErvKyk4O9DT3tM9zD7MXWOvcT9CHmEeVp/SnvIpouqVp5NpzHRu oULVMFgJ6aB8QFFcylrlS8KYc8ZZ5lhWWBgLpuzRrwjpaAiqQXPRJrQdvKQLSEIWiwkh1gb+ owdMfMCCLbnmHD9FiKZ4NlgCGMl+AWfuaQFTg06EDv6SjF/VApt5mSDCIVBy4LW3zLuYGUoY SWtZe60aPK9mKpRA39qrJj3jQF6lKaU4k9ib9dOLZ5P/mvfdXbv/mr3Hu2LU+ueeWj39XrzG /dJpnIXlFzBZuWeHf8bMV9/78MSd0L514Nh/DVRyoXd0O8fwdrJTa9K+ZL6xX2Au2XmWmu0O JrVkiYa3aGc85z0pDxsSHWaHyxbgwJF0qbJqVsy5Jh1cx5QJw79pkIcys6+kU0mD54KHzPVs 9zR4jntYD0OKna6Mq2n7X66mO+NmJgDNG75RbbwFOAysmOFwYluafV28VZJFWZAZXotZebMf W2QbZUrgxIKVQCDKh4YbmnGKrBFrSZpI1nVPLPysZscQTW4smHHT/GfZ2EN7es+t6Li8dT5Z O3tWj/vfaT0KQrYuOY0NA01sKIhO608rWlvtBm2AxpaHGkIkO9RGiWR1dHbMujFrbmhTSOzq 7urv7+7vrxJHK2PcY/zTxRnKNG2We4b/eOg9x2eez3zvBZsdzcHzoVTIFWHjWtxZynbV+rD9 tVHaV6a/ZyU1k9UMiNFwzF2gzpHZm3tGxpqsyzVynczKC7C9mBTbogj9V4WeDQod/zeNbqh0 a9n1Ct2e8c9dLqeDUOnLszLXxR/WPdX1/qnrz0xfeO72URvbWZ9ZtPj5ZxfM35ucxr1cP3To htSWJ5OX7x7YtfUy89Spk29/8PZbHwG9eoEdzAN6qciLXtGrbYLsVfryN4kj+CpxCj9NFEu0 rraurlJPb22AbYCrt2cMN0a6Wau2Vbtu9sziZkkTtVm2Wa6JntuwU+I5dTRzC3eLPFqZyUzi JskzFdkdYAVrwGRy5AqUdey50ZIiASNBA4+JETqc82M/Pe6l4BnqACF1uCQblUPjOvioxgTW ircAaK6+VA0VQ7YAJ1CnGrCCLg3jhkm3crdKLK6usmudgT4orZyQ/Tri9Hrqrj99il23//3u c8mWQ/vWrd23f826fcSO8+5dlPyi9dTf78RBrL7z9jvv/untt4C1O6e+YcYb0awKXZtEpvAL yEJ+vboeHFKwFtinh9mgRZJiABpjpuqQHYfsun2IvcbO2nEMDbAdrKINp4GCSyAItNUt5XQk M/q1UynY5rQK7bZHmDuh3/T8E1Wv3PnKKbzds3NZz/l3MP+44m16a/rn1OcZxvyTjAIf3QS+ 6sf6mG1g3MhPwk92ck44ZyenhdN2ckw4Zid7hD12sk3YZicbhY12codwh51cFi87yExxpoOM Ekc5iCIqDuKwi4JbAa3HWH4xM78Qs0qwklBRQoWeDdHb2+cIK4SNMDrY3sWRMKtKAuCu7vaV mBdioYuYIBglGGYjwcTrqX02bdIo7ya01mbtErj0Rg2Vg1dDPXsDv0KJ08YMaW9SvxfNq62t xbWZP1yNnRHqyHcGDSmEr6tjxyuhgtGFnUsY/MDVGnvy3afXJoa06eMePfK3GlBqHt7BdmV5 w4Ptq+dxPGYFCUUZHGWIEGVZPlpE8DZymhByjEM+CXvFkaMMvzjtFoPk0aYmjNYaQBs4LVwa tsLKdr3ShXmDrszYna2P7KR26inwoXKAS0xo6iGkAhvn2Z0lLBOU5O3yGXACwJ0wiSIHnofA V9eBx0hMIRxCmYAdXIuqlZCKQ+oQlboRbDfgmupaoCElnVZ9iZKS6tBEWXV7IwKL46AdrWFY I7B96gT59cSJVh4w2zNk1K99yP7WCqBCX+Y7Moh70+CXT/VBBr9cEC84CBaxg5wXztvJGeGM nRwXjttJg9BgJ08IT9jJ/cL9dnKncKedzBXm2skkcZKDDBOHZfjFopgY5HjeTjlEUYFxzMAy WHxeoAeKMLARQQmMzZaEAlyTp7q7K4pKmUZdSAiTQMA4eSgEtnS6wTMg1Amq6xIGwzRrRh2k xAjAtlwtf88y17iltha4h4Yvip0OgRfyOnXqXHxdfeQr2fHRhZ1KmY+vVth/A5t0G9qmr2vc sN9qVLZuTA5lvgf9F0QF6IJeYzIBuDJFHQNNvR28lOXNKjTFHIWRMlMnR39TH8cIodI01fSr /LPT3C5SmNc90j1vYN6mwu2FQqdwpzblhX1MfcK929wSvqXNNGFCeEKbmsK6wrN534Z/jPyU Z3W7eGcT2duYH7ALBhrRQqjIwCJ16DgYUhppWK734AIBi9w7J6DILmdxtFiOejxn3Fhz6+4a d52bdS+w4CjKyc49ZjltOWdJWdhsS7llMCAcb7xwQZiGs+ODjHA2YEwjot3afIlSlsYoq5tp SfkITG11rZuCOSPSmAeaiKTj2u7Sq5rpev05eY+pY88Fy9d7zHhRw6cXZr97z9Glz0z6dPsf v9/6zPJlO3cvXbyz0jc02nHiqM4Nd+PEZ1sw3rCl7sr0f59e/DxT8O7xY++8+tqrwPjHQGxW GjGmBw4A+BYJR6F3lxtKjLK4JF22LUqX+W3SZSSaLrOC6dLjM0q9vaqVhLhN3B6OYUKARzYC qGtAbHsD5Z0DdMfZQnBwE7zuCfZDQyVXg9HYVwegrrqKxp+q45k/GojqUESl69gJ7vCvfaCt TwAs/NaQ7tG6k+eC1PtHDBsExSdLQRMSDYsW0Gwlwi1M/5AcUonsU1kpLeLVSrfRV3UjzaZc qq642Bw30il0BXhIpZu+MuwMZ9Yn2NwrjzPxKx8wq7nDu5PlLyTV3VTPFEFLDkNLBDRYVzkS ZBkgHU2qS01k/v4Qi9kmjF/iQ5i0ZzAD9QM4rWbgrHhwa1rcaEuAGaq/1gxkVn41pVNK303s ySy2Punn1N27f/0nfScoOHYNvFNCA/QCo/cbBXyNAPD6R0MkZCLEZ7rWY7nbmP/ocXP6PUaI 6z96u5P57MpXpKF1CO1p192tk2GQhqW+Yb3ccdBbEejzOb1zqQu3cfVz9Yt9rXxXxElFeDla jpexC8Ra0zxlobrUfTeqxxvYteJK02plrXqP+x3ra3ZbDg09BEI+WoRC7WnRNhSDQg+2CSko 6EGKP9huezvczhYO8lx+0KYG5x+TMFBziq7F51v0EKARC0YWzUIsTfi+gx098xsoZcmUfbnz nXTYzeFIScipO4lzU4fX786glIvVLRTJGZWME1DdviWTbOlQdC0GQl0tVItpKoniOcArAgV1 4KUjOHK93DEO13VO+/S5M78+dvz7GbPW3ZO89MknyUv33bp2xtQ1d02esr5rv03DVu7cfeeK Zxl/my3Tt589t33yQ20KT64/mgJmP77xFXzL1NWrxk1Yt/pKqmLT4Gfq7nxuJ4xZAkZZAIoH 0Td6p25cN/4Id4w/IrwuvhkQ+ilVyi3mGcpE81LbUvtdtqO2r3xf+S/4lGOml+zErwW0LC2o 8X9MXUBC6jwSoZTA5fAFZU3k+bcCPkcg4BMDPgYT0Rdg1KDWRJ7aP9iKrU3Yc0ANOjgUbCJH dAsmijzf/R5wnQ5UxUfISvAsNNxFV6wHysk4MoesICw5THJRNt64N01s0G7UclxsSUsU1W3W dIzMXbbO3C5uXq6dxOl4iEFxuqFAel7UGY51pmmYDFGpyUiPAS/APytc6Uzc0Scf/mnn1tvv fBQfsv/73fcu3fTsiSfGBHfv7pGYcPyOk19NnvGHR+vtpz/5fnflc0efWj++A1DyueTneBU6 hWQ06IAMAOR5nlrGGGYShGAZJ5BMgIMSiO8idB2MxqE5aAVoKw5tN+3YAj26WG2kCbS0EfzN /IHIUNOWtmwHTw0Z2bGsE3PqVO3dsQrv+NFgwXYABtkNcupBOXigbrGZzNjWKTAqe7I4K5u1 NaX+tt/mK4Hywv6cvBIr3c/KK9EypSVTwvmP92fF0ufhei1T0vP6fKhEzf0D/UPDTGMCswLz pMXmJZY18nrLQ+ouS5PlW/M3Fs2sKCGrxWG1WqwWRbL5SdjnknmbVVMVziNJLrfPG3S7UTjH 0B4eD0BKMRgzP8pXh3Ln5tblMrk5nowaiXTb+ZsaARTkbfa0XIuHGsoEDifK2hvDnR5tDkY7 nUvJ/CGq53VZ1C1lFq2r1daVRhBxbSa6+Lnu85ZZc7xlNljNeqBMy3HAmg2rsyzzhCpQVYar BbIJdtIeYdqRvFgkYoXDad4J7yD1J99Z+tZ7FfnDB6Yunhg+e2Tb8IAv8I41mwc99GSyiDs8 +I0lj36YFc0dtDBZizus3tDFJLQuZIo7L+k7dS1FH4+D9LXC2KkweiP10knWGQ4yQBvgGK2N drAmJUijzG5PWt/aYqIv5MPw7/OoGUp5qcKlup2q29rqSzSncNW4GHCxGlXTbhgBGxIOG22H pkM/wo+TNvdXzLy/6sfkm8n1+Pajj1cP7LA6eRd32GybdHDWkWRr6wsM3rBizCqnCi0dDprZ CnqCxksPNPIhrxYAltoHFuCPIPouWG2wWkDF3sry68h603rLm2ZOEkwe0ts+0Nnf29N/i32M c4z3Zv8MYYZpgn2mc4a3xr+E3MYvMi21rOO3CJu1Nz1nyYf8h6ZPLT5fkOUcQVV1z5eoTiiS MJI0iUibsq3z0TX9C3aeoE3Ba/rXiEJccxEpxkFdrkq/XTOCLi6bU6POc17MrlHNatVACQj8 8BnvbV+0b8GN09/b8f6S+w7tWrZs1647lvWvJu9hFt/wwrj9ydTZZDL56u4tL+HHkg/9dAFP xdN/nLaWWspVqW+Z88YM6pcPIR/NDzndJSRkd1HxuaC3sTlK4nacK9pdCra7TDySrQHGhIpd UY/bCL248XE3dg/yGV4BDb34LvjIXN92X4Mv5WN9SlS6luCndAhJZ6TzEisN8l5NpMVbrkZd Eq3G5AXwGMrS2qPnEt3HambVohJeEHlwRhheYxU/UkWrH9HIS0HBSlCMwPGZ6Q15McM5df/m qDLlyz4Y++RgzdRoss4eOvTebo2PNt40a3DpfHJ/6/57OvQdOmzjelJ2+SylBRCks4HvNhxC HEC1zl3SkK2kNF0WdUiXOWlIp0eBVhYum9vGnePYwbC5wDHZRpYkxbEA6UBrpqNO9EnGyPuK S0u2IXwc4B25LgTFXssqxuPpvKLBAvMMYaa4blVjBtfRuBnFdQ609xCw7nFdhTZE2VKmN3NY ZRmKE3Ld3hK3aFWsDoYDGBDgBIdJhnEwhkvCxwErDHLRxrjpcLkuuMhc13ZXgyvlYl3E8f86 I8N5bcAM/642fjHNr4l09P5anMzMm4WomVf8WBUtmfgYjdGm3b90CMgIjYH9oqGxxjuOL3px QOPCGUPuSYAz+I/7q596tHUc2bHu9mH3Lm89Am2g8hvmngE7/72eNcC3JKs+a7P9WfuryofK p35RsnvMBT5GKuKKTDRfwwAJNLvstNntb5ktDrPdYbaoYLx1u1kOOnXzdjMxmy26EzudARuY 8JcsLH5Pp4ATe/QIGwyo1nHaHG2FtlFjtTphvseQYQ9GHs1DPJtCtqO4FFnwg0jFXfaZD+DD uAtCQDHTb0Kd3YTv33sNV1Fn5lIaWFEDaTgyFFRaYQVT2bxOTNsAZPC8YezxdcHstJ23A+xk 0vEhgXL68JedW2fe2bh7w8gN+bvuJZ+0vjR49X3HsbjgnotvtOI6rf7uk088vG9wuYv8zwvJ RWOSl959/b5950Fvp1rB5lYZeNyMg/qE9lqRNkWcKtVo65lN2pvca/xx7YJmErkqPIIM0aaa GrR/Kv9U/2mWWIVVWTNjkiWOZRXVLPKCoEBd5BWBMoqgOOAAAW+GVRxwhRTkODHIM3wTmatL SFS+08EYkMPYBKDOpNuUEJokMDcPYU+z51hmU9oR0E1DlOPCOYXZpGCF7msW4bRAVgh1AhH+ YPnwIwNu1HphhX9Pi9bi82otLchTnvC1lDcnKAxpWce1iwNBaUIxg6RoOGSddvKk+eTJdVy6 BFIPaDBlcoCNrIURhcOAAlHq30aeD8+rrY5gmp8LM/YwE8vjBYYUv0sqP3u+9ZEdn+D/2don J1BMpRIfTfYio/DmQ7fdczew0Tkg8mWwNjKar4cYXbWWzGBXkI1kq8i+wGIJ8RxhJA4rBL8l pyPSlL+QYRR9CqerlrRyoUaiiMMhTucI5zUdxgm8BqXnQdTGM4JozHErp1Aik3qPhyNWAIKl NKpALjf2eO+Wh/7WfgF7e/dl2S/2fWsc1fjrQYP8m3qG+B3dJ/Aj+FESY1H/yV3imeHMbTKx 8SF7uESkoMuWzp83QmnjjAPhdEJ9NRzhWZZj+c5SX5aL8m3lSvk2ZqF8lvmSF57hcYSPCVGx jO8ilauD1Sq2iq8UqqTl7BJuq/Qa/xf2Q76Z/074F/+L6LTJMnjALIFmS5IIO5IoRgUeeIln WDbKyQ6Ok2UJdkSAEsZnT6LJhGTgFss+LkeEQo+EjOyGb5OKVVMUkSjGm66lrhT1i3DfyZnQ QqKChvMAcICD13LxN2hWnqBoDPiGpYzDAedQEC5oYkJMMMY2nd/VZakwq0wSs7ISfFPq831Z ZVC8vy9kFHvDaQBWVU0zvbUoHjcwG586vi9cBrr5+D4XLT7fp5Xx6cLYU4xirymD3qqoPaOv sn3GYtHhgrc5HAljA3dd2uehN/+w15++HFdXGTF2qlyBXXEEC9b1jfi575LT8bHPkztWcIev HMUNyUWtE0n20uRo4IB5qIXtyh5EJtRFz0azJfKLyMzmBF6aLbPyLxyeXU4GE0K8Sjq+eBGc /wSIVXMigdpfpHmSDkVR6npb0w4xwQAQNz6HNyZrW/D9O2m5Mzk7bav4GNsd/OHXDoF39bHe w6SCrWpmm6Uv3F+FuA+4SyHiFkMRyeMPSQwTCQZ4Z8BkovmICIi1fCaKN0W3R0nU7faZo5sM 56v6gCe6iQbecbXuRaQ4EsVnEKYZMUID74PBentzo0148f5w36vxpHkgKM3QD9DArYN6T+r1 de08ROdrAdQw2MGanp9w1YApDnvMoVj92KY6rxowQ7iuTjJ0uQ2v67oEz3X2bEfHZ6Yveij7 jrcef25/ZEz3uQ80Vk4cuLIrG3tw0LhbKw/vOdiaRx6bOa7rg0+1PkT2LV485OH7Wj+hsk8t OyAxGY99qRQMd461TKbZYtVaJrlsgRKRbkhT6vv9UOJMCVd8rEvBcAnKhw3sfatLgE6QCzaw d1Y/kN+uBIVgY1HaoHwpJpehUvkm1FceAeq9SqyUJuPJZJo4TVqMbsO3kSXiYuk2eR1eR9Yy dwnrxXrpMbRFuk9+AT0hv4xeEvbKb6I/yWfRB/IP6Ev5MrooF8qIkz3IJeejmNxZHoxAQjjd 5irhdBhtGYQ1KskOSZIRc21+CsgzkkHM6XQUQZYYhLn2oO5zRF3XpTpAyk3Yf0AHGEU4qOlS iOg4x/T9X4y0BJ1k0lrt87Q0V2fmlFwTYqshwb9NJQH/GQSk9jfPynCu6AQMlzEDA+MXkzP/ 2BzN9sR/OJSczcZaV0+Zc8sisp7O18JoWXIoqeHeA7/hBl3Os2Ck2QRR05pw8X60zQyKp1i3 CtvMYxGjMSGGYV6wPrbBMPqtl8DiG9DI8GNwjFhpSqAYnHSBd2oYn3vwzxWjjq5ckndDBLgr OfQo/jc2/3i29fKZqvrNR15OZidDoLkaoBEbQVNzSEIj9wa4JrJHj4kJniBeNr3NSF25LmwC deG7Gn46jU+/LcumlWHqk19NbAC+aG5tbtZ+BDtRobV+PWBY5X6OBQNMKVbVochOp6oxDLjp 33Q+V/LkaTyTkXDv5JEr/0o+cOrUf1JBySf5GpFkDSObROkgb2MwpYMFbWPGWszZgK1esP13 KtgjyEoz87G8Ypod1UjrShCsnBvylq48OqridHIoPo+/OHpoc/2ov1xuPftj8h9JEd4+itmP 8wwaxHQn4hjM/UgQszKEN2GCp/OZcDx1mzJxKjvtC7O+3akiuNP288/JH+Eph6Ej69Ap0A1R 3UNoOCORDmLsQex2OL+dNeIYl6qNJ6XDFodPpfs/BtDn36H/RSipPzqBmcDOZxaAXcorZcoC PZl+wsCs3tm9cvvkDWOqhDFZI/Pvspvz1VguyWXyop0sJZFe0d7tR4VGRIZHZ5qmqzPMkx2T PEtMS9WlluXawtz50bVMvekutd5yj7Ymd1X0fnWzZbMzGM01qyYuHMgK+kWBZxnC42huDhzj uaC/7Ubwo1tcqK2GQ3gIrsFzgRo8jEODHm0bDLoYLthW8sd8/aUYaoPb+DqGYzYcs91CEYa3 w4RMZLei2TCEV+0guJ0aQFNYL9IwFKhEYyJwZh4wnQBg7xwkxenwAZ3zYgQA/3N+Bes2og6A UHNjY15Sx72xfM5zw4aM6ZacOXTalDv+8cCTv6zlDlt272rYUdYFf1JZt3Tt5cdeT/5zK/5I m33PyBvn9+o9JeIeH+/85KQ5r0yc9s5K8933rhw9uLh4Rn63A4sWnp6/4DsYw80Isd9lZusX oJX6EJbtExkRmRyZL62W+Gm+hdxcab5pFbfKxOe5JMaTVxB0ZUmS3RYsKGjTBgFRAYdmB4NW JHpi/C3RmOIrzApmwhLx68MSlzIY4Xdhbzo3gk5sMUhzNUrhuhYINZMIDndMh+hikTCc69yd pOubSWzn2/MnT1mzcWTdKxuSf8A3rOzSf0CfOx9PfopnjY31HNX1lgc3JHdzh6sOTRr7THHe 0bope2s6MDdbXZMr+s1pc3m7oHSZ0efmJR0oXz4KOD7biHF/v9dmooix1O4sESn+FkRATyIR GEaUWEIkQWSZEM9z1SETDpmGmGpMc011Js4kSqG0t6fAnZkoeDrRkPHxLl5L4hmTwgFDs+3S ihVThNIo6n0MXHOwT5mod0xXO5YJOd4yMFSfH/RCtWO6So9GjKpuipQJZgesdrp/8aAdqlnp ahZUnbT6773XYlk4o7czca1iTBOI2Pro6ww5/PqVJHf48kp2xa992LrLdaAzb0pOY84D5tBQ AP1R32IicVLg6UYGkCUKX+4s9w7wbgpuD3Il9hJ/ebCXvZd/mH2Yf4J9gr8mWBd8n//A9jX/ nfK9R2tDcpQ4NKVU6Uf6KKPINPKJ8qnnS9d33q/9V4gFs6rDFzAJZt4RYE3I7DYXI/rNhgVr Ft1SY6mzsJYF1v/yzUZW8Hd5rnSSi86t/s85E6gWWzMTbjplMlu/+2CjsOCh4S8nf5rz3h1/ qn2iNfzC4vnP7Fm08MnkNCJ2G4TbYWF7ctUz9/7ak9l96tSrr7//4euUZ3akvjFyvg5Uq8sx SyVbKb4pskYwwAUsUMJ2E/uw/cVFlme4by2CgujkzyN6gJccMVIdcuGQa4iL0InGdS7GpcZC MpaNOcVwr1ztpLwDmiVe3VKhVVfXGhG9lrTyB7OLi60OwoJiIEaIxvBurWzNiYnJy+//Ofnr 3BN9dy//8CCg1b2fJa88eS9Wv2MGX9l37MCtJ7AjE2/kRkHbLSD1q/VYKBv3FNOibNWCFiS6 YyEJS77sLC0jycHfJDltIjJibIC8Tow/HVFiRZb3enwewptkRVZlhne6HC67i+H9jDuMbWbY eMRAGLtkaxgZ7FgAfytxOjgJpszmdBAQ+mi4YyYwb0Qo8S/Pj7qjasH8QUvvO7UmuReX3fd0 h94VD80ctDv5DnfYmTXw1uTpk88mk7vGd9zdqUPv7575+l8FQTpGI1Jfsy7wH+PoPT2fU11q b3Wtyva2jrQu8jM3u2Zq0x0TXQvVJY61ar3jLv/TqsyFjLiPif4WBCvgiKpgmqygMY0jmH6+ r+LSRkVxsp7D5CnkJVP1XGcwwLHBNqpt/rjQnBAJ1QnzY0acI4bphyUktqmtpwl32ed977/F Nwp/H9+4Gt1IW5H0xySGMflt+h+meSM6M/z6sIbQ+foIx9XZQdfSSbERjdkPzlix54nlxQMd NtP8prXTp21wNIa/f3HxWzMmT7xzU/LbD19J4VWeresa7ly2w/E4Wbx8wp2rV4cOvD5l38Rx j7YLvnzv8eTPX0OLJwDff8a9j8zIj1boNT4LdmgOh9/t97OsxjpMbpOf3eU+aH7NzLjdHj8J ZenWwfbBbt1XyVVKI7Xh1nH2Ue5xnhG+kf673VuJ5g0yjC1okpyxkIAFX10WzrLEDPsamJDJ I1aAca2m1vX6kC6IhV1D4Y4sZRpDGDqnp8iXEKACmoDX405v4z7PNyYPHjudPLzzDZz10afY v+S7+/6c/Ii8hWfhx04kn/7rueT2A2/gUX9M/it5Gpdg/35s+kPyK8o94eRQ5kfwInx43X5L AFuown0qUJbvGGHZIzO6qluIJZRfVKLRjaBINpfqseWZ8pQ8tZPSSS01b7Wa8m359ptcVbYq e5Vzmm2afZpzCb9IXWJd6ljqXKPWWzfYNtjvcmyRd5qOakeshx3fy984flZbtV8cqUDQZrEo mtVmA7zvddjtUZvsgB2LYrEqUZPsMJlku82mKCaeCXgtKKAFSPvAsQAJNJHyAxa7btMdTeQW 3VRu021knO2Yjdia8I0HLTgH9fbL9JTNEjLpekgpUgYrzBAlpRAFrtjf3gKdJeWN/tAy8PXB e2ylASJwE2h8yKNdbPbSwEmLz6O1GDXkobqJomDqM4jXe/00ELfOrCUS4skBDeZhAxo8Q0dV HkFK6ltkSn2Lr5vr7QDL1rlMzulcZgbX64CzzJrJwVTRGA0CzwNwb156mgIsvzkeNF0XyVnh 6FaYuMltjXGm5KwTn8VzsuNfNiZn9sgtWjaiJDlll5af659hyWLzW7cuXLlsEZlx+Y09N1YZ cz+cgEqrAJX6UTbuoK/Lz+qSRSRWyiIjLS/ZXwq8bn898O8sHhMnkljGgSSOtyJJFDQkmQTN LyuC5lEtguY223ir22xnHG6zizjdZi9xelQfcfrlAOPwy1mMw6MGeatHzeatfln2+6NIAnUs qR5P1G12uN1mJ4k6GAZpQtTKN+GDehezWVVlWUJ+j8ftRrLT4bBq3c3QYYZ0R54HVPcDatSs W8sGm7eBu7AwLD/glx6A54IlOWAtS6f+d+wP7ZqaUTDNWvO18mKCDpmx/f1XBq3Gl0k0c/T7 4J/lP/6oHFbXuu2R0mJ7uDRsL2boWuyMMDTAGrHTYJ89PGXkrtf7J3/C7UduHom7jXxo5O63 B2BX8p2Rm0ckXxu5EHcdkPyTFz/3IJ7xIN6dHEbXB5MPPpgcgZ9LjiDleAaMUAWMkBP0OMWo +/S8GV7cS9Cdvby9QqMAis9gJgoTxem2iaEF4sLAGnFt4EPxfZdVAEXemBeKhMJUo1vzg7o6 RCWq6vDj98YZlJmqS+ACcDlBB53x1gWcogPR+Zqhu8Er0zSNaJsKZaq0g7hMl8vd49xz3Cvc rLuJ5O6PZ7JNLVd1dkZlV6c/AGy5Gn6mqlowvtWhaWWqmW2ZeYlWY5aiC1+f2mcu7/cU9psx osfwW0mPo1MaW287s/qLZPNjd327+7PWzoPvHTTvqSduX/ocO8w8vaiiqPuPf51Qk/zXX+pb 7sAD8DK865WdJ658Vv1cVdPjW/bsobx9CBTZWtBhdCZcFz3EcogXJMInWCaBeRZ8t/Z0hiVl lB1iJv+cnnWanqdXlvYDqRsI6yFw45iqU6euPHuKfgcwHnwHF/csUtFc3XxSBRyHWSKyEqMi CnWKCGYlRZ3PMISSdLCRwGeIzyLOl/6OBuNxeBxhyqGYg1dgFnvNGUtoTIJNVFykDhWNy2qZ ZCbNi6TD+rXGF2s8Yngh0slm6zyeObAh2TKgk+UQc+c/72J/3b3hwaQtebnp0934e/z6o1SX TwartQhkPAs16TUTyPQs6HNHdQKaixZk1aHVWZvQw9zzzNPqIaZRfV09g5qz/pllNduyrFlZ TAGfby0IhLL7qiMcI50jvFO5GVm32+62PcxsNT8c2ImfIjutH5jtgAR9mkPzsRSZ78svMz4i yMsv0ywIs357UGH8QVbSYpb+KEYDDL5sgFkiFr3B683cdT6k1bD28Xg1tXaYfgeWhnwlttzi jmzGUyROh42yD9t44obkq1+1JD96ZA/ueeKvuLDbseITf9j15ZhZX6998m+EdPjp8it49l++ wsP3nn+77fb7n0j+dN+R5Hf1dLa0D0ZSAzwow1he1DvZKpWpysPKLuVNhRvIDFQfYBkbJiJS eEbgZBMjIEVR1bcYFpQVC6NNFJUVmCPkCBIRwdt1GbEsXILektkmMvkljpP1rOwSuQl31lVB z4mUCHXhUmGThVAKgUCWIKKREPDGAeCBDQYa+qEaZCsevxhPaF8bflM5aKpLiasfLK9LB5fT SsgwHyrQ3FamNqXe103FZUxO2zKGzcpKZELIxiwAh6KbypS6IWWKHitTcgJQts0Emen0J1xs fHHJWDHZ3LqaPPaH115rTJbicU8zB6/0fzq5g7DkwVaqjcYy+8ltRhzFhBYeolmOTBbz33pO rE2JiZcFDrEYcRxv+lESRRAAJIgJ2ZKOx9GMoGopkT7HDJsgmGY1sFfJTKA18hBaqzHxM6OV W6mGvv7DyHg8HZgpNrabOp5q+1kHI0TjvnAh+V16izK5eq8xp6cA/LeSrr6BLj0y2jUyMpmZ 6ZrlmxJZ6lse3OC7O/iwa5fvqO9719ehSyH7Da7HXbtdTNc2E3mSR5OAEdCennCID+UHB5vH 0YxfADQmh98bklaijTTPl30YlyET6FDrf+T4CqlmbaSK1XotXW/VrcS6Kf76f8LelutTelcV qBEwSUNd6vvn8ekpioD0XDarkcKP4ZLfvp+Yu9u1bPyw5UM64U5HZh28goXXNrbcvvR/nnjh LHn76QWL9+1atnwHHqYtnT1wxcdzFc+IGVj8+BzWHk5+mfxH8pvk/hePMSWPHDz56AaqPzF4 SIj5H9CfGr7tJYsNW8Adp+kGHfzxUZbN7GYRVIDlOHecPy68bZEsuqvMx9glp+rTSnFX00p8 r0lsbxvJVglVpkrzQ3iLvMX0EmlS3jC9ZX5HO8t8IL2rfqp9JdtsYNIFUZIwz0scyzAmi0UD 248tFlUzYSQR1cQomswD5JS119BrEtEy6IEh6msqVqMK41AURpYkYDdeU1WQP3mwDdv6qXco ObJlPC/doYMI+l/S+SF8nZFK7KmbQ8wdJGcwdLSfddnJzIQqIyoMaE/7SrvY8nX178ABRQTV mahwdQbflVks60Tjw8L0FgrBgHyZPE+j2ZNVZjLCFVkgd26QTrexvy9cphkfhjvLcE64TNID VwMVFPSheDVNyRRjXOymUK8zzcgwediCVye3fvFku0BhdP9Hyfvw3Z+d7Zr8juTj5C99i24s vpxUWv+M+1clq+nvXVSmPufyQO9no0LUCd+gv7HUOc81z7203dL2a13PtP8MiZuznnSRu9qv 6kRWBVaHSaML17jHh4nLqbumI+a54FkXmR+Yn0UW+ub5yUJ0u4vUu1f5yS7niy6yKlgfIvXy qgB5O/RaHjnlOuEnh32vOci0ToddZJp7UjGZ1B6PKB7TifQpHpVNKlw3+kmRryybxPy5IYLa tg22bSfLyO9yZTlDLlcodFhu65DltrE2Gi5pE+zKmPxrsyJja+xz7dvtTHu7bif2v2Zt9GBP ExmlB7zdg/NC4C916dJm7HZggu0dxlIfanrn2nQINjMRsfliSzUUUG9G5c1gWa5OjBPMiavf hxoVA9H9rz+UKY3fLsijocrOv81Y5DCdny/QwCW+OpWO/oQBBk7OfNF0quovS79YPWPPixNu PP3Y5mPJv2OhrfdI0c2T6pbMSgYX9h7Xt9/4SARXJA/eP/neO4fu3j1hwpZlW9d/OmzevTeu frVp5bsPJPdWLsg/vmzt6I19mDW9p5YPGDe2V86AgtZSvHXkg/2qjk8CbTcKbJgCIx1EOWi1 3h70mp8s8y3zk1t9k/xkhjLeTEYpt5hJJ3MvM/F7RYFFWp7VitQ2DhxENB8QCeeEE9lydiIn J5QIh4NobHC2PNY9PVcbG7Ji6/QIzeFRqmqXqMoy8uOtxjS9SwlDZzWnLXaGZjhmfLxgBCyv eeUsdcrNRKCqG3+Mg64OuUe6PHXb/Ic9h7z/evsjjEatquzkI02n8LRc2/SKrt3iT9/addq2 TVtdp85+/0zNEwsG9a+ZmXzIwF80dltg2KFiXcGEZYIcEo1JwORZ3SwQJhO84a8L3hji3JrI THEOOzefIH/hDv/6z910fkrqG1IGFGTQsEOIAfF0pIOMIUfZQwwmzDZmD0OYRYjGkDDBcJ3M fIvIt6Dhdx2Atuxf6qHfE9JvGo04p6Errk3Ic9KM6q5NyUov98Ov9AloC0K8hX57ixfqKxCx iA7iF9lFylrlDYWRlH5KPwvTho2qheZKZjS7SF1sXqeKJsKJZWon82AygAEnQKxQbzTLW8hW ZrOwWdzJPCvwNmIxm4s44uA4IgJOKeJEqIrKzZab6deeRKQ/9WlSVbNZQ6JEamx14BgfJjuR ijvs40JiEziBsiLJIV1ZYcKmw2QEMmMTnCFN2KRLFoxClrka1prIiJdCXE36O26yc7+Vxuy8 dAJndcIDpDa8Zaj7ru00V4OnXJ649i03XXxaS8v/yrT9NpniZXCVLyMx9SEiqQ+NuRQDGhQ4 l298aqim/r3XLNOjGQz0/sFwmbkwbOAg8KbNHTsb1QNt4WjbqznxebVGTp0G3TBVrDhsjVhx BFu34Fw8usjlBdCDuSPJEXuSldzhy/+476YhjzBXfu3Dvn25lD1/OQRjl7qC32LnkNHAA0Hd gkvp70sYIRuDCa7/fQkGkDrLzsdv3XcfHfNZgMMPAY9F0cd6b7/D7yQ1eXisaMc2JjcXhW1u EkVBAsrDHTQz4SAvYRzLi+aGGCZEQnk1gBHn1eXhvCwjXuqNXUvA0DDppfTXR9T9uvrlZcLY TcfOruake7ERf8AX8AYYXolpUWcsOyZG2Vgk6lGzwshlsYfhYoc9JMBeDhcN44DJHcYOK2yC UjiMchnYoEw43fh+9upfgZHaxqXgvV+P1EE3tiM0oy2ARrSxNIJhZQaSWRuTZ7Z/nNzWuB8P +XQbxvfH9oRvPThnzYnbwl3WYXLfHRe6k/IXcOv5efMP4bEff4jnN05peqBobl3F0NWD1287 mfx33fjO2Eqp6kVIWETn/uINeq82KGZtY4t5ylAna5mtk6cf6mvtZ+vrqUQjrZW2kR5ti7jF Qn/0lv5cgigCoFcUSTVbLIrDbrPRn771OJtSif0c8oRoqdistNRHOUUpRH8ZIZTOPHs4UQw6 PQ6n02NTJCnotEHVZlUslpBmdWia1SYposfJWayaggjnVDjGo1ksUjpZTTw2G2hf0ed2+7Qe Eh6KQkiBrRNWHXF46MEQdZK83iZ8997MPGCftwJwSWsrABSPMffgv/46QgYoX52p9P//8wgU tCROXq1dvwFhs4CwWUHY9tlkT1PqUloCo3CwwJBARD/2zcirGY7sV3ROT0e15l3LjkNhS8eq IphOfsL48eTtr5/L9XWRsfv7vwyOBNp+/Wpy9pHk23mC25F8kzt8pfyhB/+ey3ze6kv+8M+7 G5kXQfqqN4Qm9b38JDJ+o428+0PuuWeGjLMkfhb9ovGLj098mVdw9dcfU1eSQ4Ej3oeqlPm9 Y+M+oXtyEOr5249E/sdPAffn4RA7H/Uhz6E1UPYnZcgOay7s98Cvo/VwbAD3OuKhXMsiVA7r EKivy6y9YL8z/a1PuH4Y+wKaB9c+BfW+cO5GOH6MG4GeYL9ERbDuhGPDYE3A8efguh1w7nHY Hw7rKnjXqswzh3MjUq1QnoNnr6fP5J+D4wj54LnL4N4GWuJ1aBTUD8MzxsC6GZ73KNxzk/Hc 143njuDL0AS4Lwx1J6wVcP0hKMfD+clQ+shHaKzxfoQs8IxKqI+CdTPtD7xzCzs/dQWeMUu4 h8ob6oTO4CJiJfeSi4ybmcaauXv4PGGM8JO4RLJKj0lfSl/Ki+UG+bLpPjBl25RmNahWmq3m g+Z/WM5oUW2/tcx6t42zvWAfY3/BsdvxhXOxq4drpeukm3HH3L08qmeT1+99zicChon5Hwls zKrJag3Ggyuztexnsy+HHgsv/3/au/rgqK7rft9bWVoJhISwhTBCe0Fi+RBIIMsWCBskkMBY AWFJUESJ4Wn3SfvM7r71e2+1lmdir2fimbpuTJrMOKk7UxxPp3WaulmkDBU4HdySJg1Na7dx 3amdDzttZ+LJpNiZaVP/0aq/c97dDyHhOGn/6B/Scu4979xzz/e9776HPjY4G37SvKp5oGVL S3/L+xt/rDL6gNiFfZm+dFEr2sV+OhlV/RdoOmgHA0eFUOP/zW2A51XxVYBnrdCCCg+Ih7R6 hZeJKs1TODYH7XGFl4P/OYVXiG9ov6/woAjrMYVXit/Un1V4VdlfBBoUvkyMVbyl8OViPHiv wqvLvxZ8UeErxOmaE4VafaJmWuF4wq7dqXA8Ydfeo/CAaK+9T+Fl4Ikr/DaxvPYRhZeD/1MK rxBjtZ9WeFCswp3LxytFf+2HCq/SjZV7Fb5M7Fx1ofBbxO9a9brCqwOnbg8ofIVoW/1JWKKV UdSXr36G8dsoI6u/wHg50/+Q8QqmzzAeZPwa45WUo9XfVThy1PB3CkeOGt5WOHLU8J7CkaM1 hxSOHK15UOHI0RpL4cjRmozCkaM79ygcObrTUDhydOdPFI4chV5WOHIkaxSOHMm0wpGjTVsY ryK/Nj3F+DLyZdNvM76c6V9ifAXjvsxa8mXTZcZXAa/b9C3Gb2eef2L8Dpbzr4zXM/3fGV9D czdrjK8lns2+beuIZ3OI8RDjrYy3MH8X41sZ72d8O62MzcOEB9l+hbOuzWcIX+7TzzHOvmzO iBExJVLCFOPCEBH0UnwZMCJijB8RtkgCPMUlsfPawgFOrQG6xRwSlDjmtwHrY7rxv5TUXrBM imGMxEW6wOOCdhi9r2+n2I3PDrFdYR1M7cWMOPohzJmADR7PGoI8F+CISbRRcDkYN8BJIxPQ EceVs8Da7hJOeRNvtzjBEt2CB2TBLrRSbIYkC3Y6GHEB45C4pUTWrWYWOY4gDsWrP+GIUryi mJlg/edAI8m/eqwlqOSRBUs8tohiI3FNPJ6Sehx5kOIYz5cizPqOoB2E7nGOuQF+mmdCKkU5 wzNJWtsiNvn5taGXbEqBd+qWXCbXFfFl2KqJgl5LVe12zostxpTVR3kkxpVjwJptBdsdHrG4 QofRptlqPw9+NVEGDrAlHkc5HzcHtkhwGaoG/UqyOPZRriyqtSTrKq2XiJJlsG00M8ESye4Y 9CdYoh99yVYbrC+isuGPkNWuyofBPvrzpgr5t1SVp1QGTY6Ny5Xne5fPkKHsT7M2yRpKrcpn nmJD1xmWHSupBuK1WZavO0/3o+2piERUpboL+DzINDkqFnpfdkRR0hxpqqhiTdu8Yh2OaJzn k6WUz4SaldcQ4fmTSqulPPXXHkkoRmGc13BcUYtxtVR0beWJxfxpvipm1eUqjbN1i9dEfk91 C77QWILlFWXQ3nBOWWuo+Ed4t5NqleZjFmXdE0z159MKs1QOY7zuUqpGbLS0oidVtH0JxV3e 4Fz51SE5hhHlv8VZizNPiteeX41Jnul7UlrdVqGyaOU/qjKTYGuoNifV2vL3nXjBjgRfFavX u+lO5N7kX0TpGGMJaY50dF5tmuIR0PORTfPf08h7OM61LbkGHuXYulx3XmE/8bNOtvvr3VO7 hr+aXFVlxd3TH01wRgzxGM/3rSa5ER4tVpqvPcrRSvEqmSp4kded5D2Txg2OhKN00Bryo+jx /LzFeekprqEE75t529r4nudhrBv30nbIpU8bc5XusG28OyXAEeO1FAeWAJbkDJl85YozXAN+ xtsKnP+3GjJcMT6vWaLlKHb6EdzvDwIOoPIIHwSV7gAH0X6C6f2gDKOl2jyEO0E/PkeYOiKq +X8Fq3gvsdT6uPnUk6f768SPaErFvFijH+8uVsxMfkfO53mMR6fAny7ojBT2Nr+ei/ej0t3S 3zmK+6i/fi21Z7pqTU+wFLOwJ9JqHVXaaHVPqr10rHA38nV6HxGZ/N6ZKexOplpxZqGmHd4/ PLWex1U9Lhav/CqkiJklUoqreKG+qLoDUgWO8c7oWz2mMpNUkhfL0Cb2an6k/B15YVUs1Jzf 22gXM/gMakBrXEXbVXvIrXRT9I+DUtxnpxbkwlSnjNIzl797G2xRiiNrqZPOx8m5VLWYLNnb 8nppJ4lypK2Su4hTckbeVuB2Suq2eO/+6EiRdQmWn68re568DOf/HGez9Bya3x+LnDZ4/RNq miNO8mMFf3y7Sqs7oXZUP/7+qkqp+ijuvPNr6KM8KtbHYfZ9YebyZy+655jqhOZ745/3IpzV 5E05cG6Kd1Gyy6dVOpFE1X1oks9GGVF6uvrF2c/Lc9T5z1LPOoud4hbm0Y9W8cQaYZkL13E+ Y8ZNsR7/pawtRnmhhvn3+/kWmeoU6+Hek5dAzye9wn8S2IwzfKfowrOWRLsTV9vxhNgJ2CHo LcFxMaA4d/DfnOrEx8e7xF0AmnWPuBvPAgQk/Ze71/3qd8b8WPtN0SvcD0emUua4ETHll+VI zJRH7KTtgSQP2E7KdgzPspMyFY+0yT7DM34BUzsJk8N2PE0UVx5OYt7O3bt3bEfT0SZ743E5 ZE3EPFcOma7pTJrRXscy4kPmRDpuOHmx3UyUitp9wnRcUtDRtqtDbj5iRRzbtce9LcxVOsiE IyPcvSRHHCNqJgznnLTHP9Jq6ZgTluuZjhmVVlJ6YD0+LI8ZngzLkSNycHy8TRrJqDTjrpmJ ga2tIAn+2hOOkYpNlZJM2ecYGSs5QXMthHa7HLLHIPqoFYnZccPdRtIdK2IZcthIJ6PwAWHa 1XHATnpmgmxzpqRrIIIIkjUuo6ZrTSS3ST8uEXAZFgYTtmPKWDphJGG+jMQMx4jADVxYERd+ GEmJsSny30LIU3DQjJiua0MdOWRAfjoSk5YSRc6nk6bMWF6Mw5Cw7SjNJhxmezAkgqC6eZqX MZOeZYI7AiTtTLVJjrQ9aToGcu05puElMEQTImnk2yVllD3TYRPG0/E4ULYV6hM2lFjJaNr1 2FXXm4qbpZGgSnVJi+kkrCRzOPY5iDVgfyQNRX4Co5YxYdN4JoaYy5gZTyEitpywJk1m4JI3 ZBzhkAkTsUtaEbAbqZSJMCYjJpT44bYoWNJ8FM4kzPiUhG8uaidOMhJWnMPrqUXkKn0RzBgz ZdpFSXE0zUfSZGw6QvGX4zZchkQ45XlUJ3DdMZF3D6WBNLkIGZcnLhPGhPGYlYRo04ts84OG 6VHLTcWNKVJBs5Nmxk0ZKZgGlihM9CyXBBN7yrETNktri3leqru9PZPJtCVUwbZF7ER7zEvE 2xMe/e3I9oR7xiDH24j4MSdkzDioJk85Ojhy+ODhA70jhwePysGD8hOHD/QfHe6XvYeG+vuP 9B8dqa6qrhqJIaz5qFGIKScwFB54HNFFlhg7Q4VMPo9NySk7TTMjVG2IM68jvyxRHFyjyC+W XxLsxoRjmlSJbXIU02IGysAeo2WEmd48Y6g6M1ROJhJnUqQdM+Ihz+OIY9EuSqE9YTILp7gw D6lB9Y6lPYiGmTZWVIlDm9y8USjkQigKk6na5KQRTxtjqDDDRYWUzm6Tx5Ncs1N5L+CT2rlQ 3oZ0U2bEwqaz0HOJKCa52miuEY1aVBOoSod35G1Edji2vLpvMipuJSxyCEqYL2M751y/SLke mWhnsKGmx+KWGyM9kOWHO4FChf1IVWpK+sWrIjRfEcfj8HjROdq9HkmbLqvBvhcxnaTywFF2 M7Mbs9PxKNbQpGVm/O1qgfvEh0ya2AGixS2u4CPM4o014hVzTI4ZyurxxcWyyYUJat0rQdBj eN3EcHy4FzeBzbs6u7bIrp27tu/o3LGjsvL4AIg7du7s7ETbdVeX7Lrn7t13766uusWq+8jF SFftyjxeh3hUtfkhjw7l9Ig2pVXjxv8wDgDv8bEhPzbMxyB6SKRDWzTwfOBi4M8CVwGXA1cC f7z0Sn/plb5YeqW/9Ep/6ZX+0iv9pVf6S6/0l17pL73SX3qlv/RKf+mV/tIr/aVX+v8PX+nP e/Iv4gbzLzb27k1zzHnvBPitwC1kxrnCS67Lmsp2lg2UHSq7D+3ueRpoD76VlKO8Zmjv8b2P aTntSwHB6+LWcxbHC9/LK+Y20U8ELfzqbRY1gdXiBmAOEBAhtO2AQcAZwHnABUA58xHFBjwB uAp4n0d6AqunP3dXzyy6Z7ibeTjewZeGf3n6k3w582ujfn/kQb/vO+yzdftsOzt9ctt+v9+0 ze/rNnZkqa+q7ni1tz5QL14P0DdfptBq+jdEjaaJkHghcIfIAfRAuaL0BOpmWsIdF64GyoQW 0AMaYhqaezWgTVev7Oit0uf0G6JOhPR/03/qj+g/nVmxsuNC7wP6j8RXAVcBAf1H+Lyrvyue 0N+hn/lEuw9wAXAV8BrgBqBcfwefH+LzA/0H4Pq+aAfsA5wBXABcBdwAVOjfR1urf4++G5hb wvcBdP17aGv1t+HW22hr9LeAvaW/BdO+O921u+MyI63tCgltVMjqtQqpq++Y1f9++sMtoVn9 n2dka+iF3h36GyIH0KHsDQh/Q0jAMcBZQApQDuxNYG+KLOCzgBcAOUA55ryJOW9iznXAdwBv ih2AHsAxQFB/fRpqZvXXpsP7Q731+t/q3xKrEdS/0f+K++/o3+T+r/W/5P7b6JvQX9e/Od0U Er3LMC4wpxZ9Lfp2jN+m//lMS11ornelfhXhCaFtB+wDDALOAM4DyvWr+obpaKgOQl4R14MC nNPiPe7/QLwYFD0Ph3rCB1Bjkppw933A0FyQF8J6T/i538ElNeFnPweMmvCnfwsYNeHHngRG TTg+CYyacPRhYNSET50BRk14cAQYmln99/60ZVOoa/CcJntr9AyilEGUMohSRpTpGfqID8vI tt+d3roVEXu+p3XL1lD2ipb9upYd0rIvallTyz6uZZ/Usvdq2Ye0bKuWbdSyTVq2R8u+ou1C KLJaz9fmXe7uadCy17Xsy1rW1bJhLbtRy7ZoWal19czq66cP38VdP3czvbSu0N+3t6MGNq5H RNejrNdj2V9F+xpgjq96wCQ3+MxrmqjfMLN1n3/d1t1h996vX8PEa0jDNfFDQBkSdA1ldA1C 6LvTa9DuA5wBvAq4AZgDlIN7Aww/z20N2nbAPsAZwBOAG4ByNucGQBe2MvGrbFi7MnqQrvRr +GzAZ72+vmddbWNta+39gfONWk2TNtg016R3iXr66YS6lcGVs1r1pZ9X/+fPq0Vlb6X+rH5e rEMiPqv689MfrgvNal+cDr8S6r1D+4JoKkPVabtFWNuIfpdw+fpu0RikvlM06l9B3zHdeCJE vxw3vC10RVtBsy6FPmz8l9B7jbM60B83vhL6Rzlbpk2H/gGUr1wKvdH4dOjb7bNBUL4entXQ XZHMerlxV+jl68z6JAaenw49Tt2l0KcaD4XONfKA6Q885OKqpyY0FD4Vuh/y+hrHQj0uZF4K 7Wt8KHSvz3U3zbkU2gETWn10K4zd0shKm5tY4PGuWS3Ws63iuYqTFYMV91R0VGyrWF8RqlhX sbbi9mBdsDa4Irg8WBUMBsuDZUE9KIK30y9LaaUfrri9vJb/PnAZtWWM1+rU6v7PmehaUBcP iNyqwIA+MLxfG8i9GhEDYzL3H8PNs1rVg6dytzXv13J1A2JgZH9uV+vAbMXcUK6rdSBXcezX T17UtGdHQc3pvzGriZGTs9ockZ5am6s7QH9EUVv51GfWUr/5qc+MjoqG+sl9Dfvq9q7cfbBv keasakt+OWnDPHxd7rmB4ZO5P1o3musgZG7d6EDu88Py9MnL2s+09/v7LmsfUDd68nJgr/az /iGiB/b2jY4OzGonmE9I7QPwoWI+YL5gk5DEJ2Swyed73ufbiPnga6EOfJWVYiPzbaysZL4y jfguui39fRdbWphnNY6ezOOulqU81zeCZ+NG5qnPiuvMc70+Szy5vczS2AiWpkZm0e4UjczS qN3JLCeKLO2K5ekCy9OsKaAVeRp9nup38jzV74Cn9eN+mftbW7WZPaOR0/1mc//Z5n4TcDb3 zGSsIZcdk/JiZJQGZC4QPjsWiVFvmLnRZrMvF2nukxf3nF5k+DQN72nuuyhO94+cvHi6x+yb 3tOzp7/Z6BudOXSss2uerqcLujqPLSLsGAnrJF2HuhYZ7qLhQ6Sri3R1ka5DPYdYl+AaP3by YlDsHz1w2u9n9GVVqNeza9eP7q+vTe3l4t2zvuHxtVdwIHlJLGsdzS1v3p+rBtDQ9t7tvTSE NUVDK0CuUUMNj+9Zv/aK9pIaqgV5ZfN+0eql3bRo6Lf6/H8uvkDy0hRwv211b/WFsf5cj9Hn ekIM5LYOD+T2PXjq5MWKClDPkku57jxt2bL+2blXfWIbiN1EDAQKjES7l2iVlYpxYf7Tqucf Rs7qr8xoPU0aHupGA7mmgREdW8HIKfh6+tTJKzgu0e3BHYWDrtaquXkZbLZQv6eS/M2Dl1aY ioOnen8Wprj5cBS+MAdb1f8AFdQ9OgplbmRzdHJlYW0KZW5kb2JqCgoxOSAwIG9iagoyMjYz NQplbmRvYmoKCjIwIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQ0FB QUFBK0FyaWFsTVQKL0ZsYWdzIDQKL0ZvbnRCQm94Wy02NjQgLTMyNCAyMDI3IDEwMzddL0l0 YWxpY0FuZ2xlIDAKL0FzY2VudCA5MDUKL0Rlc2NlbnQgLTIxMQovQ2FwSGVpZ2h0IDEwMzcK L1N0ZW1WIDgwCi9Gb250RmlsZTIgMTggMCBSCj4+CmVuZG9iagoKMjEgMCBvYmoKPDwvTGVu Z3RoIDU0NC9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxdlM2Om0AQhO88BcfNYQXT PcCuZFny2mvJh/wo3jwAhrGDFAPC+OC3D9U1SaQcbBVNTfNNzU+2PewOfTdn36ahOYY5PXd9 O4XbcJ+akJ7CpesTJ2nbNXN8sv/mWo9Jtow9Pm5zuB7687BaJdn35d1tnh7p06YdTuFTkn2d 2jB1/SV9+rE9Ls/H+zj+CtfQz2merNdpG85Ln8/1+KW+hsxGPR/a5XU3P56XIf8MH48xpGLP jijN0IbbWDdhqvtLSFZ5vk5X+/06CX3737tKOeR0bn7W02J1izXPS79etJiuBFpZd9CeuoQu 6DF/aVp20BU9r9Av1AX0K/0V9IZ16//GukJvWTe9o36Hfqcnh96zvkxq5XLTfgNNfoHHgV9y t4Umv4LNkd+/QBf0WJ38Jdgc+T34Hfk9+B35C8zXkd8jB0d+tZ7kV8zLkV+MgfyF1clfgFPI r6bJX+FbwvxLjJWYP/oL+dU8zN9jXYT8ajrm/wZNfjFN/hLzFfJX4Bfyi/Unv1ifyI8chPyC fIT8gnVR8hdYLyW/xxyV/N485K/QU8lfgF8jP/LUyG99Yv5YXyV/BQYlv5iH/Ap+jfljD2jM H5xKfm9+8qt9K/KD08f80d/H/JGDJ7+gv4/7Bzw+7h+siye/WJ38Htn6ivsK3/Vx/4DHx/1T 2WGMpw7HEvfGn+OeNvdpWo66XS52xnG6uz78vX/GYcQo+/0G3qgWHgplbmRzdHJlYW0KZW5k b2JqCgoyMiAwIG9iago8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9CYXNlRm9udC9D QUFBQUErQXJpYWxNVAovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDczCi9XaWR0aHNbNzUwIDU1 NiAzMzMgNTU2IDI3NyAyNzcgMzMzIDIyMiA1NTYgNzIyIDU1NiA1MDAgNTAwIDU1NiA1NTYg NTU2CjUwMCAyNzcgMzMzIDU4MyA3MjIgMzMzIDU1NiAyNzcgNjY2IDYxMCA2MTAgNTU2IDU1 NiAyNzcgNzIyIDY2Ngo1NTYgNTU2IDIyMiA1NTYgNTU2IDY2NiA1NTYgNTAwIDU4MyA4MzMg NTAwIDMzMyAyNzcgMzMzIDE5MCAyNzcKNjY2IDY2NiA3MjIgNTU2IDcyMiA3MjIgNTU2IDc3 NyA1MDAgNTU2IDU1NiAyNzcgNTU2IDcyMiA1NTYgMzU0CjU1NiA1MDAgNjY2IDU1NiA1NTYg Mjc3IDgzMyA1NTYgNzc3IDk0MyBdCi9Gb250RGVzY3JpcHRvciAyMCAwIFIKL1RvVW5pY29k ZSAyMSAwIFIKPj4KZW5kb2JqCgoyMyAwIG9iago8PC9MZW5ndGggMjQgMCBSL0ZpbHRlci9G bGF0ZURlY29kZS9MZW5ndGgxIDIwMDg+PgpzdHJlYW0KeJzlVMtvE0cc/s0+7AQSsEOgoU7L bBeqgNd2CPSpIFw3DQ2pROQodJdGohtn85KdWCYgqIqC+lDpVn2oXDi1BC5FFdXYXDhy4NAD UVGF0qoP0QMSl3JBqlRVTdJv1stDKP9B1/bM933ze8xvPPubrRz1qIlOkUrZQskttzKmENF1 ItZSODbL9cY31gL/Ae3lsfJ46WZH7Q6R0o6fN148MdZx42yRSPsA67cnPHf0p3vvWUT6BPjz ExDeX3ozCn4OfOtEafa4yV5vAr8G3lScKbhf0SFA/QaGhpJ7vDypPsXAfwbn027Jm32h4V3w v7GHz8szR2ZbaWqFKHparpcrXrktee8S+DfgafwYPvJBDhaRXKH/97M8unJHXdT36hfpS/qY LtE+ukBf0AxNUZ4OU4Z2U4p20lu0jZ6kHsoRpznK0kU9TiTIErShX+wYsMX+Y44gc2+biCTt PU6gnXT4TcE2pNtSgln8F9GUTAnF6s/br5mOkRKqNdnGRXbANkTWSQnNkq6Gabxj/55YcBKw s5cSd52EaQg9aYveY06w4DiIp1vNw4dSImJVn2GnkZ2fHh5OCEKYqFXdGkjZB1KD1RLnL2VS otHiJ2WSawjDhbqtz+RCe3a/oAHb93yXS/BiwjCchB+wfJ3JhGvqu4slYgYirrX4j0E5TRbP iGhy2OZ8n9nrTnGbj47UQ0i7ZpkZqbnP9/m9rulz3wzSmTK4yMIS9UlBZD1J4LMuyLRnsc0w EnzRxzHAqQ+7GQr3ZgRm6y2TL4bJTW73DyYMwRzbR0F9pm9yv883XelQd5FTSsTk39CCfcdl ARK0PFaALyfTnXr70Uqk6wYLRfgfyWPbP2r6UcEH7O7EVay0Wpcpy7K5HOu/EqMCBaM0HrLl mLfNEezezCUwMTOHk8/m7Rru0auFXI1xhknwgtjstd/PtdESUHEuGFLykiq4eaSM6kPoQlFK VxllumtRbdPdrmpE/627piqAVFWlrEu5Fo20/9tdY1LfFTfi24y40aPw5a3s7PKEPvTPtz3a AslucAu9Y047R2txv2vgSaEv3J+ZaMoIdVE0LuBbbWZJ6txpcIqRwZ/YFItG1NTyveWrLMvW seYL589fYDmlneXm55duz8/L2MSua6Qcxp434lXJCLaALxNapqoHseLPGRs1GJ05Q8FeUOLY 2K/L1uDh9d1/0ZaG4P38/ofclkffV30Op4BeSPcbF/yiB5fmHjFhj73iqvIn9USG6ZZW5xZa aiWwUtEH63EUcIU2SWfVCf3W0XcPYq1/EJfRGjAWekVpc4hV6DzEGvCOEOvUjB5SxxHor8CS aY1gT1N/iBm10mSIFeQ9GWIV+ich1oC/DrGOXnQ5xBHoCx2F7byrc2cnP1BxC0XvQNmbHjxR Gpkp5r3xo0W38lB4iA56lSOTM9O8K707veuhTB24w9tRShd1ovF1Ah3AcblQi+QBlzFO0yCd oBKNoFEW0Sg9GqejQC4sV7NYTTsIpUJHUPgMVmS+NA4qTbtWtUa1wbMyjnpXea6wlQ8F+5T6 RcOAXWXsM6faKzuWiKEZt+YBTjlPobMM245oTRL9By/ghr4KZW5kc3RyZWFtCmVuZG9iagoK MjQgMCBvYmoKMTE5MAplbmRvYmoKCjI1IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3Iv Rm9udE5hbWUvREFBQUFBK09wZW5TeW1ib2wKL0ZsYWdzIDQKL0ZvbnRCQm94Wy0xNzkgLTMx MiAxMDgyIDkxNl0vSXRhbGljQW5nbGUgMAovQXNjZW50IDc5OQovRGVzY2VudCAtMjAwCi9D YXBIZWlnaHQgOTE2Ci9TdGVtViA4MAovRm9udEZpbGUyIDIzIDAgUgo+PgplbmRvYmoKCjI2 IDAgb2JqCjw8L0xlbmd0aCAyMzAvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicXZBB a8QgEIXv/gqPu4dFY+lNAiXLQg7blqb9AUYnqdCoTMwh/76ju22hB8XHe9/wHNH15z74LF4x 2gEyn3xwCGvc0AIfYfaBNYo7b/Nd1dsuJjFB7LCvGZY+TFFrJt7IWzPu/PDk4ghHJl7QAfow 88NHN5AetpS+YIGQuWRtyx1MNOdq0rNZQFTq1Duyfd5PhPwF3vcEXFXd3KrY6GBNxgKaMAPT UrZcXy4tg+D+eepGjJP9NEjJhpLqsaOslqq8ZfNQuXuiTChf/GnG7YZIreoeap1SxAf4XVWK qVD1fAMs5m/qCmVuZHN0cmVhbQplbmRvYmoKCjI3IDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0 eXBlL1RydWVUeXBlL0Jhc2VGb250L0RBQUFBQStPcGVuU3ltYm9sCi9GaXJzdENoYXIgMAov TGFzdENoYXIgMgovV2lkdGhzWzM2NSA3OTQgNTAwIF0KL0ZvbnREZXNjcmlwdG9yIDI1IDAg UgovVG9Vbmljb2RlIDI2IDAgUgo+PgplbmRvYmoKCjI4IDAgb2JqCjw8L0xlbmd0aCAyOSAw IFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMTk5MTY+PgpzdHJlYW0KeJztfHt8VNW1 /9pnzyMPhjx4BQLMSYZAIE8CCMRUJiQTwPAIEDCh3iYnMyfJwCQzziMxFgtea7VBi7eltvYh 2Ba1RctkojagLdRf23u1D7Ctre3PCv607xe1attbzdzv3udMHoDW3t/94/f5/JiTtffaa6+9 9tprrb32OXMYouGYTlNoP3Fye3u00HTGCJ/vELFcb19UffC5plzg54ns3+gMdfXc9bmbXyBK /wKRNdIVGOj8xcfff4QoKw9j+rp1zffIquypaN+N9lXdIKwfHbCj/R9oL+juid44l61OQ/t3 aKcFgl7taroaaNZrKGw92o2h7dkLrWi/ibbaq/Xo730m64dE2XOJymOhYCTqowVJomsOif5Q WA/9ZVHn62g/aurASKqPFRGzyfb/5x/rRwAbyQmYyw9RPlHyJcArgF+NXpt807qHXKO7k+f5 NDA/YgJREd1Dh2kBXWBL6Sk6TdfSA1RLTXSI1tEZOk5TaYB9myzkonp6iIqYkxRqoFnMSvfS T+h6CtPP6TwVUyO9yHIhx0Mhmkmrk79G2Uh3JE+AK4Pq6Mt0kgXYdqoAvl4pZSWY+WDyNM2i 4uR3k8+j9Vn6OVuQHKL1wH5BObSI9tG/US7tpmeSIkoWUAc9yPayX1MBtdMBy3LLYHIPguox eo41AttEA9bn0x+jAEZ9ns1ip5Pnkr+kr1kY6ZD0r3QHNE7QaaWc11mPkEoL6T20mTT0vp9+ wqaxpdydXJRcm7wX1AfpVaVE+Ra3Q48S2kBtdBfdD2v8iF6h11kmW8E+y47hepb9wfo8dGuk GN2EvfVZWO9BephOsKVsqTJLmQVrzaLFtAN9B+ko5h+ms6yRtbLT7Ov8qLVydE1yenJG8pfJ JC2hFmh4mL6OOV5jleDBDLyQRy3zLVFr1Vu3YIU++gydpWehx4uw++v0V7YE10vKB5R9yeuS DyV/Dl3SyEmraCvtoiD1UT99Dl59ir5Bf2J/V9LBecbyTetN1gvJj8K2C2ktdN8C7u2QfQBe StAIrh9hlTlMxSpWsc1sG+tiB9k9bIT9hP1EsSkFyg3Kb3icf5u/YLnKak1WQ9JMmo95XXQd dcMDH4C1P4r1PkTfpKfZDLaQlWFFP8L4N5SrlXpcn1fOKC/y2/hBy5vWD42eH/3t6N+Tg2RH lK2DHWL0JVjhj2wmdFjMdrMIexma3608yqfybO7iK3gtb+at/A5+iP8H/54lbDlm+al1g1Wz HrNro72jzyYbkx8kkRVs0GsRldJyWon46UQ07YF+IVxh2ku30CB9BPHyUTpCx7DuU/Q0PUc/ o9/BA8QKoLMfs/cg6m5jH8F1L3uYfZ19kz3NXmJviEspxFWsXKWsUeqUBqVLuQ3XIeWs8iPl V3wu9/J9fD+u+/jj/CcWslgsSWsVrvXWA9YHbd+2F9vX2zvSvvPm799a8lbrWy+O0uic0feO 3jP69dFfJncmB6B/EZVROTS9HVreixg8iutLiMTH6VvI3T+Wur7KFGZFxOcxF6KhFF5bw9ax Dbg2sa24duC6ju3CpbEO1o1rH9vP/pXdyj7I7mIfl9cnsbaj7IvscVxfYSdxPcfOsV+w37BX FQSxwhHNRcoipUJZjZXWKeuULco2XF1KEFdICSt98NCDyrByQvkRn8aLeBnX+A38Xv5l/hT/ If+bRbGUWiosNZadli7LrZYzlmctz1v+bnVaPdZu633Wp2z5tuW2Hbbdtk/ajtt+ZXvTbrM3 2Tvse+0/tCfTipCt/h3rfmxSyquwnWER63TLjco57Is8HrLeznbAYjalmQf4R/j3rZ3sAlfZ T9kg9/M9yc/zBuWvPMh2KqdYIXdaq3kn3UlJdkx5SXlN+aVlBmtWfs2KLf/GvqIEeZ1ik3n1 B5YZllutvyJSfkzVys3stPJNfiu/NflVqrbex85Z71OeJdVyXplG57Crb1c+gUHfU/zKAWqx LLf+nfyw+xetN8Le1yh3sCX8h5b76OfcpfyZXWD3IGt8l11rWaC8T1nNjiHjvsXm0+/ZDRRi Hyc3e4L9jI0QYw/xB9lGZQq8FVccbCUOu+/yAvZDnkGtQke2UJnBmpQLyg7+pO0sX4Gj/Sx9 n25inFUidlKfUerFDjikLEJO8yCb/IBVUR59Avn+tdEnRca2Pm89gDi7n5fSNqqkf1G+TdXY Gz/H1UIfoio6iRi8gyqVT9Le5H7mQ97fhPyp0AjbTRUsE9lyFnTbh/NiplKIXNiGWf+K/P8M sn4j+wP1MxU76zQVW0TPnRYPMlM78u8BXD76F7Q+Qx+1PWb9AW1hs4gs6uh9iPIX6H04c17G /HOoBvrtovstpdBaRWa+ASM+M7qe3Lg+RN9mCt0Mna/BPm+yrEfmvSe5Gyv044zaiDPxafIn P0F18N225K3JA9SWvD95PXXR9uRDyL99yQRdRbdbW5Wd1hLLcuTYp9k3cB79b3YAeXs9/RT5 qIjl0W9wfRkaXWN9ggYtP0buXJO8M/kczYA9CmGhDpyir1AP/QF2W89P07LRzcpQsoGHcEKd o63JB5NOlkHdyQAy75N01G5F7tlP861H3W73mmveU3N19epVK69asXxZ1dLKivKy0pIli4sX LSxa4CosUJ3z583NnzM7b9bM6dNyc7KzpjqmZGakp9ltVgtXGJV6XA3tanxhe9yy0LV+fZlo uzQQtAmE9rgKUsNknrjaLtnUyZxucHZexOk2ON1jnCxbraGaslLV41Lj3613qSNs19YW4HfV u1rV+O8lvknid0vcAbygAANUT153vRpn7aon3tDXPehpr4e4ocyMOlednlFWSkMZmUAzgcVn uUJDbNY1TCLKLE/1kEJpDigVn+Oq98Rnu+qFBnFe5NF88aatLZ76/IKC1rLSOKvzujri5Fob zyqRLFQnp4nb6uJ2OY3qF6uhA+pQ6enBO0eyqaO9ZIrP5dOub4lzrVXMkVOCeevjs256JW+8 CeG5dS23T+zN54OePL8qmoODt6vxI1tbJvYWiLK1FTLiSlFD+2ADJr4TJmzcrmIu5bbWlji7 DROqYh1iTcbqdJdHUNp3q/F011pX9+DudjhmzmCctg0UJObMcZ9Inqc5HnWwucVVEF+T72rV 6ucOTafBbQPDs93q7Mk9ZaVD2TmGWYemZpnIFMdERB/rk5hkF1jjtjG7MqGRawPCIa56VWjS 4sKaVolCX0WD3lVgw6eVYVTcB3/44+l17YPZ1aBni/Fxa1G2Sx18neB/1+9/N5mimRRbUfbr JFARJWOBhv4UHi8piS9ZIgLEXgePQsdrZHtFWWnfiBJ3hbJVVDAfNcG2Wmt1BYxfUCDce2DE TR1oxPdvbTHaKnXkJ8hdUdIaV9pFz+lUz4wdomd/qmdseLsLcfyofP6YEU9bOPaXlT1zmqe7 Os5mvkO3bvQ3bnc1bt3VonoG203bNjZPahn9q8b6TIwZHTB43FIES21wIfS27WoRBPxZixpc Hn/7emw16BifVtfC85VWA1PyuRSF+L1+TLJotEwRsixFNhn/vhF7GgJYUpjaEM9uX2+UrRkF Be9y0Ejyghglq/Fh5pri1SWT21dPak9Sb8ogh8KWhUpj867BwYxJfQ1IVoODDS61YbB9UBtJ 7u9wqdmuwRO8hbcMhjztKfePJE8eyI833NmKRXSz6jIc68I3Vlx4MrbTpiGFPaF8DfeNduVU gqyWEeVrj3LKsAvkMUaz02zWU+hXiLPFlM72sPdRXkn2GzVv1WzOfq1m01s1tAZ49psollYW 5BTkFKFgOBHfVPnpN91W+jvuFk6T8cSqPPu75z79TGtbVs3rabPT5CH9uZfnPTXpuU5ohgfx sSdc1PaCUQ/utGmcMumj2FazuYqBG4/dci48GRhEhbLxHFYL2d/FszSX1HV8FwkLGPcJZOIM d8+jJq7QVDbXxDmF2RITt9B89hkTt1IeO2niNipk3zdxOz3PXjPxNFqofMfE0+lDyqsmnmHd yW808UwKp33PxKdQZ7rbxB22R9MfMPGpdH32rrG178t+3MQZZeWsMHGF7Dn1Js5pdU6jiVvA 80ETt9KUnI+ZuI1ycg6buJ0COXETT6NpuXNNPJ3qcitMPEM5lhs28UxaPWPe2LcSy2bsNHEH 3zXjwyY+lcrzXoYmzCKsPmV2jsStwiOz50ncJullErdL+mqJp0l8g8TThY9mt5o4fDTnOhOH j+bETBw+mnOricNHc143cfgof5qJw0f5JSYOH+VvMnH4aG6RicNHcxtNHD6a+6yJw0eFi0wc Piq818Tho8KkicNHi4clniHWtSRL4pliLUvyJT5F0g0dpkp8pcSzxVqW1El8GvDcJVslPl3y eCU+Q8oJSnympO+T+Gw59oDE8yWPods8yfNFiTsl/pjEF0j+r0t8icTPSLxM4j8TeJqh/28l bsz1F4FPkfQSLnG5lhK5xiwRP1SST800gGdNHffdGnlRq/RFQDOekgW+Cc/ovYCoyaXiPjmI J9OQLDXQ/ZJDBSWA8eXA6iVd+7+UVDGmmYr71yBosTGeiLyz7jXnW0qrcVXiOdTAqiS1FiMC qLdhTBd0iMpR2yAvAghTH0of5vDjPliXfZtR90ueIGga5AvuLswbQCt8yQqq/8Fo9aLx1bRT zhwZW6nQdBVKVT6n+LGeMHoigE7MsvgfyH87aeOjjDHjI5pgyU3of2e5X5ZeEz7xoa9H6r4H NKHVf9+fKqjCGn7MGpWaC/uraAueqCl1BzRUoacYL74BE/NtQrkFc3dKvwoNxTgdUiNS925T WvlldDJiKIh5hU4h8A68LZcuY1fw9Uutusbm9Zs7o0zGYlTqEABlwLRDWK5KSC0FZafkj0q6 iqc6YT9hyV65JhGjy6SXuuUowy4pK2t4NgvIuaKX7EuhR1haT5VrEb3aRXZMSU+1U96a6HHD jxulvj7TR73SkhHI1KTcsFxJp7mGfqmrF6WQG5UUTcrySZlih/VKPYSHxN4UPN0mTwQ7oEP6 6gZghh0C0nYdaHll3OlSr16z7pwQEf1ShwBkC1k9cn9ETaleaZkIrk65y9QJPvVKy2gTcoah W8oihte6pJ00OdY3yfcRObcRWar0j09iMWk1XdrlnWNhkWkhv5ThnbAjOiT3O8eJsQMu9d9E Cxs26jU17R2jiSwSk1lPNTORTjfKXdcrvdUnZfrNfWjYyKCF5NiUVY0o6pPZt29sTwhbh825 w2Me2jMWcxfvL8MO726PGatbKyPHiOvgmP5GXBp26DXz+WSLGzHnk943ojsmLWxIism1G3M2 SVlCYhR0bUJeaZLZulfaxNjP/knRbOTIAalZQI6IyJUGzKjrln7UzHnDZr4Tq4tIz8cm7R+h rdhxKR1FNKgyKg1/iHV7Za4LjHk4YObRDkBAajdgrjgmc60hqV/2dEtpQVxGzvSavunBGMPW 14HPJ2cYMG00MZ90yLF7TF0NCwkLdAFukjwiUibmChHrxhkQNXuCk3KoT8ZXbJIXU5I1mdOD E6T5pP1C0icDkzh90kJhaduUX8vlOR8FfzXuHypgA3GVy6wxMSLLzaxTIfl7IL0CZVRmAqGX aEWoTco2dp2RH8NjZ2T52Mj/2Rn7pSdSOXF8ls3YJc3Y9Q2AOtzbCHwLqGL3NMjsIegeULaj FHc/63Cie+S3qILaTA7KkDB+7lx6wqTo3RNyQci08sBYZn53p+y4r/yml43YSmW/ARmvqTm9 8l3Q+F3BxCyb0sfYTz0TzjBN7gYjsnpN6ZrUQpdnqhFhIs5bzdnE7uwz83+HzN5+8+Qy5nk7 y6TuyfrNE1fsJf+EHDgxyxs7qdOMlsvZK2iuS1hMn5RJU3v20vl8ZiYJy50fG8sYHaZnJp6d l8/Aky1lnCWXRsWlM/vNParCcpq8Dx+/S9HkOaHLvHT5uYX1d5hnpHGmDFziC8NPk+8JjUyo SY1C0rJ+M4u8G5+rZiym8njXhHlF7vBJSxvnsXH6hyc8J5SOcYcnxO34fck7Wyogs4b/opw+ Li91XkZk/I3fFaRy3jhnELzGHXRMWlzI7x5bj6HXxOjuMbOkYX9jV4XM+BjPppNj6J1WNB4f G+TaL/Vc6iw07uwiE1ZjnDRe6dXei3wQvsje45LF+oLyXs5nniXivsN4QknlgXfj/ZQ8Y0/q 5nk6+VxMybvUj4a1jBVEzbP8cvs45THtIlt3/lPajlv50hm85v1bh9maqJFunoRRnD0pCeL5 Sbx3Ek8qxXgaFG+VFwNfiSeDVaBWglKJS3xrsoMaTc5K9C5Fz3ITX4lniJVy1FW0Ak8UAoT0 f+6s+++fjKm+iousN3YeNg+E9E7Nq6tfVJu7dXVTsDcYBUmtC4ZDwbAW9Qd71VDAW67Wa1Ht HzBVCGHq9mAgJigRdUMvxi1dvbqyDEVVuVobCKjb/F3d0Yi6TY/o4T7d1+zv0SPqZr1f3Rbs 0Xq36V2xgBZOTVB9Ubdq9lfv1MMRMWlV+aoqtXiT3xsORoKd0cUX8U9kk13okR1N2zc1X8T7 kNoc1nx6jxbeowY733Gdaljv8keielj3qf5eNQrWHdvVJi2qLlSbN6lbOjvLVa3Xp+qBiN7f DbbyMUmwULArrIW6ByaSdLU+rPX7e7vEWD+cUaZuj2q9AX0AOoT9kWBvqbrT740Gw+pGLezT e6Mw67Kq5m5/BLoIlbWOgK5GU77s9IcjUVULhXTN1FGwi1osy1g41rgx2OvDinr1/khIC+nh UrUTM/R3+73dqj+q9msR1adH/F29uq9cVTdE1W5QIrGOiH5DDDoEBtQO3Rvs0dVgry7kCUP0 B8MBX0TtCUKBSMzr1SORzlhAqqZ6w7q0YQTShCJYWpe/VwuoPmP1EbUfxlJ74AY11uvTwxdb YREU8od1r3REx8DFNoEDxtZnKAyNeiG0V2DhYKyrG35R9Rujem/E36djkbrwKrBQOChUhYn6 goE+4YnOWBijw2JBe4TlUv6CDpfxGKZbq0Vg66CQD1tCh17Euak4LOdTvTB3zBsFUywiRjbp 4ZAejWkyVpoCWm/UDz/7DTMjIgfUYMCnRqIDcK23WwtrGAtpUb83onbEDP9oPi0kJEaDapdY h36jVw8ExIIDiNEOf8AfHcDEsVAATP3+aLfaFQwiMqFLsGcAWl/n9+lwZCxixElHMLgnIhXq 0bq0m/y9esSIirCOHRBFI2hEqC/ojRlLFMxaIBKUbD5/JBTQBgyir08PR/1ireXd0WiouqKi v7+/vMc0ZDlCp6I72hOo6ImKfxVY0RNpiwrXIR7DYkeWi853ObBfD4hIlEM2b2ne0LChrrZ5 w5bN6pYGdeOGOs/m7R61dt02j2eTZ3OzI8ORIffO2IYReLeMArgOFkMwX2bLylX5sWRYS4Tf QDAmRnqDfTIVGCEr5MBPPXKHaWoAxuoFu9YV1nVhsHK1FcO6NTgr2BHVYGF4b5IyIpP1Y+Oq ul9GoBHycFInzDKuF6wdDXbpRpAKz46NgxOiYT9CBKKhprk7JwSwqRR2yZgpxgYD19Q+LRCT KUWLRPToxNHl6g7sSOyUgdQqsCYzEyIINTUS0r1+hMilK1dhRRHjXXKs5vP5xT7G9g/LM6FU kMPStjKXXKRUwN/jNyNd8ol9GYkaOVlEniQG+5GgYx0Bf6RbzANZhrl7EJLQH64KDahGmJoW mjyRtMeGzvHFiV2IZBeR02DTePVwr7mCsKm3ZI50B2PYrGG9z48DRcTApcsXfPCkjn1q7kXB N7ZGqIUJotjl4z4WC9NMrTsvL1aqPDbAi/zWoacEYR4tWi0YdmyvxaFSvGr5ysXqyqWryiqX V1amp+9oBLFy6dLly1GuXLZSXXnVitUrVjsy3mbXveNmFK0KUz25D/GwHJSPmeKxQDwkDjAH bj124xbk1/LGJdWX+vLPZ3xxxz/Fh/hX+SnACX6SP3zlxcqVFytXXqxcebFCV16sXHmxcuXF ypUXK1derFx5sXLlxcqVFytXXqxcebFy5cXKlRcr/0++WJn07cc4rkn+y/W9dNEYfdL3Isad 9+VlBmSET2hb5luWWhot6yzvQbl60gwiB7+dlM1yz4jcY6y+m8XZ/ZzkvqgFV1ieeUKnt5dw eXzs35tTsgDiL/M5kTzNXxr2eKrcI6hLymWdKF5cJTsSc+ZWfZW/pDyMc8IJwrnEzHzZ82Ji 7VoTuWqVgQwvKas6V5vBX6Q/AhT+Ij+HOJOjhovLqy7UOkBg/AOUxRg56Qj/GcUBCrn5T4cX LKw6fIp/B/3P8KehqRj2dMKRUwWB/86/Qrnk5I/zx8yex4an5lRRbYTfRYxOozwLOA+4ALBQ kD9I+wAHAccBFspC6QRUALYICj/Gj0HPo+KfsqOsAAQBBwEWauZfAn2PKPlDfDcVYuyd/BDN QH2Af0zWX0A9B/XnQJ+P+n60RX3YbH8atej/lEm/F+2ZqD9p1p8APR/1PfKH5E7+cbPdx2Ny XNSsj/BIYr4zu3Y++lVAJYADOwTsEEx3SDgYJeO38oCcaQh1Feoeo4a5bk4UuKSPbh6eNbvq CEx6M0x/Myx3Myx3M1nQtTfFs9fgKeN7wbMXPHvBsxdWqeQRzBcRP2VAmQ1QARx2j8Dugh5H eRpwVtI/iPJuwBHR4v2w42Jo9WG+O1HsRJB1Da92V615gnfC1G7eOTx7XtXB8VZ6hghE1FPN Okvw6rJXH06fIqj68Jx5Rg2uPbVTuZfeD1BoOsoFgOWAeoCFexMLKpwn+WbqSSP3VOc+ZR/f Z9lntVTWs9xTvIqa0gghmcvLqAYMi51tNWxle3oofX86z05X0yvT3elN6dYg38cPcu7kFXwN 38LbuHUkeTphr16Gyr3OVr3s7swjmfHM05lnM61x22nbWdt52wWbVbVV2ty2Jlu7LWTbb7vb dsSWfrftbrvSnhnK3J/JszPVzMpMd2ZTptVpZ0dqb+Md4qcMKLMBIcDdAAts3Aa6yt8HaIM3 2mCK94FOKAmtbMBZ4OdRW9HKAl8W+LJAzQI1S/7+Jkv2NAHaASGz1zbWkxoj+C+IHsAi9E4F Vfx44DzKCwIDXIuWAy0HWg5wnVXehIbZKFVAE4BL2nkAogZlqq/S7G8H2GT/BcmT6nOLscqb bm3R6cUsvpgdWczuXszcNWtqq9yFKHJzc9tcbUVtxW1HLUFXsChYHDxq2eLaUrSleMtRyxrX mqI1xWuOWipcFUUVxRVHLU6Xs8hZ7DxqObjx+MZTG89stLRtDG7ct5GvhOuGEyWVVbIuLBL1 Y4nZc6pWZtW+RzmO5bShPAw4B+CUhdIJqACsAQQBVuW4pD4C6iOgPkJbAG0AK0Y9IlIMSqfZ J+iHZZ/ARL8yqZ9j8Q8nqpdtqd2ItNsGOAzgkP0w+h+W3AZ2XNLjKM9L+haT/4ikCy4nIDVO JMFdMt3twjbcRWsAbYAQwEpn+HV0DgDpKJ2AEOA4wMJ34bqOX6c8guth5WFe6nYsneGkmTNx fOTmpGXXZitTEAsO9pAsPynLD8tyjSwXuKde63jjWsfXrnV86FrHIiBKMQ42BzskywJ3Zq3j 0VrHllrH4loHpM2iAnIoM2RpEyX7rSw3y7LUPb3A8bcCx58LHH8qcHy2wHFDgeM9BWLcXOxh hzJdlpmiZPfI8lpZLnRnOh3fcjquczpWOh21DnYfw+y0VpbzZZkvSvbqo1n1WZT+BHuV6iGJ JWoWO0cUkhVLJmpqUY0mataheitRcx+q/0zUfMz5JPsbk0cbeyOx4BVn7Qz2GttgEe0/m/Wf 2AY6hvoC6i7UD1ANK0L9hUTNLYL/8xj/KbQ/R4Vpgv9+apLjDrMNkv5Zc9xnEqUdmPXTidIB zPopKpWzfiJR+gqoH0uUfhjVRxOlAVQHE0VCwd2JmiXO2hzWRQsUweulIkVostGccT0kB1Cv MwZ7EqViVL2YYITVJVxLUS0SWj7JXNQkp3MmXHKR88glRcwll1Q6n4pkPZVlSeUdVCjrtITr FkixPVr0ivMvNU+IhdPrLCtxn/PlJ7G+nWj+H7Yhccz57AlhroTzTOkIK3rc+T3XE85vLhhh OxPO06Ujaeg4VTqisMecQzByHLwKe9x5vLTL+YhL9h51oReuPlxT5vy0a5fz3iK0E85bSp8U alAPVrwT3a2l1zg31hxzNhSNMHS7azCZO8NZ7Qo7V4O8aoRtGD7mXLpgRKhSCRnHHncuwYwL XVKVHStPKivIzmLuUnvU3mHfad9qv9q+zF5mV+3z7HPt09Ny07LTpqZNSctIS0uzpVnSlDRK mz6SPO8uEb+fm27Llv91hkWUFolnK6JUjJ8SKixNwd6JT+ONSuP2tSye20iNzWvjK0saR+zJ bfFVJY3xtKb3tgwx9pFWtOLKHSOMmlsQoIJ0W7740fQJYqzitrvyRb33trtaW1lj/LSXGjvU +BvbsY6MrbviVtfaPJrZtyZvTe41Oasb6i9TtJtlyfgnr2TiJ29e/J7G7S3xL81rjVcJJDmv tTG+Tvzc+oRygxL01J9QQqJqbTnBblJu8GwTdHZTfesYGxUqIbBRjagE2zAVCjYqZMOSbaNk Q5gWeuqHCgsNpqfYBsGE8HlKMnUZshZgCshqEhXYlPm0QMpaoMwXbIgHQ1jWRGFTiGVJYVlT SAqbK5iGiorAUlokWIZWFoFhqGil7D423u0qMtRppSI5TxFrlfMwNs5TbPAgCkweJQ08Jf+T H33tP8HMhrUXfF7xo/d2l0cHtMcP9HXnxfd3qOqQ7wXz1/AL2zu83aLW9PgLLr0+7nPVq0Oa 9zLdXtGtueqHyOtpbhnyuvX6hObWPC6tvnX4gX11jZPm+vDYXHX7LiNsnxBWJ+Z6oPEy3Y2i +wExV6OYq1HM9YD7ATlX47a1rLGpZSiN1rbWXW/Uw0pmBvZDe35B69qZ2aFr5Oa4uiDvA/kn LYRjK7OkNT7FtTbuAIiustqyWtGF3Sm6por/1sDsyvvA1QX5J9lDZlc2yDmutVRCeR5//dhf JBKJCojFSlBGY3mSFsWmLdjeGG8QP8Kuidd44u72+lYm3BEzP3Ut7uxTNWdqlGDNvpqDNYdr jtdYY7FWkHNPFZ4pVNoKg4X7Cg8WHi48XmgTHde3PO6uOVz4x0IeQzSxKD6eejlnDDX+RDMa i4gPYYIIwJiuJFZS11JbSF7c9TLcoZfRNIALsAywHWCl/4XyB4CXAX8GWOhWlB8DfB4wLCi8 jJd58vz1YsbWEpF08njVcOWKqlUjqLVOo96+y6g9m426prYqD3VizbKM2izcgDM6ifIZwE8B vwH8J8DKq3iVFB4zorY1QpESBvUJjagoIiVRVgKECXNHIyUlJEAEODwA1hI2Oe6JRWIEU8Ah qMAkqRExLCbq1Oe/AHOAPh4KZW5kc3RyZWFtCmVuZG9iagoKMjkgMCBvYmoKODUwNAplbmRv YmoKCjMwIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQkFBQUFBK1Rp bWVzTmV3Um9tYW5QU01UCi9GbGFncyA0Ci9Gb250QkJveFstNTY4IC0zMDYgMjAyNyAxMDA2 XS9JdGFsaWNBbmdsZSAwCi9Bc2NlbnQgODkxCi9EZXNjZW50IC0yMTYKL0NhcEhlaWdodCAx MDA2Ci9TdGVtViA4MAovRm9udEZpbGUyIDI4IDAgUgo+PgplbmRvYmoKCjMxIDAgb2JqCjw8 L0xlbmd0aCAyMjEvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicXZBBT8QgEIXv/Io5 7h420J6bJmbNJj3oGqs/gMK0ktiBTOmh/94pVk08QPJ474M36Gv32FHI+oWj6zHDGMgzLnFl hzDgFEhVNfjg8qHK7mablBa235aMc0djbBqlX8VbMm9wevBxwLPSd/bIgSY4vV970f2a0ifO SBmMalvwOMo9TzY92xl1oS6dFzvk7SLIX+BtSwh10dV3FRc9Lsk6ZEsTqsaYFprbrVVI/p93 EMPoPixLspKkMbUp2eN0p/axftqAW5mlSZm9VNgfD4S/35Ni2qmyvgB9WW11CmVuZHN0cmVh bQplbmRvYmoKCjMyIDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VG b250L0JBQUFBQStUaW1lc05ld1JvbWFuUFNNVAovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDEK L1dpZHRoc1s3NzcgMjUwIF0KL0ZvbnREZXNjcmlwdG9yIDMwIDAgUgovVG9Vbmljb2RlIDMx IDAgUgo+PgplbmRvYmoKCjMzIDAgb2JqCjw8L0YxIDMyIDAgUi9GMiAyMiAwIFIvRjMgMjcg MCBSCj4+CmVuZG9iagoKMzQgMCBvYmoKPDwvRm9udCAzMyAwIFIKL1Byb2NTZXRbL1BERi9U ZXh0XQo+PgplbmRvYmoKCjEgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAxNyAwIFIvUmVz b3VyY2VzIDM0IDAgUi9NZWRpYUJveFswIDAgNzk0IDU5NV0vR3JvdXA8PC9TL1RyYW5zcGFy ZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMiAwIFI+PgplbmRvYmoKCjQg MCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAxNyAwIFIvUmVzb3VyY2VzIDM0IDAgUi9NZWRp YUJveFswIDAgNzk0IDU5NV0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0Iv SSB0cnVlPj4vQ29udGVudHMgNSAwIFI+PgplbmRvYmoKCjcgMCBvYmoKPDwvVHlwZS9QYWdl L1BhcmVudCAxNyAwIFIvUmVzb3VyY2VzIDM0IDAgUi9NZWRpYUJveFswIDAgNzk0IDU5NV0v R3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMg OCAwIFI+PgplbmRvYmoKCjEwIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMTcgMCBSL1Jl c291cmNlcyAzNCAwIFIvTWVkaWFCb3hbMCAwIDc5NCA1OTVdL0Fubm90c1sKMTYgMCBSIF0K L0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRz IDExIDAgUj4+CmVuZG9iagoKMTMgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAxNyAwIFIv UmVzb3VyY2VzIDM0IDAgUi9NZWRpYUJveFswIDAgNzk0IDU5NV0vR3JvdXA8PC9TL1RyYW5z cGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMTQgMCBSPj4KZW5kb2Jq CgozNSAwIG9iago8PC9Db3VudCA1L0ZpcnN0IDM2IDAgUi9MYXN0IDQwIDAgUgo+PgplbmRv YmoKCjM2IDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1 MDAyMDAwMzE+Ci9EZXN0WzEgMCBSL1hZWiAwIDU5NSAwXS9QYXJlbnQgMzUgMCBSL05leHQg MzcgMCBSPj4KZW5kb2JqCgozNyAwIG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2 QzAwNjkwMDY0MDA2NTAwMjAwMDMyPgovRGVzdFs0IDAgUi9YWVogMCA1OTUgMF0vUGFyZW50 IDM1IDAgUi9QcmV2IDM2IDAgUi9OZXh0IDM4IDAgUj4+CmVuZG9iagoKMzggMCBvYmoKPDwv Q291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMz4KL0Rlc3Rb NyAwIFIvWFlaIDAgNTk1IDBdL1BhcmVudCAzNSAwIFIvUHJldiAzNyAwIFIvTmV4dCAzOSAw IFI+PgplbmRvYmoKCjM5IDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2 OTAwNjQwMDY1MDAyMDAwMzQ+Ci9EZXN0WzEwIDAgUi9YWVogMCA1OTUgMF0vUGFyZW50IDM1 IDAgUi9QcmV2IDM4IDAgUi9OZXh0IDQwIDAgUj4+CmVuZG9iagoKNDAgMCBvYmoKPDwvQ291 bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzNT4KL0Rlc3RbMTMg MCBSL1hZWiAwIDU5NSAwXS9QYXJlbnQgMzUgMCBSL1ByZXYgMzkgMCBSPj4KZW5kb2JqCgox NyAwIG9iago8PC9UeXBlL1BhZ2VzCi9SZXNvdXJjZXMgMzQgMCBSCi9NZWRpYUJveFsgMCAw IDc5NCA1OTUgXQovS2lkc1sgMSAwIFIgNCAwIFIgNyAwIFIgMTAgMCBSIDEzIDAgUiBdCi9D b3VudCA1Pj4KZW5kb2JqCgoxNiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9C b3JkZXJbMCAwIDBdL1JlY3RbMTU1LjQgMjQ2LjMgNDA3LjIgMjcxLjldL0E8PC9UeXBlL0Fj dGlvbi9TL1VSSS9VUkkoaHR0cDovL3d3dy5zaG9kYW5ocS5jb20vKT4+Cj4+CmVuZG9iagoK NDEgMCBvYmoKPDwvVHlwZS9DYXRhbG9nL1BhZ2VzIDE3IDAgUgovT3BlbkFjdGlvblsxIDAg UiAvWFlaIG51bGwgbnVsbCAwXQovT3V0bGluZXMgMzUgMCBSCj4+CmVuZG9iagoKNDIgMCBv YmoKPDwvQXV0aG9yPEZFRkYwMDZBMDA2NTAwNjYwMDY2MDAyMDAwNjgwMDZGMDA2NDAwNjcw MDY1MDA3Mz4KL0NyZWF0b3I8RkVGRjAwNDkwMDZEMDA3MDAwNzIwMDY1MDA3MzAwNzM+Ci9Q cm9kdWNlcjxGRUZGMDA0QzAwNjkwMDYyMDA3MjAwNjUwMDRGMDA2NjAwNjYwMDY5MDA2MzAw NjUwMDIwMDAzMzAwMkUwMDM0PgovQ3JlYXRpb25EYXRlKEQ6MjAxMTExMTUwNTU1MDctMDgn MDAnKT4+CmVuZG9iagoKeHJlZgowIDQzCjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAzOTE2 NiAwMDAwMCBuIAowMDAwMDAwMDE5IDAwMDAwIG4gCjAwMDAwMDA0MjggMDAwMDAgbiAKMDAw MDAzOTMxMCAwMDAwMCBuIAowMDAwMDAwNDQ4IDAwMDAwIG4gCjAwMDAwMDEyODggMDAwMDAg biAKMDAwMDAzOTQ1NCAwMDAwMCBuIAowMDAwMDAxMzA4IDAwMDAwIG4gCjAwMDAwMDIyODAg MDAwMDAgbiAKMDAwMDAzOTU5OCAwMDAwMCBuIAowMDAwMDAyMzAwIDAwMDAwIG4gCjAwMDAw MDMwNDggMDAwMDAgbiAKMDAwMDAzOTc2MiAwMDAwMCBuIAowMDAwMDAzMDY5IDAwMDAwIG4g CjAwMDAwMDM4MTIgMDAwMDAgbiAKMDAwMDA0MDczMyAwMDAwMCBuIAowMDAwMDQwNjA3IDAw MDAwIG4gCjAwMDAwMDM4MzMgMDAwMDAgbiAKMDAwMDAyNjU1NSAwMDAwMCBuIAowMDAwMDI2 NTc4IDAwMDAwIG4gCjAwMDAwMjY3NjkgMDAwMDAgbiAKMDAwMDAyNzM4MyAwMDAwMCBuIAow MDAwMDI3ODMwIDAwMDAwIG4gCjAwMDAwMjkxMDYgMDAwMDAgbiAKMDAwMDAyOTEyOCAwMDAw MCBuIAowMDAwMDI5MzIwIDAwMDAwIG4gCjAwMDAwMjk2MjAgMDAwMDAgbiAKMDAwMDAyOTc4 NSAwMDAwMCBuIAowMDAwMDM4Mzc2IDAwMDAwIG4gCjAwMDAwMzgzOTggMDAwMDAgbiAKMDAw MDAzODU5OSAwMDAwMCBuIAowMDAwMDM4ODkwIDAwMDAwIG4gCjAwMDAwMzkwNTggMDAwMDAg biAKMDAwMDAzOTExMSAwMDAwMCBuIAowMDAwMDM5OTA4IDAwMDAwIG4gCjAwMDAwMzk5NjQg MDAwMDAgbiAKMDAwMDA0MDA4NSAwMDAwMCBuIAowMDAwMDQwMjE4IDAwMDAwIG4gCjAwMDAw NDAzNTEgMDAwMDAgbiAKMDAwMDA0MDQ4NSAwMDAwMCBuIAowMDAwMDQwODc4IDAwMDAwIG4g CjAwMDAwNDA5ODAgMDAwMDAgbiAKdHJhaWxlcgo8PC9TaXplIDQzL1Jvb3QgNDEgMCBSCi9J bmZvIDQyIDAgUgovSUQgWyA8NDQyNDRBRjg0RjYzODc5RkUwMUUwNUIwRDZCOTk2RTg+Cjw0 NDI0NEFGODRGNjM4NzlGRTAxRTA1QjBENkI5OTZFOD4gXQovRG9jQ2hlY2tzdW0gL0FGMkFC OTM0NEE4MkJCN0UzRUU3MkZCQjVDMUZFM0M1Cj4+CnN0YXJ0eHJlZgo0MTIxNwolJUVPRgo= --------------070002090109050803000401-- From ietf@meetecho.com Tue Nov 15 06:43:33 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBF511E80DA for ; Tue, 15 Nov 2011 06:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxvlWmVtQe7X for ; Tue, 15 Nov 2011 06:43:33 -0800 (PST) Received: from smtpw1.aruba.it (smtpipvs3.aruba.it [62.149.128.188]) by ietfa.amsl.com (Postfix) with SMTP id 83F0711E80D7 for ; Tue, 15 Nov 2011 06:43:31 -0800 (PST) Received: (qmail 29157 invoked by uid 89); 15 Nov 2011 14:43:30 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw1.ad.aruba.it with SMTP; 15 Nov 2011 14:43:30 -0000 Date: Tue, 15 Nov 2011 15:43:30 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: websec@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 143.225.229.143 X-Spam-Rating: smtpw1.ad.aruba.it 1.6.2 0/1000/N Subject: [websec] Meetecho support for WEBSEC WG meeting session X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 14:43:33 -0000 Hi all,=0A=0Aa virtual room has been reserved on the Meetecho system for = tomorrow's WEBSEC WG meeting session.=0A=0AAccess to the on-line session = (including audio and video streams) will be available from 1:00pm at:=0Ah= ttp://www.meetecho.com/ietf82/websec=0A=0AThe Meetecho session automatica= lly logs you into the standard IETF jabber room. So, from there, you can = have an integrated experience involving all media and allowing you to int= eract with the room.=0A=0AA tutorial of interactivity features of the too= l can be found at:=0Ahttp://www.meetecho.com/ietf82/tutorials=0A=0AFor fu= rther information you can contact us at ietf-support@meetecho.com.=0A=0AC= heers,=0Athe Meetecho team=0A=C2=A0=0A--=C2=A0=0AMeetecho s.r.l.=0AWeb Co= nferencing and Collaboration Tools=0Awww.meetecho.com=0A=C2=A0 From stpeter@stpeter.im Tue Nov 15 13:00:27 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388A611E80BA for ; Tue, 15 Nov 2011 13:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.856 X-Spam-Level: X-Spam-Status: No, score=-102.856 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYuwzJoRQ99g for ; Tue, 15 Nov 2011 13:00:22 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D269311E80C0 for ; Tue, 15 Nov 2011 13:00:22 -0800 (PST) Received: from squire.local (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D8DA94214E for ; Tue, 15 Nov 2011 14:06:35 -0700 (MST) Message-ID: <4EC2D2DF.8050206@stpeter.im> Date: Wed, 16 Nov 2011 05:00:15 +0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: IETF WebSec WG X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [websec] pinning specs X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 21:00:27 -0000 We have: https://datatracker.ietf.org/doc/draft-evans-palmer-key-pinning/ and https://datatracker.ietf.org/doc/draft-evans-palmer-hsts-pinning/ Jeff's slides refer to the former. Are both of these documents in play? Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Nov 15 13:07:44 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC9521F8726 for ; Tue, 15 Nov 2011 13:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.846 X-Spam-Level: X-Spam-Status: No, score=-102.846 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WawQSzJ9Trgt for ; Tue, 15 Nov 2011 13:07:40 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3BA21F86FF for ; Tue, 15 Nov 2011 13:07:40 -0800 (PST) Received: from squire.local (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 302374214E; Tue, 15 Nov 2011 14:13:52 -0700 (MST) Message-ID: <4EC2D496.9040001@stpeter.im> Date: Wed, 16 Nov 2011 05:07:34 +0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Tobias Gondrom References: <4EC2398F.2050201@gondrom.org> In-Reply-To: <4EC2398F.2050201@gondrom.org> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] meeting slides X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 21:07:45 -0000 On 11/15/11 6:06 PM, Tobias Gondrom wrote: > Hello dear websec fellows, > > please find the slides for our meeting tomorrow (Wednesday) at 13:00 > (Taipei time) in room 201 ABC are uploaded to the Meeting Materials > Server: https://datatracker.ietf.org/meeting/82/materials.html > (the slides for HSTS will be uploaded later tonight.) Thanks, Tobias. Other helpful coordinates: Agenda: http://tools.ietf.org/wg/websec/agenda?item=agenda82.html Audio: http://ietf82streaming.dnsalias.net/ietf/ietf826.m3u Chatroom: xmpp:websec@jabber.ietf.org?join Peter -- Peter Saint-Andre https://stpeter.im/ From palmer@google.com Tue Nov 15 13:41:14 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F43011E80DE for ; Tue, 15 Nov 2011 13:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.31 X-Spam-Level: X-Spam-Status: No, score=-103.31 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 pc8V9oE82AH1 for ; Tue, 15 Nov 2011 13:41:09 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A231E11E80D6 for ; Tue, 15 Nov 2011 13:41:09 -0800 (PST) Received: by wwe5 with SMTP id 5so4948126wwe.13 for ; Tue, 15 Nov 2011 13:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=zB/yERtVzlvR2b51rArWjYTvgYVxqPOZXRdAFjJZ5NM=; b=Z9sS5AykfP1dFca2OlGhB1PXd8z7/B/xphJZIkVYqjI6xEbUv4TmHtSR7CfH5fmmvx kwpA2uFVVr7XwNGdeF0A== Received: by 10.216.135.79 with SMTP id t57mr5339216wei.4.1321393268836; Tue, 15 Nov 2011 13:41:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.135.79 with SMTP id t57mr5339212wei.4.1321393268690; Tue, 15 Nov 2011 13:41:08 -0800 (PST) Received: by 10.216.216.205 with HTTP; Tue, 15 Nov 2011 13:41:08 -0800 (PST) In-Reply-To: <4EC2D2DF.8050206@stpeter.im> References: <4EC2D2DF.8050206@stpeter.im> Date: Tue, 15 Nov 2011 13:41:08 -0800 Message-ID: From: Chris Palmer To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: IETF WebSec WG Subject: Re: [websec] pinning specs X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 21:41:14 -0000 > https://datatracker.ietf.org/doc/draft-evans-palmer-key-pinning/ > > and > > https://datatracker.ietf.org/doc/draft-evans-palmer-hsts-pinning/ > > Jeff's slides refer to the former. Are both of these documents in play? No, the former is the real one. It responds to the helpful critiques we got from everyone when we submitted the latter. It is no longer piggy-backing on the HSTS header, so I gave the draft a new, more accurate name. You can safely disregard the latter. From stpeter@stpeter.im Tue Nov 15 13:44:01 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F1911E80E6 for ; Tue, 15 Nov 2011 13:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Om-bBRcY1hzL for ; Tue, 15 Nov 2011 13:43:57 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E4A8011E80DD for ; Tue, 15 Nov 2011 13:43:56 -0800 (PST) Received: from squire.local (unknown [61.31.89.133]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 158F34214E; Tue, 15 Nov 2011 14:50:09 -0700 (MST) Message-ID: <4EC2DD19.2040003@stpeter.im> Date: Wed, 16 Nov 2011 05:43:53 +0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Chris Palmer References: <4EC2D2DF.8050206@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] pinning specs X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 21:44:01 -0000 On 11/16/11 5:41 AM, Chris Palmer wrote: >> https://datatracker.ietf.org/doc/draft-evans-palmer-key-pinning/ >> >> and >> >> https://datatracker.ietf.org/doc/draft-evans-palmer-hsts-pinning/ >> >> Jeff's slides refer to the former. Are both of these documents in play? > > No, the former is the real one. It responds to the helpful critiques > we got from everyone when we submitted the latter. It is no longer > piggy-backing on the HSTS header, so I gave the draft a new, more > accurate name. > > You can safely disregard the latter. OK. I'll send an email message to ietf-action@ietf.org explaining that draft-evans-palmer-key-pinning replaces draft-evans-palmer-hsts-pinning (as a result of which the Secretariat will effectively deprecate the latter). Peter -- Peter Saint-Andre https://stpeter.im/ From hallam@gmail.com Wed Nov 16 12:48:20 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD78511E80AE for ; Wed, 16 Nov 2011 12:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, 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 MgM2yU660e7h for ; Wed, 16 Nov 2011 12:48:19 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 55CCC11E8085 for ; Wed, 16 Nov 2011 12:48:18 -0800 (PST) Received: by faap16 with SMTP id p16so2452973faa.31 for ; Wed, 16 Nov 2011 12:48:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=rew8EyOQvoSNJ/a/hwmcihqx16XDWtlldw0NTjhrN2Q=; b=qX8aJBwNYGwj4XZ3r8dn9fe0R0l/jhk7FB2s7GCzCr+0mnU/Upy/vw8sXounanAW23 6lH1klf/u9wjxv3pMApfiPEA/BxCY0qEcitVsW8rjJg8zJHZbr+HdlGdAH3GeIFBQXYK 5NfAzeOEmoVE37vkfLCfPDcwQclV1i3MdOEac= MIME-Version: 1.0 Received: by 10.182.45.102 with SMTP id l6mr8604458obm.0.1321476496788; Wed, 16 Nov 2011 12:48:16 -0800 (PST) Received: by 10.182.42.99 with HTTP; Wed, 16 Nov 2011 12:48:16 -0800 (PST) Date: Wed, 16 Nov 2011 15:48:16 -0500 Message-ID: From: Phillip Hallam-Baker To: websec Content-Type: multipart/alternative; boundary=f46d0444ef0b2b8f0b04b1e0391e Subject: [websec] Reasons why DANE does not meet all Security Policy Needs X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 20:48:20 -0000 --f46d0444ef0b2b8f0b04b1e0391e Content-Type: text/plain; charset=ISO-8859-1 More information on the scheme I am proposing is to be found in the following document: http://www.ietf.org/id/draft-hallambaker-securitypolicy-01.txt One of the conversations that came up yesterday was why WebSec should do pinning if DANE is already doing this via DNSSEC. At the top level there are three major reasons. 1) WebSec was originally chartered to consider Security Policy in the form of Strict security. Thus as a process matter WebSec has a strong claim to address other forms of security policy 2) The DANE charter does not explicitly call out security policy as a deliverable. Thus while DANE has made Security Policy its primary concern as a WG it has no process claim to 'own' the issue as an IETF matter. 3) The approach taken in DANE does not support Security Policy as a stand alone function., It is only possible to use their key distribution if you also buy into their key distribution, it is only possible to use their key distribution if you buy into their security policy. It is not possible to use either independently. As a result I am unable to use either. In particular, I am very, very annoyed at the constant bleating of 'don't beat up on DNSSEC' followed by attacks on the existing PKIX infrastructure based on the claim that DNSSEC is absolutely perfect in all respects and 'more secure'. This happened several times during the WG meeting this morning. I note that each of the three individuals who protested that this was not the place to discuss the security of DNSSEC then went on to do exactly that. So what they were really demanding was a chance to get in as many free hits as they like against PKIX while running to hide behind mummy when the security of their proposal was examined. I do not have a great deal of respect for that mode of argument. If people want to argue that their new proposal is better then fine. But they are not going to get the free hits they demand. There are in fact many reasons to be skeptical of the DNSSEC system. Note that I am a proponent of DNSSEC and have argued for advancing it for the past ten years. But it is still a completely new infrastructure and is simply not ready for use as a PKIX replacement even if that is considered to be a worthwhile goal. My interest in DNSSEC has from the start been to provide a model of key distribution for very low assurance keys and to provide the basis for a security policy mechanism for very high assurance keys. The two application areas are almost entirely disjoint. First let us consider the components of the DNSSEC system. They have different levels of maturity. 1) ICANN Root Infrastructure 2) Domain Level Signatures 3) Registration of Domain Level Keys via registrars 4) Interface between the registrars and the registries 5) DNS query protocol Of these (1) and (2) are as good as can be expected. The major problems are (3) (4) and (5). On (3) the major problem is that the registrars are not specialists in cryptography. Sale of DNS names is a loss leader as far as their business models are concerned. As a commercial proposition it is highly unlikely that the registrars are going to invest in enabling DNSSEC unless that is going to provide a commercial return. Demand for DNSSEC is currently negligible and likely to remain so until critical mass is established. As a commercial proposition it really makes no difference to a CA if the basis for PKI is PKIX or DNSSEC. They both require the same degree of customer hand holding and support. During a transition period customers would need to deploy both so DNSSEC represents a growth opportunity. DNSSEC does not provide accountability and so does not provide a basis for EV type certificates. The major security problem is at step (4). Contrary to the claim of having a single CA, the DNSSEC ecosystem actually has a separate CA for each top level domain and several hundred entities that function as RAs beneath it. So even though I can only get a .com through the VeriSign registry, I cannot buy a domain from VeriSign direct. I have to go through one of several hundred registrars or several thousand resellers instead. The degree of complexity in those systems is vast. There is no party in the system that has oversight of the whole thing. While there are procedures in place that enforce 'domain locking' at the registry level, these depend on the interface between the resellers and the registrars being correct. Domain hijacking at the registrar level is a very, very frequent occurrence. So frequent that it no longer even attracts notice unless the target is a major player such as Twitter. On (5) the deployment of the DNS protocol does not support DNSSEC sufficiently reliably to use it as the basis for distribution of either key distribution or security policy. The most important limitation on the DANE infrastructure is what it does not attempt to provide. There is no party in the system that accepts any liability for operation of the PKI under any circumstances whatsoever. As a result the injured party in a breach is likely to sue every party they can in a joint action including the registry, registrar and browser vendor. Of these the registry is likely to have a good legal excuse, the registrar is unlikely to have the resources to fight the suit let alone pay damages leaving only the deep pockets of the browser vendor to catch the liability. Expecting that the browser vendors would accept this situation is rather naive. The reason that Microsoft and Netscape insisted on the formation of VeriSign (the CA) in the first place was to catch the liability. DANE as currently proposed requires that the domain owner switch from the established PKIX infrastructure that has known vulnerabilities and a very low rate of breaches to a completely new and untested infrastructure that has frequent breaches and is potentially subject to new and unexpected failure modes. DANE is intentionally an all or nothing proposition. I have to eiher drink all the KoolAid or not do any of it. I cannot pick out and use the parts that I want independently. Unpacking the key distribution and security policy functions and addressing them separately allows for the limitations of the immature DNSSEC system to be worked around. For key distribution any system must be as reliable as existing use of self signed certs. So I want to use a system that only depends on components (1) and (2), the components that are currently mature. DANE does not meet my needs in that respect because it forces me to depend on the DNS query protocol infrastructure what has a major legacy transition problem. The problem of key distribution has in my view been almost completely solved by Kaminsky and Langley in their proposal to pickle out the DNSSEC chain and place it within a certificate. If they are willing to change that approach to putting the DNSSEC validation chain into a stapled OCSP token instead then the objections resulting from the different validity intervals of the DNSSEC data and the Certificate data are completely resolved. The self signed cert can then have the long term validity interval required to make use acceptable with legacy browsers that will query the user on every certificate change and the DNSSEC validity information can be regenerated each time the zone is re-signed. For Security Policy it is very clear that DNS is one of the mechanisms that should be involved. DNS is the Internet infrastructure for making authoritative assertions about domain names. Security policy is an assertion about a domain name. Contrary to the arguments raised in the WG meeting however, effective use of Security Policy published in DNS does not mandate DNSSEC. The most valuable use of Security Policy information is to detect and report violations. Blocking user access to a site only protects one user and false positives impose a major cost. Since Security Policy is a new concept, false positives are inevitable. Over the past decade there has only been one incident in which genuine positives would have been detected and then only if you happened to be in Iran. While demanding a 'hard fail' position is clearly desirable to me from a security point of view, I can't see that I am likely to get it while the browser vendors still refuse to hard fail on lack of access to OCSP data. Over time we may well move to a position where browser vendors are willing to move to a hard fail model on security policy misconfiguration. In the transition period, I see the following as being more likely to be acceptable: * Security Policy Origination Security policy may be declared through DNS records, HTTP headers or out of band means (e.g. tell CABForum or APWG that you are a really serious phishing target). In some cases security policy will be obtained heuristically. * Security Policy Curation Security Policy is hard because it throws up many corner cases that can easily rat hole. Having some form of curation of the raw policy data allows these corner cases to be pushed to some intermediary that can handle them intelligently on a case by case basis. The principle experience that IETF has of security policy is in DKIM. Actual deployed DKIM security policies are of variable quality. But even though the information they provide is not a 100% accurate guide, DKIM works well in practice as one of the (many) inputs into anti-spam systems. Depending on raw Security Policy information may well prove to be impractical. But that is not the only option we have. Anti-Virus systems do not depend on code signing alone, they use it as one input into their systems. Code signing does not prevent code from being malicious, but once malicious code is found signed under a particular key then all other software signed under that key comes under a higher degree of scrutiny. If a Security Policy system is deployed and it just works then this component will be superfluous. Otherwise the ability to perform some form of curation of the raw security policy provides the answer to the various objections being made of practical experience such as what to do when the system administrator fouls up. At present the response to a CA breach involves various parties round the world being called out of bed to respond. We are dealing with an intelligent attacker who changes their attack in response to the countermeasures deployed against them. Thus having the option of curating the raw policy data is likely to be of significant value in developing the right response. * Security Policy Distribution Security policy may be distributed through multiple modes of distribution. No single distribution mode can ever be relied upon in all circumstances and provide the scalability and robustness required. If there is knowledge of an active attack against a very high value domain then the most appropriate technology is to push out a hotlist of security policy statements that includes that domain. That particular mechanism does not scale but it is capable of scaling to provide absolute protection for 95% of the most risky transactions. Even if such a mechanism is never actually used it would be very useful to have in our back pocket to use when needed. http://www.ietf.org/id/draft-hallambaker-securitypolicy-01.txt Hotlists do not scale and so some form of online mechanism is essential. HTTP headers and DNS statements both have pros and cons. But in practice both these channels are subject to MITM attack and DoS by nation state actors. Note that for the Iranian State adversary, denying access to Twitter is one of their main goals. In practice any distribution mechanism that is going to be effective in those environments is going to have to be capable of circumventing the normal communication channels that can be blocked. Thus end clients are going to need to be equipped with the capability to employ a range of distribution mechanisms. -- Website: http://hallambaker.com/ --f46d0444ef0b2b8f0b04b1e0391e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
More information on the scheme I am proposing is to be found in the fo= llowing document:


One of the conversations that came up ye= sterday was why WebSec should do pinning if DANE is already doing this via = DNSSEC. At the top level there are three major reasons.

1) WebSec was originally chartered to consider Security Policy in the = form of Strict security. Thus as a process matter WebSec has a strong claim= to address other forms of security policy

2) The = DANE charter does not=A0explicitly=A0call out security policy as a delivera= ble. Thus while DANE has made Security Policy its primary concern as a WG i= t has no process claim to 'own' the issue as an IETF matter.

3) The approach taken in DANE does not support Security= Policy as a stand alone function., It is only possible to use their key di= stribution if you also buy into their key distribution, it is only possible= to use their key distribution if you buy into their security policy. It is= not possible to use either independently. As a result I am unable to use e= ither.


In particular, I am very, very annoyed a= t the constant bleating of 'don't beat up on DNSSEC' followed b= y attacks on the existing PKIX infrastructure based on the claim that DNSSE= C is absolutely perfect in all respects and 'more secure'.

This happened several times during the WG meeting this = morning. I note that each of the three individuals who protested that this = was not the place to discuss the security of DNSSEC then went on to do exac= tly that. So what they were really demanding was a chance to get in as many= free hits as they like against PKIX while running to hide behind mummy whe= n the security of their proposal was examined. I do not have a great deal o= f respect for that mode of argument. If people want to argue that their new= proposal is better then fine. But they are not going to get the free hits = they demand.


There are in fact many reasons to be ske= ptical of the DNSSEC system. Note that I am a proponent of DNSSEC and have = argued for advancing it for the past ten years. But it is still a completel= y new infrastructure and is simply not ready for use as a PKIX replacement = even if that is considered to be a worthwhile goal.=A0

My interest in DNSSEC has from the start been to provid= e a model of key distribution for very low assurance keys and to provide th= e basis for a security policy mechanism for very high assurance keys. The t= wo application areas are almost entirely disjoint.=A0


First let us consider the components of = the DNSSEC system. They have different levels of maturity.

1) ICANN Root Infrastructure
2) Domain Level Signatures= =A0
3) Registration of Domain Level Keys via registrars
4) Inter= face between the registrars and the registries
5) DNS query proto= col

Of these (1) and (2) are as good as can be exp= ected.

The major problems are (3) (4) and (5).

<= /div>
On (3) the major problem is that the registrars are not specialis= ts in cryptography. Sale of DNS names is a loss leader as far as their busi= ness models are concerned. As a commercial proposition it is highly unlikel= y that the registrars are going to invest in enabling DNSSEC unless that is= going to provide a commercial return. Demand for DNSSEC is currently negli= gible and likely to remain so until critical mass is established.

As a commercial proposition it really makes no differen= ce to a CA if the basis for PKI is PKIX or DNSSEC. They both require the sa= me degree of customer hand holding and support. During a transition period = customers would need to deploy both so DNSSEC represents a growth opportuni= ty. DNSSEC does not provide accountability and so does not provide a basis = for EV type certificates.=A0

The major security problem is at step (4). Contrary to = the claim of having a single CA, the DNSSEC ecosystem actually has a separa= te CA for each top level domain and several hundred entities that function = as RAs beneath it. So even though I can only get a .com through the VeriSig= n registry, I cannot buy a domain from VeriSign direct. I have to go throug= h one of several hundred registrars or several thousand resellers instead.<= /div>

The degree of complexity in those systems is vast. Ther= e is no party in the system that has oversight of the whole thing. While th= ere are procedures in place that enforce 'domain locking' at the re= gistry level, these depend on the interface between the resellers and the r= egistrars being correct.=A0

Domain hijacking at the registrar level is a very, very= frequent occurrence. So frequent that it no longer even attracts notice un= less the target is a major player such as Twitter.

On (5) the deployment of the DNS protocol does not support DNSSEC suff= iciently reliably to use it as the basis for distribution of either key dis= tribution or security policy.

The most important l= imitation on the DANE infrastructure is what it does not attempt to provide= . There is no party in the system that accepts any liability for operation = of the PKI under any circumstances whatsoever. As a result the injured part= y in a breach is likely to sue every party they can in a joint action inclu= ding the registry, registrar and browser vendor. Of these the registry is l= ikely to have a good legal excuse, the registrar is unlikely to have the re= sources to fight the suit let alone pay damages leaving only the deep pocke= ts of the browser vendor to catch the liability.

Expecting that the browser vendors would accept this si= tuation is rather naive. The reason that Microsoft and Netscape insisted on= the formation of VeriSign (the CA) in the first place was to catch the lia= bility.=A0


DANE as currently proposed requires that= the domain owner switch from the established PKIX infrastructure that has = known vulnerabilities and a very low rate of breaches to a completely new a= nd untested infrastructure that has frequent breaches and is potentially su= bject to new and unexpected failure modes. DANE is intentionally an all or = nothing proposition. I have to eiher drink all the KoolAid or not do any of= it. I cannot pick out and use the parts that I want independently.

Unpacking the key distribution and security policy func= tions and addressing them separately allows for the limitations of the imma= ture DNSSEC system to be worked around.


For key distribution any system must be as reliable as existing use of= self signed certs. So I want to use a system that only depends on componen= ts (1) and (2), the components that are currently mature. DANE does not mee= t my needs in that respect because it forces me to depend on the DNS query = protocol infrastructure what has a major legacy transition problem.

The problem of key distribution has in my view been alm= ost completely solved by Kaminsky and Langley in their proposal to pickle o= ut the DNSSEC chain and place it within a certificate. If they are willing = to change that approach to putting the DNSSEC validation chain into a stapl= ed OCSP token instead then the objections resulting from the different vali= dity intervals of the DNSSEC data and the Certificate data are completely r= esolved. The self signed cert can then have the long term validity interval= required to make use acceptable with legacy browsers that will query the u= ser on every certificate change and the DNSSEC validity information can be = regenerated each time the zone is re-signed.


For Security Policy it is very clear tha= t DNS is one of the mechanisms that should be involved. DNS is the Internet= infrastructure for making authoritative assertions about domain names. Sec= urity policy is an assertion about a domain name.

Contrary to the arguments raised in the WG meeting howe= ver, effective use of Security Policy published in DNS does not mandate DNS= SEC.


The most valuable use of Secur= ity Policy information is to detect and report violations. Blocking user ac= cess to a site only protects one user and false positives impose a major co= st. Since Security Policy is a new concept, false positives are inevitable.= Over the past decade there has only been one incident in which genuine pos= itives would have been detected and then only if you happened to be in Iran= . While demanding a 'hard fail' position is clearly desirable to me= from a security point of view, I can't see that I am likely to get it = while the browser vendors still refuse to hard fail on lack of access to OC= SP data.

Over time we may well move to a position where browser = vendors are willing to move to a hard fail model on security policy misconf= iguration. In the transition period, I see the following as being more like= ly to be acceptable:

* Security Policy Origination

= Security policy may be declared through DNS records, HTTP headers or out of= band means (e.g. tell CABForum or APWG that you are a really serious phish= ing target).

In some cases security policy will be obtained heuristi= cally.


* Security Policy Curation

Security Policy is hard because it throws up many c= orner cases that can easily rat hole. Having some form of curation of the r= aw policy data allows these corner cases to be pushed to some intermediary = that can handle them intelligently on a case by case basis.

The principle experience that IETF has of security poli= cy is in DKIM. Actual deployed DKIM security policies are of variable quali= ty. But even though the information they provide is not a 100% accurate gui= de, DKIM works well in practice as one of the (many) inputs into anti-spam = systems.

Depending on raw Security Policy information may well p= rove to be impractical. But that is not the only option we have. Anti-Virus= systems do not depend on code signing alone, they use it as one input into= their systems. Code signing does not prevent code from being malicious, bu= t once malicious code is found signed under a particular key then all other= software signed under that key comes under a higher degree of scrutiny.

If a Security Policy system is deployed and it just wor= ks then this component will be superfluous. Otherwise the ability to perfor= m some form of curation of the raw security policy provides the answer to t= he various objections being made of practical experience such as what to do= when the system administrator fouls up.=A0

At present the response to a CA breach involves various= parties round the world being called out of bed to respond. We are dealing= with an intelligent attacker who changes their attack in response to the c= ountermeasures deployed against them. Thus having the option of curating th= e raw policy data is likely to be of significant value in developing the ri= ght response.


* Security Policy Distribution

Security policy may be distributed through multiple modes o= f distribution. No single distribution mode can ever be relied upon in all = circumstances and provide the scalability and robustness required.

If there is knowledge of an active attack against a ver= y high value domain then the most appropriate technology is to push out a h= otlist of security policy statements that includes that domain. That partic= ular mechanism does not scale but it is capable of scaling to provide absol= ute protection for 95% of the most risky transactions. Even if such a mecha= nism is never actually used it would be very useful to have in our back poc= ket to use when needed.=A0


Hotlists do not scale and so some form= of online mechanism is essential. HTTP headers and DNS statements both hav= e pros and cons. But in practice both these channels are subject to MITM at= tack and DoS by nation state actors. Note that for the Iranian State advers= ary, denying access to Twitter is one of their main goals.

In practice any distribution mechanism that is going to= be effective in those environments is going to have to be capable of circu= mventing the normal communication channels that can be blocked. Thus end cl= ients are going to need to be equipped with the capability to employ a rang= e of distribution mechanisms.

--
Website: http://h= allambaker.com/

--f46d0444ef0b2b8f0b04b1e0391e-- From stpeter@stpeter.im Wed Nov 16 14:12:33 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E380F1F0C38 for ; Wed, 16 Nov 2011 14:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0DX+MScB6Y8 for ; Wed, 16 Nov 2011 14:12:33 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA7E21F8B3F for ; Wed, 16 Nov 2011 14:12:33 -0800 (PST) Received: from squire.local (unknown [61.217.193.77]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1834F421AB for ; Wed, 16 Nov 2011 15:18:48 -0700 (MST) Message-ID: <4EC4354D.8030102@stpeter.im> Date: Thu, 17 Nov 2011 06:12:29 +0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: IETF WebSec WG References: <18B53BA2A483AD45962AAD1397BE1325382F703703@UK-EXCHMBX1.green.sophos> In-Reply-To: <18B53BA2A483AD45962AAD1397BE1325382F703703@UK-EXCHMBX1.green.sophos> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc X-Forwarded-Message-Id: <18B53BA2A483AD45962AAD1397BE1325382F703703@UK-EXCHMBX1.green.sophos> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [websec] Fwd: [Asrg] Phishing and domain reputation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 22:12:34 -0000 Possibly of interest here... -------- Original Message -------- Subject: [Asrg] Phishing and domain reputation Date: Wed, 16 Nov 2011 15:18:28 +0000 From: Martijn Grooten Reply-To: Anti-Spam Research Group - IRTF To: Anti-Spam Research Group - IRTF The anti-phishing working group (APWG) published a report on phishing in the first half of 2011: http://www.apwg.org/reports/APWG_GlobalPhishingSurvey_1H2011.pdf Lots of statistics on phishing, such as a significant rise in attacks compared to the previous six months, which was largely due to attacks on Chinese organisations and their customers. One thing I found interesting, and which prompted me to post about it here, is that only 2% of the phishing domains contained the brand name of a variation thereof (e.g. paypaI dot com) and they've only seen two examples of phishing attacks using IDNs and homographs (e.g. fácebook dot com) in since 2007. Also, only 18% of the domains used (down from 28%) were registered by the phishers themselves; the other domains were hacked or compromised. It suggests that phishers do care about the reputation of domains as used by email/web filters (does the domain have a history of legitimate content?), but little about reputation among users (does the domain look like the one I expect for this site?). I'm not sure about their definition of 'phishing'. This could have some influence on their statistics. Martijn. Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From ynir@checkpoint.com Wed Nov 16 23:09:16 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977241F0CA1 for ; Wed, 16 Nov 2011 23:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.124 X-Spam-Level: X-Spam-Status: No, score=-10.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVOrTbev9WBO for ; Wed, 16 Nov 2011 23:09:16 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 933EA1F0C54 for ; Wed, 16 Nov 2011 23:09:15 -0800 (PST) X-CheckPoint: {4EC4B2C1-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAH79DjN020623 for ; Thu, 17 Nov 2011 09:09:13 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 17 Nov 2011 09:09:13 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 17 Nov 2011 09:09:13 +0200 From: Yoav Nir To: IETF WebSec WG Date: Thu, 17 Nov 2011 09:09:11 +0200 Thread-Topic: Regarding HSTS issue #4 Thread-Index: Acyk989GxGJctcRjT9qJ/9vmum+oHg== Message-ID: <4C85550F-29EE-4596-BEA6-0113B7C08A81@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: [websec] Regarding HSTS issue #4 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 07:09:16 -0000 Hi I thought I would go over the list of issues for HSTS, and got stuck on the= first one (#4). The issue headline is as follows "Clarify that HSTS policy applies to entir= e host (all ports)" The text in draft -01 that addresses this is in section 7.2: Note that the implication of the above steps is that the HSTS policy applies to all TCP ports on a host advertising the HSTS policy. I have two issues with this. First, this does not allow to all *TCP* ports,= only HTTP ports. We don't care about some SSH or FTP port. The text above = that paragraph does say this, but I would remove sweeping references to TCP= . The other issue is that I can think of a use case where it would be OK to u= se HTTP (no S) on another port, and my company m= akes a product with such a use case : A web server might be also running a CA, and that CA may issue a certificat= e for the website. But what is more relevant, the CRL DP for that certifica= te may be co-located with the web site. CRLs (or OCSP responses) need to re= ceived in the clear, otherwise you have a bootstrapping problem, so in that= case, fetching the CRL needs an exception, even though it is to a host tha= t advertises HSTS. I don't believe this is really an issue for implementers. Fetching CRLs is = usually done in a different context from the fetching of content, and the s= ame could be said for hash&URL schemes that some are proposing for TLS, but= I think we should explicitly say that this should apply only to HTTP appli= cation content. Yoav= From alexey.melnikov@isode.com Thu Nov 17 01:01:28 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7349121F9AEF for ; Thu, 17 Nov 2011 01:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1K6lJ-1PKNg for ; Thu, 17 Nov 2011 01:01:27 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 94AFF21F9AF5 for ; Thu, 17 Nov 2011 01:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1321520486; d=isode.com; s=selector; i=@isode.com; bh=s+001mh02Ln4UTw//D5W8sj4wgZ1R0NiPs36llGdnoA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=fiNtPG+5Zjb4Ahhekp0YAVsf7XYknOR0Qdh8SDhK/JE8n36BcNTVtkhgR3YiRwmyYDMk24 5M3cjmbcCe0wHpSEiDdOuXAbDgx5LOsnUgmEi0KLZG4qu5nZ4TJTCLpF1IBbHgKzQewL20 /upoPJ+rosbzEEcNSqLFoPvhsiE+1XM=; Received: from [130.129.18.66] (dhcp-1242.meeting.ietf.org [130.129.18.66]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 17 Nov 2011 09:01:25 +0000 Message-ID: <4EC4CD53.8000802@isode.com> Date: Thu, 17 Nov 2011 09:01:07 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: IETF WebSec WG References: <4EC2D2DF.8050206@stpeter.im> <4EC2DD19.2040003@stpeter.im> In-Reply-To: <4EC2DD19.2040003@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] Acceptance of draft-evans-palmer-key-pinning as a WG document X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:01:28 -0000 Dear WG participants, During the WebSec WG face-to-face meeting in Taipei there was room's rough consensus to accept draft-evans-palmer-key-pinning as a WG document. This is of course subject to confirmation on the WebSec mailing list and this message is doing just that. Please state your preferences about accepting or rejecting this document as a WG document before November 25th in reply to this message, or directly to Tobias and myself. Thank you, Alexey, as a WebSec WG co-chair From ietf@adambarth.com Thu Nov 17 01:04:31 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BD121F9AEF for ; Thu, 17 Nov 2011 01:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.386, 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 z1CrgN5i0vX1 for ; Thu, 17 Nov 2011 01:04:26 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3E9D21F9AE8 for ; Thu, 17 Nov 2011 01:04:26 -0800 (PST) Received: by iaeo4 with SMTP id o4so2214014iae.31 for ; Thu, 17 Nov 2011 01:04:26 -0800 (PST) Received: by 10.231.1.9 with SMTP id 9mr9196573ibd.58.1321520666249; Thu, 17 Nov 2011 01:04:26 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id bu33sm55486540ibb.11.2011.11.17.01.04.24 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 01:04:24 -0800 (PST) Received: by iaeo4 with SMTP id o4so2213964iae.31 for ; Thu, 17 Nov 2011 01:04:24 -0800 (PST) Received: by 10.231.63.9 with SMTP id z9mr9232539ibh.17.1321520664095; Thu, 17 Nov 2011 01:04:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.67.130 with HTTP; Thu, 17 Nov 2011 01:03:53 -0800 (PST) In-Reply-To: <4EC4CD53.8000802@isode.com> References: <4EC2D2DF.8050206@stpeter.im> <4EC2DD19.2040003@stpeter.im> <4EC4CD53.8000802@isode.com> From: Adam Barth Date: Thu, 17 Nov 2011 01:03:53 -0800 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] Acceptance of draft-evans-palmer-key-pinning as a WG document X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:04:31 -0000 Support. On Thu, Nov 17, 2011 at 1:01 AM, Alexey Melnikov wrote: > Dear WG participants, > > During the WebSec WG face-to-face meeting in Taipei there was room's rough > consensus to accept draft-evans-palmer-key-pinning as a WG document. This is > of course subject to confirmation on the WebSec mailing list and this > message is doing just that. > > Please state your preferences about accepting or rejecting this document as > a WG document before November 25th in reply to this message, or directly to > Tobias and myself. > > Thank you, > Alexey, as a WebSec WG co-chair > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From ynir@checkpoint.com Thu Nov 17 01:38:00 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7708221F9A0E for ; Thu, 17 Nov 2011 01:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.423 X-Spam-Level: X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 T415PEpZorql for ; Thu, 17 Nov 2011 01:38:00 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7F58521F99DE for ; Thu, 17 Nov 2011 01:37:59 -0800 (PST) X-CheckPoint: {4EC4D59B-2-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAH9bvYk018569 for ; Thu, 17 Nov 2011 11:37:57 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 17 Nov 2011 11:37:57 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 17 Nov 2011 11:37:57 +0200 From: Yoav Nir To: IETF WebSec WG Date: Thu, 17 Nov 2011 11:37:55 +0200 Thread-Topic: [websec] Acceptance of draft-evans-palmer-key-pinning as a WG document Thread-Index: AcylDJapwBzcgq/aRJ+DHONfRmKrxA== Message-ID: <4E24136E-F302-4C51-B5F8-9CD978514C24@checkpoint.com> References: <4EC2D2DF.8050206@stpeter.im> <4EC2DD19.2040003@stpeter.im> <4EC4CD53.8000802@isode.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: Re: [websec] Acceptance of draft-evans-palmer-key-pinning as a WG document X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:38:00 -0000 On Nov 17, 2011, at 5:03 PM, Adam Barth wrote: > Support. +1 From tom@ritter.vg Thu Nov 17 06:30:53 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFB911E8164 for ; Thu, 17 Nov 2011 06:30:53 -0800 (PST) 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 46R15sXdVwzO for ; Thu, 17 Nov 2011 06:30:52 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD45C11E8163 for ; Thu, 17 Nov 2011 06:30:52 -0800 (PST) Received: by ywt34 with SMTP id 34so1328880ywt.31 for ; Thu, 17 Nov 2011 06:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=n+zQDdf6WzWnUzbohulG4gO8GofeCbgcTTG9B0EPWYs=; b=snTk9obCH4Iv3aIzBdzxeYoytc+pQfSNs7/Gc6t+DfMAYp7UPinRPsM0i7f5AucaaU vWqWK2OU+auC4HiuANb5MPvVG7FE8MCihWpxjxgx54+oaDgWyi+UmDjG6r41vFwan0ne YLIz9biXnQCcZpJG5iL3mMhjLG6QZyh58B4gs= Received: by 10.42.147.65 with SMTP id m1mr42621594icv.27.1321540252178; Thu, 17 Nov 2011 06:30:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.174.71 with HTTP; Thu, 17 Nov 2011 06:30:31 -0800 (PST) In-Reply-To: <4E24136E-F302-4C51-B5F8-9CD978514C24@checkpoint.com> References: <4EC2D2DF.8050206@stpeter.im> <4EC2DD19.2040003@stpeter.im> <4EC4CD53.8000802@isode.com> <4E24136E-F302-4C51-B5F8-9CD978514C24@checkpoint.com> From: Tom Ritter Date: Thu, 17 Nov 2011 09:30:31 -0500 Message-ID: To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [websec] Acceptance of draft-evans-palmer-key-pinning as a WG document X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 14:30:53 -0000 On Nov 17, 2011, at 5:03 PM, Adam Barth wrote: > Support. +1 -tom From hallam@gmail.com Thu Nov 17 07:41:36 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4BC11E8157 for ; Thu, 17 Nov 2011 07:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.116, 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 0DoRPJD--fJW for ; Thu, 17 Nov 2011 07:41:36 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0472711E813B for ; Thu, 17 Nov 2011 07:41:35 -0800 (PST) Received: by faap16 with SMTP id p16so4531588faa.31 for ; Thu, 17 Nov 2011 07:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CF8P+QgpOJgiEtpQaQjpS35lFWuo91fwazX+FyUOUlI=; b=xggJFKC/HkCcUh1TmKND4hUzW3NWvFURRpHQZYvwmk+Jp3TwSTShcqSXjvQL7DYpI/ 19ezchEN6e9QqHmvMwaC0kIXoMqRsUux9TGGVJJJszvCOGM9B7syDBE7adUEksZsX2YO ErHTOhPaAwX+sJEBn3RznFoMjZCvduLQ5U2ms= MIME-Version: 1.0 Received: by 10.182.152.65 with SMTP id uw1mr11716588obb.10.1321544494420; Thu, 17 Nov 2011 07:41:34 -0800 (PST) Received: by 10.182.42.99 with HTTP; Thu, 17 Nov 2011 07:41:34 -0800 (PST) In-Reply-To: References: <4EC2D2DF.8050206@stpeter.im> <4EC2DD19.2040003@stpeter.im> <4EC4CD53.8000802@isode.com> <4E24136E-F302-4C51-B5F8-9CD978514C24@checkpoint.com> Date: Thu, 17 Nov 2011 10:41:34 -0500 Message-ID: From: Phillip Hallam-Baker To: Tom Ritter Content-Type: multipart/alternative; boundary=f46d0444ef0325126a04b1f00ea0 Cc: IETF WebSec WG Subject: Re: [websec] Acceptance of draft-evans-palmer-key-pinning as a WG document X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 15:41:37 -0000 --f46d0444ef0325126a04b1f00ea0 Content-Type: text/plain; charset=ISO-8859-1 +1 On Thu, Nov 17, 2011 at 9:30 AM, Tom Ritter wrote: > On Nov 17, 2011, at 5:03 PM, Adam Barth wrote: > > Support. > > +1 > > -tom > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/ --f46d0444ef0325126a04b1f00ea0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

On Thu, Nov 17, 2011 at 9:30 AM, Tom R= itter <tom@ritter.vg<= /a>> wrote:
On Nov 17, 2011, at 5:03 PM, Adam Barth wrote:
> Support.

+1

-tom
_____________________= __________________________
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec



--
= Website: http://hallambaker.com/
--f46d0444ef0325126a04b1f00ea0-- From alexey.melnikov@isode.com Mon Nov 21 02:23:35 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B4221F8B9F for ; Mon, 21 Nov 2011 02:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.985 X-Spam-Level: X-Spam-Status: No, score=-100.985 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, J_CHICKENPOX_43=0.6, 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 POMoLZF4dWiC for ; Mon, 21 Nov 2011 02:23:31 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id CB2A421F8B9B for ; Mon, 21 Nov 2011 02:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1321870919; d=isode.com; s=selector; i=@isode.com; bh=FGhI5m7UjUmM0SO65PUKQtdWVoi3RGC+m2Hm2UlL/Rs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=frZgZJ5ATUy1wjjTIYtuGqznGr40HsXPzAU0QeA1kJfFG6KLzaoRDmJEACyI0hh6pO8uzd /C2GEp0QXSfhP+hjhHRQP3PNCXKIA4uK23grBmHYsQEKq5WEgTyeEPE8bXJ5qwbiE7T5KR f5zWArlKzQjODwsjSsO2yREjW8BdHDs=; Received: from [192.168.1.144] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 21 Nov 2011 10:21:59 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4EC8BB7B.5040908@isode.com> Date: Sun, 20 Nov 2011 08:34:03 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: Yoav Nir References: <4C85550F-29EE-4596-BEA6-0113B7C08A81@checkpoint.com> In-Reply-To: <4C85550F-29EE-4596-BEA6-0113B7C08A81@checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] Regarding HSTS issue #4 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 10:23:35 -0000 On 17/11/2011 07:09, Yoav Nir wrote: > Hi Hi Yaov, > I thought I would go over the list of issues for HSTS, and got stuck on the first one (#4). > > The issue headline is as follows "Clarify that HSTS policy applies to entire host (all ports)" > > The text in draft -01 that addresses this is in section 7.2: > Note that the implication of the above steps is that the HSTS policy > applies to all TCP ports on a host advertising the HSTS policy. > > I have two issues with this. First, this does not allow to all *TCP* ports, only HTTP ports. We don't care about some SSH or FTP port. The text above that paragraph does say this, but I would remove sweeping references to TCP. +1. > The other issue is that I can think of a use case where it would be OK to use HTTP (no S) on another port, and my company makes a product with such a use case: > > A web server might be also running a CA, and that CA may issue a certificate for the website. But what is more relevant, the CRL DP for that certificate may be co-located with the web site. CRLs (or OCSP responses) need to received in the clear, otherwise you have a bootstrapping problem, so in that case, fetching the CRL needs an exception, even though it is to a host that advertises HSTS. Right. > I don't believe this is really an issue for implementers. Fetching CRLs is usually done in a different context from the fetching of content, and the same could be said for hash&URL schemes that some are proposing for TLS, but I think we should explicitly say that this should apply only to HTTP application content. If I were to add some text to describe this, I wouldn't use "HTTP application content", as this is still sounds ambiguos to me. Is your recommendation to exclude protocols running over HTTP (as opposed to classical HTTP use)? From ynir@checkpoint.com Mon Nov 21 03:56:20 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C4621F8BE9 for ; Mon, 21 Nov 2011 03:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.135 X-Spam-Level: X-Spam-Status: No, score=-10.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqVtv736KWhV for ; Mon, 21 Nov 2011 03:56:19 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 12E8421F8BE4 for ; Mon, 21 Nov 2011 03:56:18 -0800 (PST) X-CheckPoint: {4ECA3BDE-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pALBuHwN005404; Mon, 21 Nov 2011 13:56:17 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 21 Nov 2011 13:56:15 +0200 From: Yoav Nir To: Alexey Melnikov Date: Mon, 21 Nov 2011 13:56:16 +0200 Thread-Topic: [websec] Regarding HSTS issue #4 Thread-Index: AcyoRJIs2qODy68CQBqCseQWXjibiw== Message-ID: References: <4C85550F-29EE-4596-BEA6-0113B7C08A81@checkpoint.com> <4EC8BB7B.5040908@isode.com> In-Reply-To: <4EC8BB7B.5040908@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] Regarding HSTS issue #4 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 11:56:20 -0000 On Nov 20, 2011, at 10:34 AM, Alexey Melnikov wrote: > On 17/11/2011 07:09, Yoav Nir wrote: >> Hi > Hi Yaov, >> I thought I would go over the list of issues for HSTS, and got stuck on = the first one (#4). >>=20 >> The issue headline is as follows "Clarify that HSTS policy applies to en= tire host (all ports)" >>=20 >> The text in draft -01 that addresses this is in section 7.2: >> Note that the implication of the above steps is that the HSTS policy >> applies to all TCP ports on a host advertising the HSTS policy. >>=20 >> I have two issues with this. First, this does not allow to all *TCP* por= ts, only HTTP ports. We don't care about some SSH or FTP port. The text abo= ve that paragraph does say this, but I would remove sweeping references to = TCP. > +1. >> The other issue is that I can think of a use case where it would be OK t= o use HTTP (no S) on another port, and my compan= y makes a product with such a use case: >>=20 >> A web server might be also running a CA, and that CA may issue a certifi= cate for the website. But what is more relevant, the CRL DP for that certif= icate may be co-located with the web site. CRLs (or OCSP responses) need to= received in the clear, otherwise you have a bootstrapping problem, so in t= hat case, fetching the CRL needs an exception, even though it is to a host = that advertises HSTS. > Right. >> I don't believe this is really an issue for implementers. Fetching CRLs = is usually done in a different context from the fetching of content, and th= e same could be said for hash&URL schemes that some are proposing for TLS, = but I think we should explicitly say that this should apply only to HTTP ap= plication content. > If I were to add some text to describe this, I wouldn't use "HTTP=20 > application content", as this is still sounds ambiguos to me. >=20 > Is your recommendation to exclude protocols running over HTTP (as=20 > opposed to classical HTTP use)? I guess so, but web services should probably also be protected under HSTS. = CRL and OCSP fetching are special cases that are never protected by TLS bec= ause their content is signed and because it would cause a bootstrap problem= .= From ietf@meetecho.com Mon Nov 21 06:32:02 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A2E11E80BE for ; Mon, 21 Nov 2011 06:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.476 X-Spam-Level: X-Spam-Status: No, score=-0.476 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R9oN6Aoa2vO for ; Mon, 21 Nov 2011 06:31:58 -0800 (PST) Received: from smtplq04.aruba.it (smtplq-out19.aruba.it [62.149.158.39]) by ietfa.amsl.com (Postfix) with SMTP id 109E411E8096 for ; Mon, 21 Nov 2011 06:31:57 -0800 (PST) Received: (qmail 5374 invoked by uid 89); 21 Nov 2011 14:31:56 -0000 Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq04.aruba.it with SMTP; 21 Nov 2011 14:31:56 -0000 Received: (qmail 10873 invoked by uid 89); 21 Nov 2011 14:31:56 -0000 Received: from unknown (HELO ?143.225.229.189?) (ietf@meetecho.com@143.225.229.189) by smtp8.ad.aruba.it with SMTP; 21 Nov 2011 14:31:56 -0000 Message-ID: <4ECA60CE.9040906@meetecho.com> Date: Mon, 21 Nov 2011 15:31:42 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: websec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp8.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Subject: [websec] WEBSEC session recording available X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 14:32:02 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of WEBSEC session at IETF-82 is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/82/remote-participation.html#Meetecho), or by directly accessing the following URL: http://www.meetecho.com/ietf82/recordings#WEBSEC For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From Jeff.Hodges@KingsMountain.com Tue Nov 22 13:42:21 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFA421F8B43 for ; Tue, 22 Nov 2011 13:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.221 X-Spam-Level: X-Spam-Status: No, score=-100.221 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kDLbBuyuSUD for ; Tue, 22 Nov 2011 13:42:21 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 169F521F8B42 for ; Tue, 22 Nov 2011 13:42:21 -0800 (PST) Received: (qmail 19275 invoked by uid 0); 22 Nov 2011 21:42:20 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 22 Nov 2011 21:42:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=YIsI7dndp5vBuSNVrXtgf6czo2jeYJ7Y1e2VVi1C5EM=; b=z9CWa+cA5hOZYRg8PSZRRShJb2q1LMvQzhCoqx9MgL+AvOInrY6SX5eKpwiBpCARfIJwyzXrUK/q/jf132M8VEhx71MnCJdAWuBmyIV3K0eAudH8kVBseNMDF1vUp1tD; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.106]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RSy6e-0006v3-6O for websec@ietf.org; Tue, 22 Nov 2011 14:42:20 -0700 Message-ID: <4ECC173B.5090104@KingsMountain.com> Date: Tue, 22 Nov 2011 13:42:19 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [websec] Acceptance of draft-evans-palmer-key-pinning as a WG document X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 21:42:21 -0000 > During the WebSec WG face-to-face meeting in Taipei there was room's > rough consensus to accept draft-evans-palmer-key-pinning as a WG > document. This is of course subject to confirmation on the WebSec > mailing list and this message is doing just that. > > Please state your preferences about accepting or rejecting this document > as a WG document before November 25th in reply to this message, or > directly to Tobias and myself. i support acceptance. =JeffH From ietf@adambarth.com Tue Nov 22 13:43:31 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A338C21F8482 for ; Tue, 22 Nov 2011 13:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=0.348, 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 MV-LgrlHWl8s for ; Tue, 22 Nov 2011 13:43:31 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D560021F849B for ; Tue, 22 Nov 2011 13:43:30 -0800 (PST) Received: by ggnp4 with SMTP id p4so812011ggn.31 for ; Tue, 22 Nov 2011 13:43:30 -0800 (PST) Received: by 10.50.40.198 with SMTP id z6mr5260067igk.39.1321998210167; Tue, 22 Nov 2011 13:43:30 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id z10sm64444159ibv.9.2011.11.22.13.43.28 (version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 13:43:28 -0800 (PST) Received: by iaeo4 with SMTP id o4so852794iae.31 for ; Tue, 22 Nov 2011 13:43:28 -0800 (PST) Received: by 10.50.160.161 with SMTP id xl1mr25064338igb.5.1321998208192; Tue, 22 Nov 2011 13:43:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.67.130 with HTTP; Tue, 22 Nov 2011 13:42:57 -0800 (PST) In-Reply-To: <4ECC173B.5090104@KingsMountain.com> References: <4ECC173B.5090104@KingsMountain.com> From: Adam Barth Date: Tue, 22 Nov 2011 13:42:57 -0800 Message-ID: To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] Acceptance of draft-evans-palmer-key-pinning as a WG document X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 21:43:31 -0000 On Tue, Nov 22, 2011 at 1:42 PM, =JeffH wrote: >> During the WebSec WG face-to-face meeting in Taipei there was room's >> rough consensus to accept draft-evans-palmer-key-pinning as a WG >> document. This is of course subject to confirmation on the WebSec >> mailing list and this message is doing just that. >> >> Please state your preferences about accepting or rejecting this document >> as a WG document before November 25th in reply to this message, or >> directly to Tobias and myself. > > i support acceptance. +1 Adam From martin.thomson@gmail.com Tue Nov 22 14:58:39 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112181F0C4A for ; Tue, 22 Nov 2011 14:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMwIslKJltAC for ; Tue, 22 Nov 2011 14:58:38 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C31E81F0C47 for ; Tue, 22 Nov 2011 14:58:37 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so454630bkb.31 for ; Tue, 22 Nov 2011 14:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=kJn0GhnX20P44nN65KObBcqtsdjBG4RXzgb2gd1ugXw=; b=rMfHOJobcNMu2ZF6EZI28Dh9Nlo5IUYUf1uUKmdb4OZM17LPH8+DhPMRIp3civ71mK EFbxsKGlDGkSXpOzlTOB6FQRpxdprE94tSuHvpl2WITAufBIHwhyXPuV/9wQ510Rv5vH ggsFjHz+ZyGt9zYDBaCOPw6QGevY0FCdxqa0w= MIME-Version: 1.0 Received: by 10.204.14.208 with SMTP id h16mr20721684bka.2.1322002716819; Tue, 22 Nov 2011 14:58:36 -0800 (PST) Received: by 10.204.72.210 with HTTP; Tue, 22 Nov 2011 14:58:36 -0800 (PST) Date: Wed, 23 Nov 2011 09:58:36 +1100 Message-ID: From: Martin Thomson To: websec@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [websec] Brief comments on draft-evans-palmer-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 22:58:39 -0000 It would be helpful if the document described the expected recovery process after loss/compromise of the main key. I expect this is as simple as: use backup, send header with hash for new key(s). That is, the process by which a new key can be deployed in general. The document doesn't really talk about how clients are expected to react to a changed header. Can the header be shortened to something that takes fewer bytes like 'Key-Pins'? --Martin From martin.thomson@gmail.com Tue Nov 22 14:58:48 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA361F0C47 for ; Tue, 22 Nov 2011 14:58:48 -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 mkMytJmUkcEF for ; Tue, 22 Nov 2011 14:58:48 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 086E51F0C69 for ; Tue, 22 Nov 2011 14:58:47 -0800 (PST) Received: by mail-bw0-f44.google.com with SMTP id zv15so454630bkb.31 for ; Tue, 22 Nov 2011 14:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7yoZlcjBMRFfO/TkOKxx7BQ+vGvUKUX4k1FePGkU/QY=; b=CxOENba+vvEvPi5kdyFRSkg/PGf8huw23uSu+NjzCGA5vFQvY3oqEGv7OMIsJRLIPq bDKZcfo7NmVATL8O/ZXEhGjkaNAh33MbmMTvS2tC2up/dolvSQbdcho/xsK2aVDrbE1V sIhWf4mDOpdD28QAvccC6HjJJ4HfOljiU5ujo= MIME-Version: 1.0 Received: by 10.204.154.6 with SMTP id m6mr21586149bkw.20.1322002727691; Tue, 22 Nov 2011 14:58:47 -0800 (PST) Received: by 10.204.72.210 with HTTP; Tue, 22 Nov 2011 14:58:47 -0800 (PST) In-Reply-To: References: <4ECC173B.5090104@KingsMountain.com> Date: Wed, 23 Nov 2011 09:58:47 +1100 Message-ID: From: Martin Thomson To: Adam Barth Content-Type: text/plain; charset=UTF-8 Cc: IETF WebSec WG Subject: Re: [websec] Acceptance of draft-evans-palmer-key-pinning as a WG document X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 22:58:48 -0000 On 23 November 2011 08:42, Adam Barth wrote: > On Tue, Nov 22, 2011 at 1:42 PM, =JeffH wrote: >>> Please state your preferences about accepting or rejecting this document >>> as a WG document before November 25th in reply to this message, or >>> directly to Tobias and myself. >> >> i support acceptance. > > +1 +1 From annevk@opera.com Wed Nov 23 04:47:43 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C079021F8C70 for ; Wed, 23 Nov 2011 04:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 DTm9-Bje9rve for ; Wed, 23 Nov 2011 04:47:43 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id B9CA821F8C68 for ; Wed, 23 Nov 2011 04:47:42 -0800 (PST) Received: from annevk-macbookpro.local (5355737B.cm-6-6b.dynamic.ziggo.nl [83.85.115.123]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pANCldxb031725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 23 Nov 2011 12:47:40 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: websec Date: Wed, 23 Nov 2011 13:47:39 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Anne van Kesteren" Organization: Opera Software Message-ID: User-Agent: Opera Mail/11.52 (MacIntel) Subject: [websec] Define cross-origin X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 12:47:43 -0000 Often it is convenient to use cross-origin in a specification rather than non same origin. Can this term be added to http://tools.ietf.org/html/draft-ietf-websec-origin#section-5 That would be most useful. -- Anne van Kesteren http://annevankesteren.nl/ From julian.reschke@gmx.de Wed Nov 23 05:07:47 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6451221F8C99 for ; Wed, 23 Nov 2011 05:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.987 X-Spam-Level: X-Spam-Status: No, score=-103.987 tagged_above=-999 required=5 tests=[AWL=-1.388, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq2ucvIak7M4 for ; Wed, 23 Nov 2011 05:07:47 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 74EB821F8C8C for ; Wed, 23 Nov 2011 05:07:46 -0800 (PST) Received: (qmail invoked by alias); 23 Nov 2011 13:07:44 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp042) with SMTP; 23 Nov 2011 14:07:44 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/hdcpyf27hHcbabbsKuCVomSDar0bwfTHmL/yRu0 2oPnGy2juRHLb9 Message-ID: <4ECCF01D.5060403@gmx.de> Date: Wed, 23 Nov 2011 14:07:41 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Anne van Kesteren References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: websec Subject: Re: [websec] Define cross-origin X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 13:07:47 -0000 On 2011-11-23 13:47, Anne van Kesteren wrote: > Often it is convenient to use cross-origin in a specification rather > than non same origin. Can this term be added to > > http://tools.ietf.org/html/draft-ietf-websec-origin#section-5 > > That would be most useful. Seems to be too late, it's in the publication queue: . Best regards, Julian From tobias.gondrom@gondrom.org Wed Nov 23 05:23:07 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3266021F8888 for ; Wed, 23 Nov 2011 05:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.778 X-Spam-Level: X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-SoBCBJHF6P for ; Wed, 23 Nov 2011 05:23:06 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3D321F886A for ; Wed, 23 Nov 2011 05:23:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=NsCL4GBjGwntRVbruGp352gkFIOnUK53NfVvSzc6wtaDS27rrsNfmmmEKVgB5BTAtvroXvdUM9647mfYLhkjXGbneZ4gC35qo4ziDgXGvN375H/ZWIdSmJiI3ywGExFl; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 9505 invoked from network); 23 Nov 2011 14:22:05 +0100 Received: from unknown (HELO ?218.188.76.137?) (218.188.76.137) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Nov 2011 14:22:04 +0100 Message-ID: <4ECCF376.8030503@gondrom.org> Date: Wed, 23 Nov 2011 13:21:58 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: websec@ietf.org X-Priority: 4 (Low) References: <4ECCF01D.5060403@gmx.de> In-Reply-To: <4ECCF01D.5060403@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] Define cross-origin X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 13:23:07 -0000 Yes, I am sorry, but this is too late for origin. It passed IETF LC, IESG and IANA and is now in the final RFC-Editor queue before it will be published very shortly. Best regards, Tobias Ps.: @Anne: not sure, but maybe alternatively worth considering adding your idea to the framework-reqs document? On 23/11/11 13:07, Julian Reschke wrote: > On 2011-11-23 13:47, Anne van Kesteren wrote: >> Often it is convenient to use cross-origin in a specification rather >> than non same origin. Can this term be added to >> >> http://tools.ietf.org/html/draft-ietf-websec-origin#section-5 >> >> That would be most useful. > > Seems to be too late, it's in the publication queue: > . > > Best regards, Julian > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From philipj@opera.com Fri Nov 25 05:37:41 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BFC21F8B85 for ; Fri, 25 Nov 2011 05:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.44 X-Spam-Level: X-Spam-Status: No, score=-4.44 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_8BIT_HEADER=0.3, 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 cctRPO0IyEqp for ; Fri, 25 Nov 2011 05:37:41 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id BFB2E21F8B86 for ; Fri, 25 Nov 2011 05:37:40 -0800 (PST) Received: from kirk (oslo.jvpn.opera.com [213.236.208.46]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pAPDbb2Q027701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 25 Nov 2011 13:37:39 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Date: Fri, 25 Nov 2011 14:37:50 +0100 To: websec@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: =?utf-8?Q?Philip_J=C3=A4genstedt?= Organization: Opera Software Message-ID: User-Agent: Opera Mail/12.00 (Linux) X-Mailman-Approved-At: Fri, 25 Nov 2011 05:55:05 -0800 Subject: [websec] mimesniff feedback X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 13:37:41 -0000 http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-03 The right column is misaligned for: +-------------------+-------------------+-----------------+------------+= | FF FF FF FF FF FF | WS 3C 3f 78 6d 6c | text/xml | Scriptable |= | Comment: ) | +-------------------+-------------------+-----------------+------------+= +-------------------+-------------------+-----------------+------------+= | FF FF FF FF FF | 4F 67 67 53 00 | application/ogg | Safe |= | Comment: An Ogg audio or video signature. | +-------------------+-------------------+-----------------+------------+= Typo: "as define in" In 6.1 "Signature for MP4": * If implemented naively, it can "segfault" at step "If octets 5 through= = 8..." for n<8. * I don't know anything about the MP4 file format, but there's an = off-by-one error in "If octets 4*i through 4*i + 3 (inclusive)". It seem= s = likely that the magic bytes are aligned on 4 byte boundaries and that it= = should be "4*i+1 through 4*i+3". That'll also make the octet count 3, to= = match "mp4". * The initial check is for n<4, but the algorithm can only return true f= or = n>=3D12. Adjusting that solves the "segfault" as well. -- = Philip J=C3=A4genstedt Core Developer Opera Software From ietf@adambarth.com Fri Nov 25 17:42:15 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D8421F8AE9 for ; Fri, 25 Nov 2011 17:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 dPssKUf7lyMj for ; Fri, 25 Nov 2011 17:42:14 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8111B21F8AD6 for ; Fri, 25 Nov 2011 17:42:14 -0800 (PST) Received: by iaeo4 with SMTP id o4so6354907iae.31 for ; Fri, 25 Nov 2011 17:42:14 -0800 (PST) Received: by 10.231.45.9 with SMTP id c9mr655851ibf.73.1322271734162; Fri, 25 Nov 2011 17:42:14 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id a2sm61569053igj.7.2011.11.25.17.42.11 (version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 17:42:11 -0800 (PST) Received: by iaeo4 with SMTP id o4so6354854iae.31 for ; Fri, 25 Nov 2011 17:42:11 -0800 (PST) Received: by 10.50.217.195 with SMTP id pa3mr40162353igc.12.1322271731092; Fri, 25 Nov 2011 17:42:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.67.130 with HTTP; Fri, 25 Nov 2011 17:41:40 -0800 (PST) In-Reply-To: References: From: Adam Barth Date: Fri, 25 Nov 2011 17:41:40 -0800 Message-ID: To: =?ISO-8859-1?Q?Philip_J=E4genstedt?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] mimesniff feedback X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 01:42:15 -0000 On Fri, Nov 25, 2011 at 5:37 AM, Philip J=E4genstedt wr= ote: > http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-03 > > The right column is misaligned for: > > +-------------------+-------------------+-----------------+------------+ > | FF FF FF FF FF FF | WS 3C 3f 78 6d 6c | text/xml =A0 =A0 =A0 =A0| Scrip= table | > | Comment: ) =A0| > +-------------------+-------------------+-----------------+------------+ > > +-------------------+-------------------+-----------------+------------+ > | FF FF FF FF FF =A0 =A0| 4F 67 67 53 00 =A0 =A0| application/ogg | Safe = =A0 =A0 =A0 | > | Comment: An Ogg audio or video signature. =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | > +-------------------+-------------------+-----------------+------------+ > > Typo: "as define in" This appears to have already been fixed in my local copy. > In 6.1 "Signature for MP4": > > * If implemented naively, it can "segfault" at step "If octets 5 through > 8..." for n<8. Fixed. > * I don't know anything about the MP4 file format, but there's an off-by-= one > error in "If octets 4*i through 4*i + 3 (inclusive)". It seems likely tha= t > the magic bytes are aligned on 4 byte boundaries and that it should be > "4*i+1 through 4*i+3". That'll also make the octet count 3, to match "mp4= ". I've made all these indicies consistently zero-based and I've added a note that the indicies are zero-based. > * The initial check is for n<4, but the algorithm can only return true fo= r > n>=3D12. Adjusting that solves the "segfault" as well. Fixed. Thanks! Adam From philipj@opera.com Fri Nov 25 07:15:00 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739C921F8BF6 for ; Fri, 25 Nov 2011 07:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.37 X-Spam-Level: X-Spam-Status: No, score=-5.37 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 BAgrs1Rl5hOJ for ; Fri, 25 Nov 2011 07:15:00 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id A99D221F8BF0 for ; Fri, 25 Nov 2011 07:14:59 -0800 (PST) Received: from kirk (oslo.jvpn.opera.com [213.236.208.46]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pAPFEswT009739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 25 Nov 2011 15:14:54 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Date: Fri, 25 Nov 2011 16:15:06 +0100 To: "websec@ietf.org" MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: =?utf-8?Q?Philip_J=C3=A4genstedt?= Organization: Opera Software Message-ID: User-Agent: Opera Mail/12.00 (Linux) X-Mailman-Approved-At: Fri, 25 Nov 2011 20:10:56 -0800 Subject: [websec] mimesniff feedback, part 2 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 15:15:00 -0000 A rather serious issue in "Signature for MP4": the spec says that box si= ze = is little-endian, but every .mp4 file I have tested are in fact = big-endian. For example, here's a hexdump of the beginning of = sample_100kbit.mp4, a sample file from Darwin Streaming Server 6.0.3: 00000000 00 00 00 18 66 74 79 70 6d 70 34 32 00 00 00 01 = |....ftypmp42....| 00000010 6d 70 34 32 6d 70 34 31 00 00 5a eb 6d 6f 6f 76 = |mp42mp41..Z.moov| 00000020 00 00 00 6c 6d 76 68 64 00 00 00 00 be 44 3f 8d = |...lmvhd.....D?.| -- = Philip J=C3=A4genstedt Core Developer Opera Software From ietf@adambarth.com Fri Nov 25 20:26:38 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B4021F8AB8 for ; Fri, 25 Nov 2011 20:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 9d4KZl5ReBrl for ; Fri, 25 Nov 2011 20:26:37 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEAEB21F8A69 for ; Fri, 25 Nov 2011 20:26:37 -0800 (PST) Received: by iaeo4 with SMTP id o4so6543072iae.31 for ; Fri, 25 Nov 2011 20:26:37 -0800 (PST) Received: by 10.231.61.210 with SMTP id u18mr72030ibh.86.1322281597432; Fri, 25 Nov 2011 20:26:37 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id j1sm62370932igq.2.2011.11.25.20.26.36 (version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 20:26:36 -0800 (PST) Received: by iaeo4 with SMTP id o4so6543033iae.31 for ; Fri, 25 Nov 2011 20:26:36 -0800 (PST) Received: by 10.50.217.195 with SMTP id pa3mr40530590igc.12.1322281596113; Fri, 25 Nov 2011 20:26:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.67.130 with HTTP; Fri, 25 Nov 2011 20:26:05 -0800 (PST) In-Reply-To: References: From: Adam Barth Date: Fri, 25 Nov 2011 20:26:05 -0800 Message-ID: To: =?ISO-8859-1?Q?Philip_J=E4genstedt?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] mimesniff feedback, part 2 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 04:26:38 -0000 Yes. Bid-endian is correct. The IETF draft you're reading expired on November 8. Adam On Fri, Nov 25, 2011 at 7:15 AM, Philip J=E4genstedt wr= ote: > A rather serious issue in "Signature for MP4": the spec says that box siz= e > is little-endian, but every .mp4 file I have tested are in fact big-endia= n. > For example, here's a hexdump of the beginning of sample_100kbit.mp4, a > sample file from Darwin Streaming Server 6.0.3: > > 00000000 =A000 00 00 18 66 74 79 70 =A06d 70 34 32 00 00 00 01 > =A0|....ftypmp42....| > 00000010 =A06d 70 34 32 6d 70 34 31 00 00 5a eb 6d 6f 6f 76 > =A0|mp42mp41..Z.moov| > 00000020 =A000 00 00 6c 6d 76 68 64 =A000 00 00 00 be 44 3f 8d > =A0|...lmvhd.....D?.| > > -- > Philip J=E4genstedt > Core Developer > Opera Software > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From julian.reschke@gmx.de Sat Nov 26 04:57:38 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78B321F8B5C for ; Sat, 26 Nov 2011 04:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.315 X-Spam-Level: X-Spam-Status: No, score=-104.315 tagged_above=-999 required=5 tests=[AWL=-1.716, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY116KNLg5gQ for ; Sat, 26 Nov 2011 04:57:38 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 096D421F8B4A for ; Sat, 26 Nov 2011 04:57:37 -0800 (PST) Received: (qmail invoked by alias); 26 Nov 2011 12:57:29 -0000 Received: from p5DCCBE90.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.190.144] by mail.gmx.net (mp026) with SMTP; 26 Nov 2011 13:57:29 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+qxDZPLPaqvGaKylm66Ux3zbUMVMQ5kqH8krzCoi I5xROe0nB85izU Message-ID: <4ED0E230.3010507@gmx.de> Date: Sat, 26 Nov 2011 13:57:20 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Adam Barth References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: =?ISO-8859-1?Q?Philip_J=E4genstedt?= , "websec@ietf.org" Subject: Re: [websec] mimesniff feedback, part 2 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 12:57:39 -0000 On 2011-11-26 05:26, Adam Barth wrote: > Yes. Bid-endian is correct. The IETF draft you're reading expired on > November 8. > > Adam > ... Well, it's the last that was published. Are you saying people should stop reading it? Best regards, Julian From stpeter@stpeter.im Sat Nov 26 10:28:47 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D34721F8B65; Sat, 26 Nov 2011 10:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSK0QQISSuDK; Sat, 26 Nov 2011 10:28:46 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A631C21F8A56; Sat, 26 Nov 2011 10:28:46 -0800 (PST) Received: from squire.local (unknown [216.17.140.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4A4F9421BB; Sat, 26 Nov 2011 11:35:27 -0700 (MST) Message-ID: <4ED12FD8.9080003@stpeter.im> Date: Sat, 26 Nov 2011 11:28:40 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , IETF Security Area Advisory Group , jose@ietf.org, IETF WebSec WG X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [websec] W3C Web Cryptography Working Group Charter X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 18:28:47 -0000 Of interest to apps and security folks at the IETF... http://www.w3.org/2011/11/webcryptography-charter.html Provide comments on the public-identity@w3.org list (subscribe by emailing public-identity-request@w3.org with subject "subscribe"). Peter -- Peter Saint-Andre https://stpeter.im/ From derhoermi@gmx.net Sat Nov 26 11:00:57 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3114D21F8BC3 for ; Sat, 26 Nov 2011 11:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 BhB47lNKK+q6 for ; Sat, 26 Nov 2011 11:00:55 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8BD4321F8BBF for ; Sat, 26 Nov 2011 11:00:54 -0800 (PST) Received: (qmail invoked by alias); 26 Nov 2011 19:00:52 -0000 Received: from dslb-094-223-192-167.pools.arcor-ip.net (EHLO HIVE) [94.223.192.167] by mail.gmx.net (mp051) with SMTP; 26 Nov 2011 20:00:52 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19xFdEUk8FxEdaIsJ1LvqRcRsetv6EtN3ii5vpZB2 X8ws5FzaaQeGdA From: Bjoern Hoehrmann To: Peter Saint-Andre Date: Sat, 26 Nov 2011 20:00:55 +0100 Message-ID: References: <4ED12FD8.9080003@stpeter.im> In-Reply-To: <4ED12FD8.9080003@stpeter.im> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG , "apps-discuss@ietf.org" Subject: Re: [websec] [apps-discuss] W3C Web Cryptography Working Group Charter X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 19:00:57 -0000 * Peter Saint-Andre wrote: >Of interest to apps and security folks at the IETF... > >http://www.w3.org/2011/11/webcryptography-charter.html Test suite is optional, I note in passing. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ietf@adambarth.com Sat Nov 26 12:23:51 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4952F21F8C0E for ; Sat, 26 Nov 2011 12:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=0.325, 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 DSq+R2m0e32m for ; Sat, 26 Nov 2011 12:23:50 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98D4B21F8C08 for ; Sat, 26 Nov 2011 12:23:50 -0800 (PST) Received: by iaeo4 with SMTP id o4so7694696iae.31 for ; Sat, 26 Nov 2011 12:23:49 -0800 (PST) Received: by 10.50.196.137 with SMTP id im9mr2508819igc.32.1322339029239; Sat, 26 Nov 2011 12:23:49 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id wo4sm68319538igc.5.2011.11.26.12.23.47 (version=SSLv3 cipher=OTHER); Sat, 26 Nov 2011 12:23:48 -0800 (PST) Received: by iaeo4 with SMTP id o4so7694666iae.31 for ; Sat, 26 Nov 2011 12:23:47 -0800 (PST) Received: by 10.42.155.133 with SMTP id u5mr19095173icw.8.1322339027502; Sat, 26 Nov 2011 12:23:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.67.130 with HTTP; Sat, 26 Nov 2011 12:23:15 -0800 (PST) In-Reply-To: <4ED0E230.3010507@gmx.de> References: <4ED0E230.3010507@gmx.de> From: Adam Barth Date: Sat, 26 Nov 2011 12:23:15 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Philip_J=E4genstedt?= , "websec@ietf.org" Subject: Re: [websec] mimesniff feedback, part 2 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 20:23:51 -0000 On Sat, Nov 26, 2011 at 4:57 AM, Julian Reschke wro= te: > On 2011-11-26 05:26, Adam Barth wrote: >> Yes. =A0Bid-endian is correct. =A0The IETF draft you're reading expired = on >> November 8. > > Well, it's the last that was published. Are you saying people should stop > reading it? I believe standard IETF practice is to stop reading drafts that have expire= d. Depending on how the working group resolves some of the issues it is considering, the draft will need to be substantially re-written. For example, if we decide to use an IANA registry (as seems likely) all of the text that Philip commented on will be removed from the document. Adam From masinter@adobe.com Sun Nov 27 09:25:06 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB1721F8C3E for ; Sun, 27 Nov 2011 09:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, 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 dulMtwFpx54G for ; Sun, 27 Nov 2011 09:25:06 -0800 (PST) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id B1E9021F8C2B for ; Sun, 27 Nov 2011 09:25:05 -0800 (PST) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKTtJyY3Vq21xWRYLDrGHsS4q0GGCF70ay@postini.com; Sun, 27 Nov 2011 09:25:05 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pARHN58G002390; Sun, 27 Nov 2011 09:23:06 -0800 (PST) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id pARHOlRH009999; Sun, 27 Nov 2011 09:24:47 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Sun, 27 Nov 2011 09:24:46 -0800 From: Larry Masinter To: Adam Barth , "julian.reschke@gmx.de" Date: Sun, 27 Nov 2011 09:24:44 -0800 Thread-Topic: [websec] mimesniff feedback, part 2 Thread-Index: AcyseVNSdUE0zAS/Q5u/7GcPn7bkGQAr8Ulg Message-ID: References: <4ED0E230.3010507@gmx.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Philip_J=E4genstedt?= , "websec@ietf.org" Subject: Re: [websec] mimesniff feedback, part 2 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 17:25:06 -0000 > Depending on how the working group resolves some of the issues it is cons= idering, the draft will need to be substantially re-written. For example, = if we=20 > decide to use an IANA registry (as seems likely) all of the text that Phi= lip commented on will be removed from the document. I think the body of the text might say "Use the values in the IANA registry= ", but that the "IANA considerations" section would contain all of the inst= ructions for how to set up the registry. That is, the document would stay the authoritative source for the _initial_= contents of the registry, but updates and additions could be managed thro= ugh whatever registration process we decided on, without having to update t= he document or algorithm itself. Larry From masinter@adobe.com Sun Nov 27 09:42:44 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E23621F8C51 for ; Sun, 27 Nov 2011 09:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.235 X-Spam-Level: X-Spam-Status: No, score=-106.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, 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 WXY-IloEFCKQ for ; Sun, 27 Nov 2011 09:42:43 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 938BA21F8C50 for ; Sun, 27 Nov 2011 09:42:41 -0800 (PST) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKTtJ2kYkPtIMkZ7CLwK87DynFJXmNdsFv@postini.com; Sun, 27 Nov 2011 09:42:43 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pARHet8G002785; Sun, 27 Nov 2011 09:40:56 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id pARHgcRH011297; Sun, 27 Nov 2011 09:42:38 -0800 (PST) Received: from SJ1SWM219.corp.adobe.com (10.5.77.61) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.3.192.1; Sun, 27 Nov 2011 09:42:37 -0800 Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by SJ1SWM219.corp.adobe.com ([fe80::d55c:7209:7a34:fcf7%12]) with mapi; Sun, 27 Nov 2011 09:42:37 -0800 From: Larry Masinter To: Tobias Gondrom , "websec@ietf.org" Date: Sun, 27 Nov 2011 09:42:36 -0800 Thread-Topic: [websec] Define cross-origin Thread-Index: Acyp4wz0rY8MFG4wScGJusPWMgjdWgDRsj5Q Message-ID: References: <4ECCF01D.5060403@gmx.de> <4ECCF376.8030503@gondrom.org> In-Reply-To: <4ECCF376.8030503@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] Define cross-origin X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 17:42:44 -0000 In my experience, it's possible make editorial changes without significant = hiccup as long as it is clear there is no objection -- and adding a non-con= troversial term definition would seem to be editorial. However, I'm really baffled by "Two URIs are the same-origin if their origi= ns are the same." NOTE: A URI is not necessarily same-origin with itself. For example, a data URI [RFC2397] is not same-origin with itself because data URIs do not use a server-based naming authority and therefore have globally unique identifiers as origins. If "origin" is an attribute of a "URI", then a.origin =3D a.origin. If a U= RI "has" an origin, how can that origin be subject to change, mathematicall= y. I suppose this is a result of using a normative algorithm in 4 instead of a= set of invariants.=20 Perhaps section 5 should instead say: Two URIs are "same origin" if computing their origins result in the same va= lue, and "cross-origin" if the results are different. Note that in this formulation, a URI is not necessarily same-origin with it= self; for example, a data URI [RFC2397] is not same-origin with itself beca= use data URIs do not use a server-based naming authority, and different inv= ocations of the "origin" computation will result in different (globally uni= que) origins. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Larry From ietf@adambarth.com Sun Nov 27 11:18:05 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917B821F8B2B for ; Sun, 27 Nov 2011 11:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.134 X-Spam-Level: X-Spam-Status: No, score=-1.134 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QtGcVB0G5+G for ; Sun, 27 Nov 2011 11:18:05 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5FE221F8B18 for ; Sun, 27 Nov 2011 11:17:59 -0800 (PST) Received: by iaeo4 with SMTP id o4so9277724iae.31 for ; Sun, 27 Nov 2011 11:17:59 -0800 (PST) Received: by 10.50.85.129 with SMTP id h1mr47271022igz.47.1322421479151; Sun, 27 Nov 2011 11:17:59 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id bu33sm35256916ibb.11.2011.11.27.11.17.57 (version=SSLv3 cipher=OTHER); Sun, 27 Nov 2011 11:17:57 -0800 (PST) Received: by iaeo4 with SMTP id o4so9277675iae.31 for ; Sun, 27 Nov 2011 11:17:57 -0800 (PST) Received: by 10.50.169.38 with SMTP id ab6mr47563780igc.26.1322421477082; Sun, 27 Nov 2011 11:17:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.67.130 with HTTP; Sun, 27 Nov 2011 11:17:27 -0800 (PST) In-Reply-To: References: <4ECCF01D.5060403@gmx.de> <4ECCF376.8030503@gondrom.org> From: Adam Barth Date: Sun, 27 Nov 2011 11:17:27 -0800 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Define cross-origin X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 19:18:05 -0000 On Sun, Nov 27, 2011 at 9:42 AM, Larry Masinter wrote: > In my experience, it's possible make editorial changes without significan= t hiccup as long as it is clear there is no objection -- and adding a non-c= ontroversial term definition would seem to be editorial. > > However, I'm really baffled by "Two URIs are the same-origin if their ori= gins are the same." > > =A0 =A0 =A0NOTE: A URI is not necessarily same-origin with itself. =A0For > =A0 =A0 =A0example, a data URI [RFC2397] is not same-origin with itself > =A0 =A0 =A0because data URIs do not use a server-based naming authority a= nd > =A0 =A0 =A0therefore have globally unique identifiers as origins. > > If "origin" is an attribute of a "URI", then a.origin =3D a.origin. Origin is not an attribute of a URI. It's a value you can compute from a U= RI. > If a URI "has" an origin, how can that origin be subject to change, mathe= matically. > I suppose this is a result of using a normative algorithm in 4 instead of= a set of invariants. It's a result of how the web works. However we define origin, it needs to be the case that a URI is not necessarily same-origin with itself. > Perhaps section 5 should instead say: > > Two URIs are "same origin" if computing their origins result in the same = value, and "cross-origin" if the results are different. > Note that in this formulation, a URI is not necessarily same-origin with = itself; for example, a data URI [RFC2397] is not same-origin with itself be= cause data URIs do not use a server-based naming authority, and different i= nvocations of the "origin" computation will result in different (globally u= nique) origins. That's fine, but I would remove the phrase about "formulation". It does't have anything to do with this particular formulation of this concept. It's a consequence of the concept itself. Adam From masinter@adobe.com Sun Nov 27 12:18:39 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0B021F8C4A; Sun, 27 Nov 2011 12:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.798 X-Spam-Level: X-Spam-Status: No, score=-104.798 tagged_above=-999 required=5 tests=[AWL=-1.254, BAYES_00=-2.599, FRT_ADOBE2=2.455, J_CHICKENPOX_16=0.6, 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 jIzL-FSNCpTz; Sun, 27 Nov 2011 12:18:38 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id EEA0421F8C46; Sun, 27 Nov 2011 12:18:37 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKTtKbGtTLLptc4WRrnnRLq71w5mTcN6aC@postini.com; Sun, 27 Nov 2011 12:18:38 PST Received: from inner-relay-1.corp.adobe.com (ms-exchange.macromedia.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pARKIXZc028883; Sun, 27 Nov 2011 12:18:33 -0800 (PST) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pARKIVL7024670; Sun, 27 Nov 2011 12:18:31 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Sun, 27 Nov 2011 12:18:31 -0800 From: Larry Masinter To: Adam Barth Date: Sun, 27 Nov 2011 12:18:30 -0800 Thread-Topic: [websec] Define cross-origin Thread-Index: AcytOUjV+WUCJ8HkQ+K8aEJJmGQDSQAB3isQ Message-ID: References: <4ECCF01D.5060403@gmx.de> <4ECCF376.8030503@gondrom.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "websec@ietf.org" , "iesg@ietf.org" Subject: Re: [websec] Define cross-origin X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 20:18:39 -0000 Re http://tools.ietf.org/html/draft-ietf-websec-origin#section-5 So when you say that a URI "has" an origin, that isn't quite true, right? S= ome URIs have infinitely many origins, and you get a new one whenever you a= sk for one. To know when you have to ask for a new one and not reuse the on= e you got to use before, you have to ... what? Is there some mysterious oth= er attribute or state that goes along with the URI that you use to decide w= hether the second instance of the "same" URI is different enough to want to= get a new origin? -----Original Message----- From: Adam Barth [mailto:ietf@adambarth.com]=20 Sent: Sunday, November 27, 2011 11:17 AM To: Larry Masinter Cc: Tobias Gondrom; websec@ietf.org Subject: Re: [websec] Define cross-origin On Sun, Nov 27, 2011 at 9:42 AM, Larry Masinter wrote: > In my experience, it's possible make editorial changes without significan= t hiccup as long as it is clear there is no objection -- and adding a non-c= ontroversial term definition would seem to be editorial. > > However, I'm really baffled by "Two URIs are the same-origin if their ori= gins are the same." > > =A0 =A0 =A0NOTE: A URI is not necessarily same-origin with itself. =A0For > =A0 =A0 =A0example, a data URI [RFC2397] is not same-origin with itself > =A0 =A0 =A0because data URIs do not use a server-based naming authority a= nd > =A0 =A0 =A0therefore have globally unique identifiers as origins. > > If "origin" is an attribute of a "URI", then a.origin =3D a.origin. Origin is not an attribute of a URI. It's a value you can compute from a U= RI. > If a URI "has" an origin, how can that origin be subject to change, mathe= matically. > I suppose this is a result of using a normative algorithm in 4 instead of= a set of invariants. It's a result of how the web works. However we define origin, it needs to = be the case that a URI is not necessarily same-origin with itself. > Perhaps section 5 should instead say: > > Two URIs are "same origin" if computing their origins result in the same = value, and "cross-origin" if the results are different. > Note that in this formulation, a URI is not necessarily same-origin with = itself; for example, a data URI [RFC2397] is not same-origin with itself be= cause data URIs do not use a server-based naming authority, and different i= nvocations of the "origin" computation will result in different (globally u= nique) origins. That's fine, but I would remove the phrase about "formulation". It does't = have anything to do with this particular formulation of this concept. It's= a consequence of the concept itself. Adam From ietf@adambarth.com Sun Nov 27 12:41:51 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40B621F8B77; Sun, 27 Nov 2011 12:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCOnnp2PKbd0; Sun, 27 Nov 2011 12:41:51 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25D7421F8B76; Sun, 27 Nov 2011 12:41:51 -0800 (PST) Received: by iaeo4 with SMTP id o4so9379527iae.31 for ; Sun, 27 Nov 2011 12:41:50 -0800 (PST) Received: by 10.42.244.137 with SMTP id lq9mr21436713icb.28.1322426510796; Sun, 27 Nov 2011 12:41:50 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id bu33sm36130970ibb.11.2011.11.27.12.41.49 (version=SSLv3 cipher=OTHER); Sun, 27 Nov 2011 12:41:50 -0800 (PST) Received: by iaeo4 with SMTP id o4so9379494iae.31 for ; Sun, 27 Nov 2011 12:41:49 -0800 (PST) Received: by 10.50.169.38 with SMTP id ab6mr47778323igc.26.1322426509476; Sun, 27 Nov 2011 12:41:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.67.130 with HTTP; Sun, 27 Nov 2011 12:41:18 -0800 (PST) In-Reply-To: References: <4ECCF01D.5060403@gmx.de> <4ECCF376.8030503@gondrom.org> From: Adam Barth Date: Sun, 27 Nov 2011 12:41:18 -0800 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" , "iesg@ietf.org" Subject: Re: [websec] Define cross-origin X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 20:41:51 -0000 That's up to specifications that use this document. For example, HTML5 is clear about when it computes the origin from a URI. Adam On Sun, Nov 27, 2011 at 12:18 PM, Larry Masinter wrote= : > Re http://tools.ietf.org/html/draft-ietf-websec-origin#section-5 > > So when you say that a URI "has" an origin, that isn't quite true, right?= Some URIs have infinitely many origins, and you get a new one whenever you= ask for one. To know when you have to ask for a new one and not reuse the = one you got to use before, you have to ... what? Is there some mysterious o= ther attribute or state that goes along with the URI that you use to decide= whether the second instance of the "same" URI is different enough to want = to get a new origin? > > > -----Original Message----- > From: Adam Barth [mailto:ietf@adambarth.com] > Sent: Sunday, November 27, 2011 11:17 AM > To: Larry Masinter > Cc: Tobias Gondrom; websec@ietf.org > Subject: Re: [websec] Define cross-origin > > On Sun, Nov 27, 2011 at 9:42 AM, Larry Masinter wrot= e: >> In my experience, it's possible make editorial changes without significa= nt hiccup as long as it is clear there is no objection -- and adding a non-= controversial term definition would seem to be editorial. >> >> However, I'm really baffled by "Two URIs are the same-origin if their or= igins are the same." >> >> =A0 =A0 =A0NOTE: A URI is not necessarily same-origin with itself. =A0Fo= r >> =A0 =A0 =A0example, a data URI [RFC2397] is not same-origin with itself >> =A0 =A0 =A0because data URIs do not use a server-based naming authority = and >> =A0 =A0 =A0therefore have globally unique identifiers as origins. >> >> If "origin" is an attribute of a "URI", then a.origin =3D a.origin. > > Origin is not an attribute of a URI. =A0It's a value you can compute from= a URI. > >> If a URI "has" an origin, how can that origin be subject to change, math= ematically. >> I suppose this is a result of using a normative algorithm in 4 instead o= f a set of invariants. > > It's a result of how the web works. =A0However we define origin, it needs= to be the case that a URI is not necessarily same-origin with itself. > >> Perhaps section 5 should instead say: >> >> Two URIs are "same origin" if computing their origins result in the same= value, and "cross-origin" if the results are different. >> Note that in this formulation, a URI is not necessarily same-origin with= itself; for example, a data URI [RFC2397] is not same-origin with itself b= ecause data URIs do not use a server-based naming authority, and different = invocations of the "origin" computation will result in different (globally = unique) origins. > > That's fine, but I would remove the phrase about "formulation". =A0It doe= s't have anything to do with this particular formulation of this concept. = =A0It's a consequence of the concept itself. > > Adam > From stpeter@stpeter.im Tue Nov 29 09:14:50 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE991F0C73 for ; Tue, 29 Nov 2011 09:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEZQ7RQHbrCm for ; Tue, 29 Nov 2011 09:14:49 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C5F471F0C72 for ; Tue, 29 Nov 2011 09:14:46 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 567E9421BB; Tue, 29 Nov 2011 10:21:40 -0700 (MST) Message-ID: <4ED51305.5050702@stpeter.im> Date: Tue, 29 Nov 2011 10:14:45 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Larry Masinter References: <4ED0E230.3010507@gmx.de> In-Reply-To: X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?UGhpbGlwIErDpGdlbnN0ZWR0?= , "websec@ietf.org" Subject: Re: [websec] mimesniff feedback, part 2 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 17:14:50 -0000 On 11/27/11 10:24 AM, Larry Masinter wrote: >> Depending on how the working group resolves some of the issues it is considering, the draft will need to be substantially re-written. For example, if we >> decide to use an IANA registry (as seems likely) all of the text that Philip commented on will be removed from the document. > > I think the body of the text might say "Use the values in the IANA registry", but that the "IANA considerations" section would contain all of the instructions for how to set up the registry. > > That is, the document would stay the authoritative source for the _initial_ contents of the registry, but updates and additions could be managed through whatever registration process we decided on, without having to update the document or algorithm itself. Makes sense to me (as an individual). Peter -- Peter Saint-Andre https://stpeter.im/ From internet-drafts@ietf.org Tue Nov 29 17:48:47 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C17C11E80A2; Tue, 29 Nov 2011 17:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pM82DMi84IcA; Tue, 29 Nov 2011 17:48:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E7011E80A1; Tue, 29 Nov 2011 17:48:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111130014847.24863.97838.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2011 17:48:47 -0800 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-00.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 01:48:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IET= F. Title : Public Key Pinning Extension for HTTP Author(s) : Chris Evans Chris Palmer Filename : draft-ietf-websec-key-pinning-00.txt Pages : 7 Date : 2011-11-29 This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one or more of the pinned fingerprints for that host. By effectively reducing the scope of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities and other authentication errors and attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-key-pinning-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-websec-key-pinning-00.txt From James.H.Manger@team.telstra.com Tue Nov 29 19:44:58 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720831F0C43 for ; Tue, 29 Nov 2011 19:44:58 -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 N9HzjpZYfXsZ for ; Tue, 29 Nov 2011 19:44:56 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 03FD11F0C40 for ; Tue, 29 Nov 2011 19:44:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.69,595,1315144800"; d="scan'208,217";a="53591437" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 30 Nov 2011 14:44:41 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6545"; a="44533749" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcani.tcif.telstra.com.au with ESMTP; 30 Nov 2011 14:44:41 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Wed, 30 Nov 2011 14:44:41 +1100 From: "Manger, James H" To: "websec@ietf.org" Date: Wed, 30 Nov 2011 14:44:40 +1100 Thread-Topic: Comments on draft-ietf-websec-key-pinning-00 Thread-Index: AcyvEmPeWuMQv+bwRUeQ1MgFT+I/9A== Message-ID: <255B9BB34FB7D647A506DC292726F6E1138A2F4206@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1138A2F4206WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [websec] Comments on draft-ietf-websec-key-pinning-00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 03:44:58 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1138A2F4206WSMSG3153Vsrv_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-websec-key-pinning-00: First, nice work. =A72.3 "Noting Pins" 2nd-last paragraph: If the Public-Key-Pins response header field does not meet all three of these criteria [error-free TLS; current key; backup pin], the UA MUST= NOT note the host as a Pinned Host, and MUST discard any previously set Pinning Metadata for that host in its non-volatile store. This seems to make it too easy for an attacker to force a UA to discard pre= viously set pins for a host, removing the protection they offered. If an at= tacker inserts a Public-Key-Pins HTTP response header into an HTTP (not HTT= PS) response from the server it will fail the 1st criteria (over an error-f= ree TLS connection). Is that all it takes to turn off pinning for that host= ? =A72.4 "Validating Pinned Connections": if the TLS connection has errors... the UA might... allow the user the o= ption of continuing with the connection anyway If the connection has no errors, the UA will then apply a new correctness check: Pin Validation. Does this mean pin validation is bypassed if the cert was, say, expired and= the user said continue anyway? It doesn't look right if the UA MUST fail with a non-recoverable error if p= in validation fails, but an attacker can cause an earlier failure (eg expir= ed cert) and users will be allowed to click-through that warning and get to= the site. Or the user can click-through a recoverable cert error; pin vali= dation is then bypassed; then a Public-Key-Pins header fails the error-free= TLS connection criteria so the UA removes all pinning for this site. Might be worth explicitly mentioning that only certificates that are actual= ly used in the validated certificate chain should be used in Pin Validation= , which is not necessarily all the certificates in a TLS Certificate messag= e (even if the two are supposed to be the same). =A72.4 "Validating Pinned Connections": For hosts that are Known HSTS Hosts the UA MUST terminate the connection in case of TLS errors, as required by [hsts-draft]. It is ok to refer to HSTS but this spec shouldn't repeat a "MUST" from HSTS= . =A72.1 "Response Header Field Syntax": The ABNF and the examples don't matc= h at all. ABNF suggests Public-Key-Pins: pin-sha1=3D"4n972HfV354KP560yw4uqe/baXc=3D"; ... But example is Public-Key-Pins: pins=3Dsha1-4n972HfV354KP560yw4uqe/baXc=3D, ... Typo: =A72.4 "Validating Pinned Connections": "might or might now" should b= e "might or might not" -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E1138A2F4206WSMSG3153Vsrv_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Comments on draf= t-ietf-websec-key-pinning-00:

 = ;

First, nice work.

 

=A72.3 “Noting Pi= ns” 2nd-last paragraph:

=A0=A0If the Public-Key-Pins response header field does not meet all thre= e

=A0=A0 of these criteria [error-free T= LS; current key; backup pin], the UA MUST NOT note the host as a Pinned Hos= t,

=A0=A0 and MUST discard any previousl= y set Pinning Metadata for that host in

= =A0=A0 its non-volatile store.

&nbs= p;

This seems to make it too easy for an atta= cker to force a UA to discard previously set pins for a host, removing the = protection they offered. If an attacker inserts a Public-Key-Pins HTTP resp= onse header into an HTTP (not HTTPS) response from the server it will fail = the 1st criteria (over an error-free TLS connection). Is that al= l it takes to turn off pinning for that host?

 

=A72.4 “Validating Pi= nned Connections”:

=A0=A0 if the T= LS connection has errors… the UA might… allow the user the opti= on

=A0=A0 of continuing with the connect= ion anyway

=A0=A0 If the connection has = no errors, the UA will then apply a new

= =A0=A0 correctness check: Pin Validation.

 

Does this mean pin validation i= s bypassed if the cert was, say, expired and the user said continue anyway?=

It doesn’t look right if the UA M= UST fail with a non-recoverable error if pin validation fails, but an attac= ker can cause an earlier failure (eg expired cert) and users will be allowe= d to click-through that warning and get to the site. Or the user can click-= through a recoverable cert error; pin validation is then bypassed; then a P= ublic-Key-Pins header fails the error-free TLS connection criteria so the U= A removes all pinning for this site.

 

 

 

Might be worth explicitly m= entioning that only certificates that are actually used in the validated ce= rtificate chain should be used in Pin Validation, which is not necessarily = all the certificates in a TLS Certificate message (even if the two are supp= osed to be the same).

=A72.4 “Validating Pinned Connections”:=

=A0 For hosts that are Known HSTS Hosts the = UA MUST terminate

=A0the connection in = case of TLS errors, as required by [hsts-draft].

It is ok to refer to HSTS but this spec shouldn’t repeat a &= #8220;MUST” from HSTS.

 =

=A72.1 “Response Header Field Syntax&#= 8221;: The ABNF and the examples don’t match at all.

ABNF suggests

=A0Pub= lic-Key-Pins: pin-sha1=3D"4n972HfV354KP560yw4uqe/baXc=3D"; …= ;

But example is

=A0Public-Key-Pins: pins=3Dsha1-4n972HfV354KP560yw4uqe/baXc= =3D, …

 

Typo: =A72.4 “Validating Pinned Connections”: &#= 8220;might or might now” should be “might or might not”

 

--

James Manger

 

= --_000_255B9BB34FB7D647A506DC292726F6E1138A2F4206WSMSG3153Vsrv_--