From nobody Tue Nov 1 03:11:21 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B99129450 for ; Tue, 1 Nov 2016 03:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpV_VPXLqTmT for ; Tue, 1 Nov 2016 03:11:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891C512940C for ; Tue, 1 Nov 2016 03:11:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 82B5FBE5D; Tue, 1 Nov 2016 10:11:14 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7r5ZE7oFND7; Tue, 1 Nov 2016 10:11:14 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E75C9BE5C; Tue, 1 Nov 2016 10:11:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1477995074; bh=8Ln6QqDvRhN9WFZdV8nx7qEIRitKSEYT5r0Y4FJ8amA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=IP0UsYM/DuAxkR6S8mRYMjzEEiKpX2LcV/uYeDBXZJEhAa5cwn15j9bSr+db6eroY U56o5RSNWWCkeQy72qhPETur6YRe6k7TN6CXBeHXq+8gPTiv+oYxn9spD/5vYG0I2x flGV+5eL6Ly2epg4J3Jv+M96xL0JkRaK17Jd1IaM= To: Peter Bowen References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <6f6f01c9-e462-12ca-12bb-b1dc5fac67ce@cs.tcd.ie> Date: Tue, 1 Nov 2016 10:11:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010306080209000508000007" Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 10:11:20 -0000 This is a cryptographically signed message in MIME format. --------------ms010306080209000508000007 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/11/16 03:34, Peter Bowen wrote: > On Mon, Oct 31, 2016 at 6:33 PM, Stephen Farrell > wrote: >> On 01/11/16 01:04, Peter Bowen wrote: >>> On Mon, Oct 31, 2016 at 3:02 PM, Stephen Farrell wrote: >>>> >>>> Can you call out the privacy aspect that applies to humans >>>> and that is a real part of the question related to support for >>>> redaction in CT? >>> >>> There are >> >> "Are" or "could be"? >> >> Serious question. The (non)existence of those in 6962 logs >> seems to me to be a) highly pertinent and b) demonstrable. >=20 > I'm not sure how you get that these don't exist. Using the given name > and surname attribute types as indications of PII, and removing one > issuer's apparently confusion between surname and serial number, I see > thousands. A few examples: >=20 > https://crt.sh/?id=3D9031476 > https://crt.sh/?id=3D8997821 > https://crt.sh/?id=3D45107003 > https://crt.sh/?id=3D31130948 Thanks. I'd be interested if there's a way to count how many logged certs have givenName, surname or similar attributes. Anyone with better log-foo know? >=20 >>> certificates that have personal information (e.g. given >>> name, surname, and physical location) in the subject distinguished >>> name or the subject alternative names. >> >> I can well imagine certs for web servers with some PII >> embedded for no good reason. "Don't do that by accident" >> would be as good a bit of advice as we could offer in >> CT I think as it's really much more an issue for acme >> in terms of current IETF work. (Or at least arguably.) >=20 > I wouldn't call this by accident. Microsoft's root program > requirements (http://social.technet.microsoft.com/wiki/contents/article= s/31633.microsoft-trusted-root-program-requirements.aspx) > explicitly call out Individual Validation (IV) is section 4(a)(15). > IV, by definition, puts Personal Information in the subject of the > certificate. Again, do we have a count of how many of those (IV certs) are logged? >=20 >>> It is very possible that there >>> may be a desire to redact this information (in fact it could even be >>> required in some jurisdictions as CT could be considered a database).= >> >> The above has "possible," "may be a desire," "could even >> be" and "could be considered" all in one sentence. That >> is not a template for a winning argument is it? :-) >=20 > I'm not a lawyer, so I'm not going to make any legal conclusions. =20 I wasn't making a legal point:-) > So > I'm going to continue to qualify anything related to legislation that > may exist in certain jurisdictions in which CT logs may exist. Yes, > that is heavily caveated again, so feel free to ignore, but it is a > real concern. >=20 >>> We already see this with domains in many countries where the full >>> registrant details are not publicly available. >> >> DNS registration policies are not in scope here though. >=20 > I wasn't suggesting that they were. I was using it to demonstrate a > related case where it was judged that restriction of information was > beneficial. >=20 >>> >>> Additionally, while 6962-bis does focus on certificates used for TLS >>> server authentication, there are other types of certificates that >>> could be logged. >> >> How many have been logged? Serious question. If there is a >> real problem here, I'm interested. If there is not, then I, >> for one, am not. Finding the evidence either way should not >> be hard. >=20 > Why does it matter how many have currently been logged? Isn't the > point of this WG to create tech spec for a certificate log that can > log any kind of certificate? Is it possible emailProtection certs > aren't being logged because of privacy concerns? It is entirely possible. Or it could be that those aren't being logged for other reasons. My main point is that it would be an error to conflate (a) requirements for privacy with (b) requirements for corporate secrecy. Those need to be discussed separately as the issues are quite different. And while it is perhaps possible that one technical approach might exist to address both sets of issues, that would surprise me, given that the requirements for (a) and (b) differ so much. S. >=20 > Thanks, > Peter >=20 --------------ms010306080209000508000007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDEx MDExMTRaMC8GCSqGSIb3DQEJBDEiBCBwHIZ1PIylHNcoYuW2BYleIE4/idIstwTN7WTJLAa+ TTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB6joGofZ4mU03Q7k/C2W4PnjghS74iykOjw+snqehNjni2KOfzT4zZ xb7+yZL6iM0ne3mlSLhf8AptbRhlZcLRUoh6GYLJGAjib2WMaZeS9WykbKa9FRZwNVr1EXYo a1xYnhJ7ZroCygNN+oPnj8TDH0lGxgOklmOsOyzxNQSeuQclpJzmAxYcASDPpFwLlCUW7JUH 66qGw/R8ujYDykQH4D8NErpS+10YwAqtAv5q7mv3xBBfJHBX+N2fqxG7/31WKBn5UYKOnL3k YwgdqnIHKq0a/1nZCGupCA9lGLdy1UASCVuUs8uRz8qBrp48iF791R3NVVeJKpXXMI0xyrAF AAAAAAAA --------------ms010306080209000508000007-- From nobody Tue Nov 1 03:21:49 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BAD129470 for ; Tue, 1 Nov 2016 03:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHDTLRgGbHjx for ; Tue, 1 Nov 2016 03:21:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C6812946D for ; Tue, 1 Nov 2016 03:21:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 13D3FBE5C; Tue, 1 Nov 2016 10:21:44 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7LR2IAGJoBE; Tue, 1 Nov 2016 10:21:43 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 75DA8BE58; Tue, 1 Nov 2016 10:21:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1477995703; bh=0mBx3C+AugeWXS6F59MYi5fobRppmNVuIMis0u6uFgE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=eeoiHqg5+W0o0cWRBFpkVtBxhl0ckfs7/XvXhlHEPzT7HMwhjHHhNLbNr1LL/pqmX diB++aaIU8UE1BtX7myOyv7MDiPKhQIG4K/KncmBx6k1AD65rOU1EYHkFME7WHAhrq Ids8LpDNSuRrpWS6yEOtR54ObX1YIT5mmL0l79m4= To: Ryan Sleevi References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> <5ae04a85-f39a-c2f8-d206-7d6d70370fee@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 1 Nov 2016 10:21:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040704080009090902010303" Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 10:21:48 -0000 This is a cryptographically signed message in MIME format. --------------ms040704080009090902010303 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/11/16 03:38, Ryan Sleevi wrote: > On Mon, Oct 31, 2016 at 7:45 PM, Stephen Farrell > wrote: >> >> No, that's an empirical question, to rephrase it: Show me the >> certs:-) >> >> Really, it is a serious question when considering the difference >> between corporate secrecy and privacy. I totally accept that there >> are issues with the former (e.g. with .example.com) >> but I'd like to see evidence if someone claims that the latter >> is an issue. ("The latter" being the privacy of humans, not the >> secrecy of organisations.) >=20 > "Show me the certs with PII" is a somewhat problematic stance, isn't > it?=20 I guess it might sound like it yeah:-) But see my mail to Peter, a count of those with likely-sensitive attributes would be a good start. > To what end will it help you or the community evaluate?=20 It'd help evaluate the seriousness of the potential privacy issue with current logging. My sense going in was that this (inclusion of PII in certs in logs) wasn't too big a deal, but I could well be wrong. > I'm not > sure I accept at all your line of questioning, so perhaps, before > needlessly dropping PII, you can suggest how that would change your > response, if at all. I am quite interested in discussing privacy issues if they exist here. (I don't however accept that corporate secrecy is a privacy issue.) >=20 >>> - and what clients are logging? These >>> certs definitely exist - but the combination of client behavior and l= og >>> policies have, so far, prevented them from being logged, and only >>> incidentally so. >> >> I don't follow that, can you elaborate? >=20 > The extant logs all generally have policies that restrict the roots > from which they log, or even more narrowly, restrict the purposes for > certs which they log. >=20 > Similarly, the majority of log clients - those submitting to logs - > restrict what they log to a subset of what they see. Similarly, these > log clients only see particular types of certs, rather than the > broader corpus out there. >=20 > For concrete example: It's certainly be technically possible that > Google could decide to log every S/MIME certificate it saw. But would > it be wise? Of course not. Agreed. >=20 >> The WG charter calls out web site cert misissuance as thing#1 >> and http/tls as the same (in the deliverable bit). >> >> Acme relates as follows: if there are certs containing PII, >> instead of trying to handle those via redaction during the >> act of CT logging, one could recommend not including the PII >> in the certs. (It is arguable that that is a sufficient >> answer, but nonetheless it could be argued to be one, in the >> context of the IETF.) >=20 > Of course, that doesn't address the issue pointed out earlier by Peter > - that certificates are in use for more than just TLS, and issued by > means more than ACME. >=20 > It sounds like your suggestion is only certs issued by ACME should be > logged via CT. Naturally, I reject that conclusion. No that was not my suggestion at all. > You're directly proposing policy solutions, right now ("Don't log"), > and rejecting even exploring or entertaining the technical discussion. > Is that intentional, or simply a misunderstanding? That's a wild misinterpretation of what I said. If you can point to where I "rejected even exploring" anything then I'd be very happy to retract that. >=20 >>> Are you suggesting that CT does not need to be aware of what is possi= ble, >>> either through other WGs actions (such as NSEC/NSEC3) or through othe= r >>> bodies, such as IANA/ICANN? >> >> I've no clue what the above means, sorry. >> >> Guessing though, as to what might constitute an answer: I do >> not think that CT needs to try to address problematic things >> like ICANN registrar policies that call for PII to be generally >> visible. To the extent one has a problem with that, (and I do >> as it happens) the trans WG is the wrong venue, was my point. >=20 > I'm suggesting that CT needs to at least be aware of other privacy > preserving efforts - such as NSEC3 or DPRIVE - and as such, cannot > unconditionally say "Don't do that", when other IETF technologies > support "do that" - at least, not without a reasonable discussion of > why.=20 I'm entirely fine with discussion of privacy as it relates to CT, and would be glad to see that. My main point is that privacy is entirely different from corporate secrecy, and conflating the two would be an error. > I don't believe you've posed why, other than you don't like it, > or don't feel the use case exists, but if that's the level of > discussion, then I fear we will make no progress, especially given > that even the original message contained such evidence. My hope was > that here in the IETF we could try to find solutions for problems, and > only punt them when we believe they are better served elsewhere - but > I feel like your line of reasoning is to try to punt anything you > don't like. Every time you tell me what you feel I think, you go wrong. Maybe concentrating on what I say will be more useful? >=20 >>> It so, can you articulate what you view as the appropriate scope of >>> function and discussion here? I mean that as an honest question. >> >> As with the above, I'm too confused to answer. (And figure >> there's some underlying miscommunication going on here.) >=20 > Are the only certificates CT cares about TLS server certificates? No. Those are the most important use-case for now though. I do also think we need to be careful to not try to e.g. re-design e2e secure interpersonal messaging based on CT. While getting better e2e secure interpersonal messaging would be a fine thing, there is much more to that than considering CT. So going beyond the well understood use-cases has a number of risks. >=20 > If not, then you already have ample evidence in the form of S/MIME > certificates, or in digital signature certificates, that privacy is an > aspect of the discussion. > If you don't agree with that, let's find out why. > If you do, then can we accept there's a privacy argument, and not just > a corporate secrecy requirement, and move on to the technological > discussion? To reiterate: I'm very happy if we discuss privacy so long as we do not conflate that with corporate secrecy. There are requirements for both, but they are far from the same. S. >=20 --------------ms040704080009090902010303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDEx MDIxNDNaMC8GCSqGSIb3DQEJBDEiBCCA+GprGpuLmbnb7EdPKpJDThAZqG0NH7g54TI3LVh1 8zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA3zuqXAGi/W96biBZiRFZ24kg+7myIq7fWaYqwnuFV5+gTU7aJWJHu 781CN37Gcz5wGRXKDsqJ1UtR47pVfvrU03SVl6LJTL6xKDmdXuub1oKvLsXHF+hwNk5qePj3 XRkD5IZr7HNppMDaL19PXQVbZSk6hQoIIXkbiE4AXQInKusiqq3enDE02aYUPwB6ZUbVceYq HnB9ZX31lzoYmpVZ7EDeCFaFeejVtoTqQtjfTETJqqheVv+hJsX7B896llZnMKGbQU063Ya7 3YlVTw5vmQj9VdHIBl7+QRlbHvTAITeCmnf1rtZy+c7ZpJVb3J6PvYWT+yZnbBAmKwCe/Vrn AAAAAAAA --------------ms040704080009090902010303-- From nobody Tue Nov 1 04:13:13 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770FA1295E3 for ; Tue, 1 Nov 2016 04:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vA3o_WEL1NCa for ; Tue, 1 Nov 2016 04:13:11 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C151012952C for ; Tue, 1 Nov 2016 04:13:10 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id v84so131405136oie.3 for ; Tue, 01 Nov 2016 04:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=G3/ceoqng21axJxllz68aABRR6sqX31EKZIbDQRV/Gs=; b=LoptEmfsoK/nJUqj+w+3HkfV/KaevIG98sMZsWCX6c3ate0aAWnurz/iVstQ46s/Qu 8RPRuhPjAOc9vfqd3OuhW9gaFyffyZwnKDFlfgX30/8vLX6fOB1GxpgO6Fjhl3GwQs6R K7EfsxA65leSdPbS0lWs9Rr9rzdmhvj37ZwP7uExZrNOtDk4Pv0ZZTZeGBXKg/26rOCH vdVcq7Wbx2VYKeY2W8S+Z9PDh3t4SgaDnzg6XEdo0ZCZPumCfHWc8qpIH2d2ubhP2pGt uMflSQA/kysCfoGdmZoLOVtFWuudNVohdKr1QPqJLCdbVesHYygIut1XM5ct0qrPy66f e4mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=G3/ceoqng21axJxllz68aABRR6sqX31EKZIbDQRV/Gs=; b=EgJkLNmdE3l1RbRNokRK8pR8M4ypEEQ37sC6HAX5tCSQh0NBCW67e9vshY6XiuM1gk YY+bpjjajlOatN59qLS5vNeeyRV7xfLfw3ecwWWXWGq4zYCqUeOws1UE9Hf5oxJs8y15 1ZR8CK8UXIjakqAtKiHNaccLBetU/eU3XzgnSe9V2IwcEf1rOCSll6pFxx8UtRSYfcro ok6FUJ4UU0t6tZ6vK1p87zHuL+46m9C3pxh4vJZUvtuYQJZTtc9OwZAnDMjsjusv193p vZ+wfCwPBI51nWJR4yUtm9ADjTt2vJfruczER5gVSnAlLfwvthU/3I4xGzfiP1v7qYOR 62UQ== X-Gm-Message-State: ABUngvelIePb6wPGEXY7Ix6xy62oQew+RMu8nq2G8ZW8gb1weM12cvPv4bElEP2z2Yc6W2GwuIj/R4563YVZaw== X-Received: by 10.107.184.214 with SMTP id i205mr7575615iof.167.1477998789925; Tue, 01 Nov 2016 04:13:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.39.68 with HTTP; Tue, 1 Nov 2016 04:13:09 -0700 (PDT) From: Peter Bowen Date: Tue, 1 Nov 2016 04:13:09 -0700 Message-ID: To: Melinda Shore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Topicality (Coporate Secrecy) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 11:13:12 -0000 On Mon, Oct 24, 2016 at 9:37 PM, Melinda Shore wrote: > You may have seen the recent announcement from the Chrome > team that as of October 2017 certificates will need to comply > with Chrome's CT policy in order to be trusted. There was > also an invitation to discuss that on the trans mailing list. > This is a reminder that mailing list discussions need to > remain focused on the specifications being produced by the > working group - that is to say, policies related to > individual implementations are out of scope for the working > group except to the extent that they bear on decisions related > to our working group drafts. Melinda and Paul, Since Stephen Farrell has pointed out that personal privacy and corporate secrecy are two distinct things, I'm creating a new thread branch to re-ask my earlier question, but about the latter. Do you consider discussion of use cases for corporate secrecy to be in-scope for this group or do you consider only the technical implementation of secrecy (e.g. section 4 of 6962-bis and the redaction draft) and/or personal privacy to be in-scope? Thanks, Peter From nobody Tue Nov 1 04:19:37 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F07129626 for ; Tue, 1 Nov 2016 04:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZmggVOpaxyl for ; Tue, 1 Nov 2016 04:19:34 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A15812962C for ; Tue, 1 Nov 2016 04:19:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3t7TJt6Qw8zvr; Tue, 1 Nov 2016 12:19:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1477999166; bh=G1trXtA2bPV1TacoSFzLM9L1EBDqD1ZonPlWE9ukXrI=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=tQ2tvM21bUSK5Rm60DDijhxufIz+QgSnPMXS3csAxRZ0cq9ipISTWpGuCyYKKj2jE KTGYnD5Jf0qhUqK0zVQatQLySw5gIq+sKYMs8LbOsN/ZA+4Zr5V+zq1fej2DTcpiKf KKH0xics/YMYt8VBafcGk1vK7eWj9EG0snT4sq7s= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id jwZkSe0aBWOI; Tue, 1 Nov 2016 12:19:01 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 1 Nov 2016 12:19:01 +0100 (CET) Received: from [223.179.193.113] (unknown [223.179.193.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 6227744717D; Tue, 1 Nov 2016 07:18:59 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 6227744717D References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (14A456) From: Paul Wouters Date: Tue, 1 Nov 2016 16:48:52 +0530 To: Peter Bowen Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 11:19:36 -0000 > On Nov 1, 2016, at 00:31, Peter Bowen wrote: >=20 >=20 > Paul and Melinda, >=20 > Do you consider discussion of use cases for privacy to be in-scope for > this group or do you consider only the technical implementation of > privacy (e.g. section 4 of 6962-bis and the redaction draft) to be > in-scope? Yes that is in scope. What we want to avoid is talking about specific vendors' use and local polic= y. Technical discussions are in scope, especially if it relates to RFCs or draf= ts or new ideas for potential new work. Paul >=20 > Thanks, > Peter >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Tue Nov 1 04:21:30 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19E3129632 for ; Tue, 1 Nov 2016 04:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQsGvqvyRxTN for ; Tue, 1 Nov 2016 04:21:26 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A9412962D for ; Tue, 1 Nov 2016 04:21:21 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 1C4434800103C for ; Tue, 1 Nov 2016 04:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=hznAW0Yo0r5VCUmp0V0fFmx63Tg=; b= Pou3rX7sCsaBvrw80OplottGfo8Uw/2HDDkisI34AGow6OQstzt+JpTdu/CsDVQG 1pv99+0yq8i4bMYDknGs/4m5RaPlKmlmv8yVrXcrXyUxLpotff5moN7ZzzNY9mOH mL1Z32iIhTGF+qzYxQHU/GzkBRcfe0GYZJDD0CnClUM= Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id EB2654800103A for ; Tue, 1 Nov 2016 04:21:20 -0700 (PDT) Received: by mail-oi0-f45.google.com with SMTP id i127so287539396oia.2 for ; Tue, 01 Nov 2016 04:21:20 -0700 (PDT) X-Gm-Message-State: ABUngvcfat+Pb7cHL/oAvXZ/1hYzO+NThfkfvtjSDJS212cc3NE1Q+wrC72QnB+wWEtDjcqHX7KmdtBKekECXw== X-Received: by 10.36.69.155 with SMTP id c27mr564396itd.1.1477999279746; Tue, 01 Nov 2016 04:21:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.24.130 with HTTP; Tue, 1 Nov 2016 04:21:19 -0700 (PDT) In-Reply-To: References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> <5ae04a85-f39a-c2f8-d206-7d6d70370fee@cs.tcd.ie> From: Ryan Sleevi Date: Tue, 1 Nov 2016 04:21:19 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c151960c385305403b869e Archived-At: Cc: Ryan Sleevi , Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 11:21:28 -0000 --001a11c151960c385305403b869e Content-Type: text/plain; charset=UTF-8 On Tuesday, November 1, 2016, Stephen Farrell wrote: > > I am quite interested in discussing privacy issues if they > exist here. (I don't however accept that corporate secrecy > is a privacy issue.) I don't see how, within a certificate, you can draw that line. We know people are deploying DNS names with PII (the U.K. tax offices naming scheme, for example, uses tax identifiers as subdomains). We know CAs are deploying subject naming information in certificates, and these are issued to natural persons. givenName and Surname are an example, but as Peter points out, CAs are issuing certificates for individuals (IV), and these are permitted to put the PII in the O field. I appreciate the "data needed" viewpoint, but I don't agree with using the extant logs to justify that viewpoint, especially when you consider what the extant logs are presently logging, and what's desired to be logged. I can appreciate you see a difference between corporate secrecy vs personal privacy - but perhaps you could articulate how that codifies into certificates being issued, or its technical relevance. I can understand that playing into discussions about which to punt on, but I don't feel you've done a good job articulating why you feel this distinction is relevant, or what end it serves, given the context of certificates. I'm entirely fine with discussion of privacy as it relates > to CT, and would be glad to see that. My main point is that > privacy is entirely different from corporate secrecy, and > conflating the two would be an error. Can you suggest a meaningful distinction between these two, as expressed in certificates? So going beyond the well understood use-cases has a number > of risks. Can you expand on what you see as well-understood? I thought both IV certs and QCP certs were well understood, at least within the context of the Web PKI. > To reiterate: I'm very happy if we discuss privacy so long > as we do not conflate that with corporate secrecy. There are > requirements for both, but they are far from the same. > Can we infer that you're happy to discuss corporate secrecy as well? Could you expand on why you see these requirements as different? --001a11c151960c385305403b869e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, November 1, 2016, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

I am quite interested in discussing privacy issues if they
exist here. (I don't however accept that corporate secrecy
is a privacy issue.)

I don't see how, w= ithin a certificate, you can draw that line.

We kn= ow people are deploying DNS names with PII (the U.K. tax offices naming sch= eme, for example, uses tax identifiers as subdomains). We know CAs are depl= oying subject naming information in certificates, and these are issued to n= atural persons. givenName and Surname are an example, but as Peter points o= ut, CAs are issuing certificates for individuals (IV), and these are permit= ted to put the PII in the O field.

I appreciate the &qu= ot;data needed" viewpoint, but I don't agree with using the extant= logs to justify that viewpoint, especially when you consider what the exta= nt logs are presently logging, and what's desired to be logged.
I can appreciate you see a difference between corporate secrecy= vs personal privacy - but perhaps you could articulate how that codifies i= nto certificates being issued, or its technical relevance. I can understand= that playing into discussions about which to punt on, but I don't feel= you've done a good job articulating why you feel this distinction is r= elevant, or what end it serves, given the context of certificates.


I'm entirely fine with discussion of privacy as it relates
to CT, and would be glad to see that. My main point is that
privacy is entirely different from corporate secrecy, and
conflating the two would be an error.

Can y= ou suggest a meaningful distinction between these two, as expressed in cert= ificates?

So going beyond the well understood use-cases has a number
of risks.

Can you expand on what you see as= well-understood? I thought both IV certs and QCP certs were well understoo= d, at least within the context of the Web PKI.
=C2=A0
To reiterate: I'm very happy if we discuss privacy so long
as we do not conflate that with corporate secrecy. There are
requirements for both, but they are far from the same.

Can we infer that you're happy to disc= uss corporate secrecy as well?=C2=A0Could you expand on why yo= u see these requirements as different?
--001a11c151960c385305403b869e-- From nobody Tue Nov 1 05:13:50 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5D3129533 for ; Tue, 1 Nov 2016 05:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwDBvWYw4wsx for ; Tue, 1 Nov 2016 05:13:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E39127A91 for ; Tue, 1 Nov 2016 05:13:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3B3DFBE5D; Tue, 1 Nov 2016 12:13:43 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyTfkRNlheMj; Tue, 1 Nov 2016 12:13:43 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ACB41BE58; Tue, 1 Nov 2016 12:13:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1478002423; bh=eon2VTyGZA7UVvKDYrzktKFDq3W3vJzfwmoOVH543tU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=D66P2bmj9aWl1k/hnskuecbyBiOaqem/H+UNSpSGMmwZY2k4iaWKV851BqWdwW1LE 8Rc8EGIJJQKzxonXf19qOMoEVQblvvKydnquSc4yUdCDnzVrVwg/zKwpzp7gMWbjvY YZrCnkpD6mBq6S1lpQ7uOob/UMzI4BGJghZ3AZf8= To: Ryan Sleevi References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> <5ae04a85-f39a-c2f8-d206-7d6d70370fee@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <243ad292-b394-71cc-0980-4cceb2520646@cs.tcd.ie> Date: Tue, 1 Nov 2016 12:13:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000605050402070601050607" Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 12:13:49 -0000 This is a cryptographically signed message in MIME format. --------------ms000605050402070601050607 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/11/16 11:21, Ryan Sleevi wrote: > On Tuesday, November 1, 2016, Stephen Farrell > wrote: >=20 >> >> I am quite interested in discussing privacy issues if they >> exist here. (I don't however accept that corporate secrecy >> is a privacy issue.) >=20 >=20 > I don't see how, within a certificate, you can draw that line. That's a fair question. I'm not sure I can draw a clean distinction, but then again the same is true e.g. wrt source IP addresses sometimes being (considered by some courts as) PII and sometimes not. We can however distinguish the .example.com use-case for corporate secrecy - in that case, there is mostly a need for secrecy only until the web site is launched. And that does differ from inclusion of non-changing PII (such as givenName) in DNs. To the extent there are any privacy issues with including a givenName, those issues don't go away in a few weeks. I'm less clear myself on the real need for keeping some hostnames secret forever but yet have the certs for those publicly logged. It may be that the better approach to that is to make clear that semantically meaningful hostnames in certs inevitably exposes those semantics, leading to a "dr. dr. it hurts when I do this" answer. > We know people are deploying DNS names with PII (the U.K. tax offices > naming scheme, for example, uses tax identifiers as subdomains).=20 I'd say that's a fairly clear example of a not-great design, once CT (or passive DNS) is considered. I don't have a strong position as to what the WG ought do about that, if anything. > We know > CAs are deploying subject naming information in certificates, and these= are > issued to natural persons. givenName and Surname are an example, but as= > Peter points out, CAs are issuing certificates for individuals (IV), an= d > these are permitted to put the PII in the O field. Are those all used for TLS client auth or in applications above TCP or TLS? It sounds like it'd be a fine thing if someone was motivated to describe the cases like that that have been seen in current logs, as well as cases where the inclusion of such information in certs is known but those are not ending up in logs. Absent that description, I'm not sure we can see what changes or additions the WG might develop. (Note: I'm not asking that such descriptive material be in an I-D or RFC.) I'd also comment that it may be the case that some CA practices that seemed ok before CT, might no longer seem like such a good idea now. And that's ok - I think that's just showing some evolution towards a better PKI. We do of course need to try not break things as we go but I don't think that just because one of the O(100) CAs in the world has been doing X necessarily means that X has to be catered for via changes to CT. >=20 > I appreciate the "data needed" viewpoint, but I don't agree with using = the > extant logs to justify that viewpoint, especially when you consider wha= t > the extant logs are presently logging, and what's desired to be logged.= I don't understand the above. >=20 > I can appreciate you see a difference between corporate secrecy vs pers= onal > privacy - but perhaps you could articulate how that codifies into > certificates being issued, or its technical relevance. I can understand= > that playing into discussions about which to punt on, but I don't feel > you've done a good job articulating why you feel this distinction is > relevant, or what end it serves, given the context of certificates. The distinction is relevant in that methods to protect corporate secrecy might or might not assist with personal privacy. > I'm entirely fine with discussion of privacy as it relates >> to CT, and would be glad to see that. My main point is that >> privacy is entirely different from corporate secrecy, and >> conflating the two would be an error. >=20 >=20 > Can you suggest a meaningful distinction between these two, as expresse= d in > certificates? I think the distinction is that privacy relates to people, whereas corporate secrecy does not, one is trying to protect some corporate asset. As I said above I don't claim to have a crisp way to distinguish those "as expressed in X.509." That might emerge though from discussion, not sure. >=20 > So going beyond the well understood use-cases has a number >> of risks. >=20 >=20 > Can you expand on what you see as well-understood? I thought both IV ce= rts > and QCP certs were well understood, at least within the context of the = Web > PKI. I don't get the question sorry. What I'm saying is that we need to be careful e.g. when discussing how CT might relate to better interpersonal messaging. That doesn't mean that we shouldn't discuss such things, but we ought not think that changes to CT will somehow make better e2e email happen - that'd be a cart before the horse kind of thing. >> To reiterate: I'm very happy if we discuss privacy so long >> as we do not conflate that with corporate secrecy. There are >> requirements for both, but they are far from the same. >> >=20 > Can we infer that you're happy to discuss corporate secrecy as well?=20 Of course. > Could > you expand on why you see these requirements as different? See above wrt the duration for which protection is needed issue for one well known use case for corporate secrecy. In terms of privacy, I think there's a difference in that the use of certs that might contain PII may be such that equivalent (but not necessarily bitwise identical) PII is inevitably exposed (say in mail header fields) to the point where there's no good reason to try hide the version of that information that's visible in a CT log. I think it is also the case that there will be cases where the best way to protect PII is to say "putting that in a cert is not best practice as it'll show up in CT logs." That may well conflict with some existing CA practices, which is something that warrants discussion. Note I'm not saying that "omit PII" is "the one true answer" but it might be the best we can do in some cases. There is also a danger if we allow redaction to be posed as a solution for long-term exposure of PII - the danger being that that might allow forms of mississuance to re-emerge whilst not actually protecting privacy. (If redaction is posed as a privacy protection, then in principle one has to be able to redact nearly any field in X.509, which is a danger for the effectiveness of CT I think.) I think that danger is itself a sufficient reason to distinguish carefully between privacy and corporate secrecy in CT discussions. S. >=20 >=20 >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans >=20 --------------ms000605050402070601050607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDEx MjEzNDJaMC8GCSqGSIb3DQEJBDEiBCBAgbZp01shoZqtv5Ut+EXPgeo5umK3z6C1E5AtPDPD NjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAltGujYTJy24ll2gXgWBHHUEOUX7UYkGq1t1wHSQcA8yWtgwjovrXo gFu2r/9NMHB9wLjvavbm3n+PWrXw/gEfZiRxCznINbLNWNXo40NiKEgWJ8+r8flslu91iFDu C3P6uHzTpP0TOPsfz2f2ld0tQkeey+sUYeEdhc4GAjciXD9cwy0qjgZ94APreEB9YsXYKcJk oa3f4KibksI4BSoz4j27J/xgr9wPHGqsRx5956KQNRP5nUntGfQ8GlUGFKh8tY1cXgE4O6Hd laP2Jp9bKceF4uIEJZlRM4KicxMg2d836c+QwKyl5gyTVK7BJ9Xd+eCHLbfJhCbGwRUD8aYN AAAAAAAA --------------ms000605050402070601050607-- From nobody Tue Nov 1 19:19:45 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212EB1294C3 for ; Tue, 1 Nov 2016 19:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XkcbD3T5dWN for ; Tue, 1 Nov 2016 19:19:42 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C281A12007C for ; Tue, 1 Nov 2016 19:19:42 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id m138so62550026itm.1 for ; Tue, 01 Nov 2016 19:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=MHmoSNqiOHAE6Y7ay2nPWocNw9nwc6D7Un1fxWpOfuo=; b=f5F5VujB/W4s4lCGGOm3mkh+pgxp2ls9HMgxqoGcbYypqwYK8ep3OOMKaJyHeS0uGM D5800IfoZqt8erjc6nGc9iE1xZx+feZ2n4tVHf+Rk1IAARaqHb4jKX1tHt22orp7C+4z iRq6gwh0FJOyvdtjxhkdIlQeW/2FDKEPAX38hKUTnh3FeQA6kOBFV1/xjjDPXjICOCiG oEx9o7xZcYJFU4B9lrMVXVo+W3RK8WgvD285EvW3PB0uOjPlxnDUiqYZoCxRaXgX7N56 lU4HsKT89dSaDz4W9y0mX7XzL7NbW59EQcgFCcLJhUjMnq9JkGnvLq6X8qDSTd3/oxwl Pfig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MHmoSNqiOHAE6Y7ay2nPWocNw9nwc6D7Un1fxWpOfuo=; b=Rlj+3f3FeasdXGa6cSokt6m5L7kUXk33l5odUZ63cYi2fAHnYXPOzZqr9Gv9Ivc9ph wt1Liy8PTiBogUnMsvhlBA/UuDB3NIFWDogGZ/S4ieF6jkecT+gF5Q5NJMT01xsXvGZI 2yIM02otdWVnthyFY8jwkh5+z+rDcRR43Dg66AQZ9hp+Gbsf/7qQz/k4od7kUGO2rAbN Bi4646TazUYg3K+2E2urCrUwyYuHCJA7FX1/oFH+WjBykbR5JbHBWnBE5JBg6BVgYRBq GOch2MmQPnr6s8qiy1S9ry9r0N8ax2s5gYyrdolX6tTLKSzuCMBFoK+CzaKmDJpeUPL7 jsnQ== X-Gm-Message-State: ABUngveMD5xf+ZKfLkFMnwp9L77sotbiRxPgz4hF1nERHk+fI31slO0EtqUVO1vq0NsMDXs+c+woY6wjDiWWtQ== X-Received: by 10.107.17.6 with SMTP id z6mr1719637ioi.1.1478053181471; Tue, 01 Nov 2016 19:19:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.39.68 with HTTP; Tue, 1 Nov 2016 19:19:40 -0700 (PDT) From: Peter Bowen Date: Tue, 1 Nov 2016 19:19:40 -0700 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 02:19:44 -0000 Currently 6962bis section 5.1 says: "Logs MUST verify that each submitted certificate or precertificate has a valid signature chain to an accepted trust anchor, using the chain of intermediate CA certificates provided by the submitter. [...] logs MUST reject submissions without a valid signature chain to an accepted trust anchor. Logs MUST also reject precertificates that do not conform to the requirements in Section 3.2." Is there a reason this is enshrined as a MUST? It seems like it should be up to the log operator to determine their policy. For example, a log operator might want to add a feature to accept certificates which have incomplete chains and have the log add the missing links from data it already has or a log operator may want to allow logging of certificates that are also published for DANE with TLSA records with certificate usage 2 or 3. It feels very restrictive to require that every log only accept certificates that follow the traditional hierarchical PKI model. I can see value in providing guidance of what a log MAY want to do. However requiring such seems to limit the potential of transparency in undesirable ways. Thanks, Peter From nobody Wed Nov 2 04:10:29 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD5012955F for ; Wed, 2 Nov 2016 04:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQgEPtXPpZNs for ; Wed, 2 Nov 2016 04:10:20 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B673A129AE8 for ; Wed, 2 Nov 2016 04:10:19 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id t79so29545604wmt.0 for ; Wed, 02 Nov 2016 04:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gbzD0gp3osFyn93gN/TBrz9amzCauUu5O9vMZTPrPx0=; b=Qr9eJMdImwX3D7+VqwoMaW8i4ICRGEdLDasw3cXad0qhahWY4JpsZdYuCsDSLawJKp giJxfYDAkZXp+uo2BaSI6w2uuEbjCLjKEz8jZeqaPgjRUkXignDKrkudbsgbnBtF7nAw IM5nO9W4RzhY0YWw8KTW5CVsK4ap3NQoMhhzxJvs+lMT4haQWG5b9P0E6tVxN4C+BMAd lrAQhYsvxyZXWtqmUU+ZKNOK6vjceGs3E0aA5JHQ0/2NAiYlIj71X1UbQTIkISBFhVvY CZuIpGCUOJhzVmSjvqFhHpiTDNAi5vMdKKL52aMQ56L7RybYPBiJ+V+/sotdJck/TTnF 9dlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gbzD0gp3osFyn93gN/TBrz9amzCauUu5O9vMZTPrPx0=; b=nAdVxtG4ZDhFYyb8xtX41DZIeVF6nZ2+dmLVEj3TrFEUSEMaUg3L+Tb62PBMHKtIIR gI9M9W6CTyJOX9/w9x4pRlFcqTJJjJXLaW+Qq3/4JLTx3Q+EpbwC89hrgpkj9LUOY2Nv QN0Qpe6NviF0rjZNI/vPbJVncMJxuc+uLpp1EjZBH6PcS0vJbShKSxljjwjv/xwoFLGA nVuzWLbWc3E9fi+WWG7Ma9QD32SuqYeCFgl61I5Wm3e9mTi9EEEn1c53cZnGI571dI1M XEyYv7ukin/E3FtxZXkcnt2mtkbPq7ipUdY0JwaQVxfx5iE0U21PgnUtPb5COd1sXrR1 PYDg== X-Gm-Message-State: ABUngveWr5izUssxdOEmh9qyO18gyQYGWzJZpYbsNVCa2YBvDhuxQl5LgoNRYzx01vea/E0ze8/p+YFYrEu7UD9F X-Received: by 10.28.49.85 with SMTP id x82mr2862462wmx.129.1478085018137; Wed, 02 Nov 2016 04:10:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.31.21 with HTTP; Wed, 2 Nov 2016 04:10:17 -0700 (PDT) In-Reply-To: References: From: Eran Messeri Date: Wed, 2 Nov 2016 11:10:17 +0000 Message-ID: To: Peter Bowen Content-Type: multipart/alternative; boundary=001a1142dd787491ff05404f7c34 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 11:10:28 -0000 --001a1142dd787491ff05404f7c34 Content-Type: text/plain; charset=UTF-8 This is a really good question, in that I can see why some log operators would like to set their own policies for accepting certificates into the log. Each of the potential policies I've personally encountered, though, seemed unique - there wasn't a common set of parameters that could be standardized. Not specifying, in a standard manner, which submissions should be accepted by a log will make it difficult to (1) check a log implementation for spec compliance (2) clients to figure out where they should submit their certificates to or why submissions are rejected. The current text makes it very straightforward for a client to figure out if their submission will be accepted by a given log (overall makes the protocol very simple). I think (and I may be wrong) that there's still flexibility in allowing the log to control the accepted submissions in a fine-grained manner by being selective about the trust anchors used - the trust anchors do not have to be root certificates, they could be intermediates. What I wrote above only applies to server certificates - with other uses, such as DANE, there may be other aspects of 6962-bis that are not suitable. Given lack of concrete interest in using Certificate Transparency logs* for certificates other than server certificates I don't know how much sense it'd make to account for them in 6962-bis. To be clear: I am not opposed to relaxing section 5.1 (and there are arguments for changing the MUST to a SHOULD so that a log that drops submissions for DOS protection, for example, is not considered non-compliant). My argument is that if we relax it, it should be done in a well-defined way such that a client implementation will not have to rely on unspecified knowledge / external metadata to figure out which logs will accept its submissions. Eran * - There's plenty of interest in transparent logs / verifiable data structures, but those projects utilize the underlying data structure and general concepts, but are not tied to the -bis protocol/specification. On Wed, Nov 2, 2016 at 2:19 AM, Peter Bowen wrote: > Currently 6962bis section 5.1 says: > > "Logs MUST verify that each submitted certificate or precertificate > has a valid signature chain to an accepted trust anchor, using the > chain of intermediate CA certificates provided by the submitter. [...] > logs MUST reject submissions without a > valid signature chain to an accepted trust anchor. Logs MUST also > reject precertificates that do not conform to the requirements in > Section 3.2." > > Is there a reason this is enshrined as a MUST? It seems like it > should be up to the log operator to determine their policy. For > example, a log operator might want to add a feature to accept > certificates which have incomplete chains and have the log add the > missing links from data it already has or a log operator may want to > allow logging of certificates that are also published for DANE with > TLSA records with certificate usage 2 or 3. It feels very restrictive > to require that every log only accept certificates that follow the > traditional hierarchical PKI model. > > I can see value in providing guidance of what a log MAY want to do. > However requiring such seems to limit the potential of transparency in > undesirable ways. > > Thanks, > Peter > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a1142dd787491ff05404f7c34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a really good question, in that I can see why some= log operators would like to set their own policies for accepting certifica= tes into the log.

Each of the potential policies I'v= e personally encountered, though, seemed unique - there wasn't a common= set of parameters that could be standardized.

Not= specifying, in a standard manner, which submissions should be accepted by = a log will make it difficult to (1) check a log implementation for spec com= pliance (2) clients to figure out where they should submit their certificat= es to or why submissions are rejected. The current text makes it very strai= ghtforward for a client to figure out if their submission will be accepted = by a given log (overall makes the protocol very simple).

I think (and I may be wrong) that there's still flexibility in a= llowing the log to control the accepted submissions in a fine-grained manne= r by being selective about the trust anchors used - the trust anchors do no= t have to be root certificates, they could be intermediates.=C2=A0

What I wrote above only applies to server certificates - w= ith other uses, such as DANE, there may be other aspects of 6962-bis that a= re not suitable. Given lack of concrete interest in using Certificate Trans= parency logs* for certificates other than server certificates I don't k= now how much sense it'd make to account for them in 6962-bis.=C2=A0

To be clear: I am not opposed to relaxing section 5.1= (and there are arguments for changing the MUST to a SHOULD so that a log t= hat drops submissions for DOS protection, for example, is not considered no= n-compliant). My argument is that if we relax it, it should be done in a we= ll-defined way such that a client implementation will not have to rely on u= nspecified knowledge / external metadata to figure out which logs will acce= pt its submissions.

Eran

= * - There's plenty of interest in transparent logs / verifiable data st= ructures, but those projects utilize the underlying data structure and gene= ral concepts, but are not tied to the -bis protocol/specification.=C2=A0



On Wed, Nov 2, 2016 at 2:19 AM, Peter Bowen <pzbowen= @gmail.com> wrote:
Currentl= y 6962bis section 5.1 says:

=C2=A0 "Logs MUST verify that each submitted certificate or precertifi= cate
=C2=A0 =C2=A0has a valid signature chain to an accepted trust anchor, using= the
=C2=A0 =C2=A0chain of intermediate CA certificates provided by the submitte= r. [...]
=C2=A0 =C2=A0logs MUST reject submissions without a
=C2=A0 =C2=A0valid signature chain to an accepted trust anchor.=C2=A0 Logs = MUST also
=C2=A0 =C2=A0reject precertificates that do not conform to the requirements= in
=C2=A0 =C2=A0Section 3.2."

Is there a reason this is enshrined as a MUST?=C2=A0 It seems like it
should be up to the log operator to determine their policy.=C2=A0 For
example, a log operator might want to add a feature to accept
certificates which have incomplete chains and have the log add the
missing links from data it already has or a log operator may want to
allow logging of certificates that are also published for DANE with
TLSA records with certificate usage 2 or 3.=C2=A0 It feels very restrictive=
to require that every log only accept certificates that follow the
traditional hierarchical PKI model.

I can see value in providing guidance of what a log MAY want to do.
However requiring such seems to limit the potential of transparency in
undesirable ways.

Thanks,
Peter

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

--001a1142dd787491ff05404f7c34-- From nobody Wed Nov 2 06:39:34 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBC91294B6 for ; Wed, 2 Nov 2016 06:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BJxdUtXG6AY for ; Wed, 2 Nov 2016 06:39:30 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828BE1295A7 for ; Wed, 2 Nov 2016 06:39:30 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id d2so12520634pfd.0 for ; Wed, 02 Nov 2016 06:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=QsXz+bXiO6BgiZf92rVhHwA6BooCnQi70DkhxIehyyI=; b=RyIjuHbFKDLnejtG1oUF4hk87oCuJuKRptBQp13D0wv+B67ztE5LpvSf0e2HhYuCXj lRx2ZiPX91UfkMbb92TVKDX48s+f8l987HKGx4QqqQC0Oal4SmApz+YC/bAzkvxdg7wx DxoFgzUxGc1ZdzjK/yKhlcgbC45LHZ3FglIL7CGX+Blmms/1dsY2hs3j7zf5cOzgV7o+ NDur2lJXIbr+qym7vBopQalM609iwJn7Kvk/Nggg3bRORw5gXj8bHYBwjsR5atHz0+pO qv5AIyVOs5SUObniDVgfZawcXjYpkM5eTESJt85BD7Lq5vt4j6wwFKJ0W6CJdKmNele5 1UGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=QsXz+bXiO6BgiZf92rVhHwA6BooCnQi70DkhxIehyyI=; b=DPe5dl8fGxSNpAxAoUxoYZmHWTGOscfsLapPwft5u/bNApcVAp96aaCKyp+w3uzfSt kQl7dyAEJC06ND2nnb3vayVti9sYshMWw6TxJOQddzApyK+UPkqLWlDEi6xUGQNO1goO n2cIVLGEX1WYjzwFlBp7v3mqm5rGCIoA+2mVwKJdCrWb817LoTj1PpKx/t4smh1U2FGt msq7uuvQqC+y/fa2T1O2KTjuwhXgIyw+rBFVC+sxA8bz6coJp2ujDn6X8AOlTTHewxmW 9Q/D0Ow2oUXPiA3n2OP1JpgeVhMPYd6YZ/jC2HsanTLYGl2tNCpM2Q7SJkoLpCjw02Yv KDKA== X-Gm-Message-State: ABUngvc8r0OtCsliH3BuO9wMJ/F+YgfTPBjyUTEyiYrrOsBenko2YTAgTB1iS2iFEPTxmQ== X-Received: by 10.98.52.194 with SMTP id b185mr6940615pfa.41.1478093969708; Wed, 02 Nov 2016 06:39:29 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-40-114-radius.dynamic.acsalaska.net. [216.67.40.114]) by smtp.googlemail.com with ESMTPSA id vz6sm2939005pab.15.2016.11.02.06.39.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 06:39:29 -0700 (PDT) To: trans@ietf.org References: From: Melinda Shore Message-ID: <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> Date: Wed, 2 Nov 2016 05:39:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9BK7fJgG2MLwQUhuWGkWT7oiPuD997IDV" Archived-At: Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 13:39:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9BK7fJgG2MLwQUhuWGkWT7oiPuD997IDV Content-Type: multipart/mixed; boundary="PmNgA6IT7txDi8LBwlStLQaSwc7TPLwFE"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Message-ID: <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> Subject: Re: [Trans] Relaxing section 5.1 References: In-Reply-To: --PmNgA6IT7txDi8LBwlStLQaSwc7TPLwFE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, all: 6962-bis has completed working group last call. Minor editorial changes are fine, but let's try to avoid major changes that would require yet another WGLC. If there's a need for an additional document dealing with operational considerations or operational specifications, we can do that. If there's a major problem with 6962-bis, we can deal with that as well, but it would need to be serious (i.e. goes to the correctness of the specification, fixes something that's broken, etc.). Thanks, Melinda --PmNgA6IT7txDi8LBwlStLQaSwc7TPLwFE-- --9BK7fJgG2MLwQUhuWGkWT7oiPuD997IDV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYGeyFAAoJELiGRpM6HoEuCN0QAJEHy6WjY8mAgvBxp3385hP8 763gsOpXa3WGaQo6ID7ddyzR2d4cnGsxTUvCIF0DpmACfiHWNo5vU56Wo+Mh+2lM wtHQ93pd8ADHFY/CQt1DYgC+jqTK/CTUYNof9RW3SPHKvNMz4/hk9alh7qd6KwGR tVuGP+0YlsGTYcYZfCxkQajlzjlb+kaudc/6N5yPOgzfQquc/AoEGrFh+QC0jxy6 B+dafrSJIjskZndXU85SOzPwk1AKgXugAtudqBjHBZPhPCz6wiEaHRRW0G+OKKMW 9Y7KzWazcj+O5BwrEkb3lt7xF57A8iTGVM8UHTkAytn0DnMCNSJpIdBZMgXxzk7b EQBkU0T6+gvp9I2U2rjmcYI3RF4Bhyz+hiJuWOvcRZqCal6AxGHCF60q7TuFWyKP fVAj0L0FNU+nnhAPhHeGX9/t/1/SiJqcccK1oWdHMCIolMqiBJtIra/bhh5ztCxz 71bplUCE3jCxBOAXmmuzyPYAcvvKbM9Zv9nqGq3WzSA+VfurUYyyEIOwT4RdzSqD IFtSAIE9USlvxiDJhnSLFXEgy4dTkC3k1ObGH5tb/HUUcaUMm0BRxVFMmJuzhiJn 3wqH3csTuY4xlXW+z+YGPk4do2r5qRry/a4B32UHTZDBI04VHQt972goT79wQ7HU H0YfCkoq5Ru9rIXRrx2/ =e67g -----END PGP SIGNATURE----- --9BK7fJgG2MLwQUhuWGkWT7oiPuD997IDV-- From nobody Wed Nov 2 07:09:42 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CA5129491 for ; Wed, 2 Nov 2016 07:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnWPLZrx-0UR for ; Wed, 2 Nov 2016 07:09:39 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC4212945E for ; Wed, 2 Nov 2016 07:09:39 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id e187so83317401itc.0 for ; Wed, 02 Nov 2016 07:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X5qo3vPCnfrLxuBmcUwjYg7y4tmuBrrj+KV4eM2u7rg=; b=CetDFDSCCiRVylcuFaH+R5Wr1K8UMOR74Kp5A7FnkJrpRaCvJNMpdfxDKPkOGACJy9 keWTvMD6afs7Oj5Jgnl83VtbSMcLbA22Jkoex4KCx3q49M0HgncZos0Kiufiw1F5AUB7 XP8u4LsvXcEi3vV1WT2EWGkWctMbSUAeeqbnSAlbBhrzUI+yxq6E+0hl1eeLc2nQnXFD WStoa2uJ74tztxHmSlgckISUq+ePJJnlh9bsLnL29rc4sCv28bXaVg2Stp6DzDUAumyG pHauxgNjUeN2uAWpyNw0RvW3ou56sMkykLKHWmGA5HjZq2EMaG7UiXL98xXGvuR0sZ5Y aTGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X5qo3vPCnfrLxuBmcUwjYg7y4tmuBrrj+KV4eM2u7rg=; b=Iaba/VQC8FjuSrGMEtilaq3kWm648YbbXbgRSVrqEfUFOhjjqHHTbzgUvQjYKPP/Xh XEmCcJ/a1T3mpNIf9kxmI3PLtAXJRFqzP7paI+vqMlnms3cCIHL7Q1LnjMOa05hl35Qv Vvjj4TbXqtY6TaTh5jvAD4pM8YiRtFS3SpPBuZ7b7OH8608G0l/4zVsfe7Z8Jgd51BuT sx00fUIjZemA5pAVImB3G213lyJ1gFoogm3WfUFB+40KQXgbUZ9mJKsQjRnkn8M96QMs vUOdZ8+n3lC1OO+4Wab3xZcqcU6OblApfZPxJY/WoyR7fD9k7iLRdpSPncI2PJ4GJ6nb QsrQ== X-Gm-Message-State: ABUngvekVxUMAs2ecmcepw7Pw70/w+T5M3JCBWxwiZmAJ2xacc2F8BRl7DVoip6vgnKOblu2UMj6mvVCgSrxkg== X-Received: by 10.107.184.214 with SMTP id i205mr4383753iof.167.1478095726564; Wed, 02 Nov 2016 07:08:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.39.68 with HTTP; Wed, 2 Nov 2016 07:08:45 -0700 (PDT) In-Reply-To: <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> References: <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> From: Peter Bowen Date: Wed, 2 Nov 2016 07:08:45 -0700 Message-ID: To: Melinda Shore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 14:09:41 -0000 On Wed, Nov 2, 2016 at 6:39 AM, Melinda Shore wrote: > 6962-bis has completed working group last call. Minor editorial > changes are fine, but let's try to avoid major changes that would > require yet another WGLC. If there's a need for an additional > document dealing with operational considerations or operational > specifications, we can do that. If there's a major problem with > 6962-bis, we can deal with that as well, but it would need to > be serious (i.e. goes to the correctness of the specification, > fixes something that's broken, etc.). I realize that 6962bis has passed WGLC, so I know there is a high bar for changes. However I think this might pass that bar. The highly restrictive language that imposes minimum policy for logs prevents interoperability with other IETF RFCs on the standards track very hard. 6962bis appears to assume that DANE (RFCs 7671 and 6698) will never be implemented and that concepts like RFC 6091 will never come to fruition. By requiring all logs MUST accept any certificate that chains to a root in the log's root list, 6962bis fails to allow log operators to mitigate any Denial of Service attacks mounted by attempting to log massive numbers of certificates that are not relevant to the log scope. For example, many existing certification authorities issue both server authentication certificates and certificates for personal identification. For some roots, acquiring large numbers of these is relatively easy (see discussion of fetching millions of Taiwanese Citizen Digital Certificates in https://smartfacts.cr.yp.to/smartfacts-20130916.pdf). As written today, a log MUST accept these. There is no option for a log to require that all certificates must meet some usability criteria. I agree that a future additional document dealing with operational considerations is fine, but as drafted today, 6962bis does not allow a log to implement these considerations. Thanks, Peter From nobody Wed Nov 2 08:58:04 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007E31296AE for ; Wed, 2 Nov 2016 08:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlvvtqhluylB for ; Wed, 2 Nov 2016 08:58:00 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8224312950D for ; Wed, 2 Nov 2016 08:58:00 -0700 (PDT) Received: from email.digicert.com (ex1-sgu [10.12.1.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPS id 8804A8FAA54; Wed, 2 Nov 2016 15:57:59 +0000 (GMT) From: Jeremy Rowley To: Stephen Farrell , Peter Bowen , Melinda Shore Thread-Topic: [Trans] Topicality Thread-Index: AQHSLnmWWB7iOlW+ek2jHVncrasLD6DDWgcAgAAypQCAAlix8A== Date: Wed, 2 Nov 2016 15:57:58 +0000 Message-ID: <501775b31e9a49ec962512b7aa48e3cd@EX2.corp.digicert.com> References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> In-Reply-To: <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0099_01D234EF.96354FB0" MIME-Version: 1.0 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 15:58:02 -0000 ------=_NextPart_000_0099_01D234EF.96354FB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here's what we are dealing with on this front: The EU has a right to be forgotten which requires a data controller to = remove data that is no longer necessary or irrelevant for the original = purposes for which the data was collected. Primarily, courts have = interpreted this as requiring a search engine to remove information = about a person at that individual=E2=80=99s request. This has caused = consider headaches for Google.=20 CT monitors are likely considered a search engine that identify = certificates with personal information included. However, CT, by design, = cannot delete information from logs and any deletion will cause the log = to fail. This puts CT at odds with EU privacy laws as certificate = subjects often contain individual information, email addresses specified = in the SANs, and SANS DNS entries that identify an individual (albeit = this is a stretch).=20 I'm having trouble reconciling how a monitoring service/log operator is = supposed to comply with the EU requirements without supporting = redaction.=20 Jeremy -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Monday, October 31, 2016 4:03 PM To: Peter Bowen ; Melinda Shore = Cc: trans@ietf.org Subject: Re: [Trans] Topicality Peter, On 31/10/16 19:01, Peter Bowen wrote: > On Mon, Oct 24, 2016 at 9:37 PM, Melinda Shore = wrote: >> You may have seen the recent announcement from the Chrome team that=20 >> as of October 2017 certificates will need to comply with Chrome's CT=20 >> policy in order to be trusted. There was also an invitation to=20 >> discuss that on the trans mailing list. >> This is a reminder that mailing list discussions need to remain=20 >> focused on the specifications being produced by the working group -=20 >> that is to say, policies related to individual implementations are=20 >> out of scope for the working group except to the extent that they=20 >> bear on decisions related to our working group drafts. >=20 > Paul and Melinda, >=20 > Do you consider discussion of use cases for privacy to be in-scope for = > this group or do you consider only the technical implementation of=20 > privacy (e.g. section 4 of 6962-bis and the redaction draft) to be=20 > in-scope? (Wearing no IETF hat, but perhaps the hat of someone interested in = privacy...) I do not believe that it makes sense for us to talk as if privacy was a = concept that applies to corporate entities. I do believe that your text above conflates privacy (a human concept) with corporate secrecy (a useful but different thing) in ways = that are in the end damaging to both. (I further and even moreso believe = that such conflation would be damaging to the IETF were we to slip into = the bad practice of not calling out that terminological sloppiness.) I totally get that redaction has utility for folks who need corporate = secrecy on a temporary basis. I absolutely do not accept that that has = any privacy aspect. Can you call out the privacy aspect that applies to humans and that is a = real part of the question related to support for redaction in CT? Thanks, S. >=20 > Thanks, > Peter >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans >=20 ------=_NextPart_000_0099_01D234EF.96354FB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMTAyMTU1NzU2WjAj BgkqhkiG9w0BCQQxFgQUoLD31NkbkFBfaeSoFHJ3lPeGCQQwgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAGZzL4fImrS38+vpAzgfYwfULVSPRQ+DtgFr1K9n eks8gXP0H9VVtnV4PLMcr26oEuC9UdELYkOCe/9sT1HWuzvn+bLDKtF0atFqsJRV6ND9p7RTf/S0 07GuSXELPBrIZWGySD5inxO8WusSV/kRY2eVV8Ivdv0voSXo8AztEZI0rf1KYyDr4iOA0ecCtiL2 SrJesoYnGfnRzwwL5PT8qlUKR4ZxWOLGFiezzLDoGyD0VRm3QBFzAamDYVcwOEQdOnX6tSsxaxBR ZGSu7elADMRZSmeLOdo1bbInvboDrtTg5kRBvPgR4ywaGs1dFfgfdjuaDQGmPtgQsh7WoK3MeCkA AAAAAAA= ------=_NextPart_000_0099_01D234EF.96354FB0-- From nobody Wed Nov 2 09:05:33 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEF71296B6 for ; Wed, 2 Nov 2016 09:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEvsRPpoOLlX for ; Wed, 2 Nov 2016 09:05:31 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4255C1296A1 for ; Wed, 2 Nov 2016 09:05:31 -0700 (PDT) Received: from email.digicert.com (ex1-sgu [10.12.1.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPS id 07A667FA9D2; Wed, 2 Nov 2016 16:05:31 +0000 (GMT) From: Jeremy Rowley To: Zakir Durumeric , Andrew Ayer Thread-Topic: [Trans] Log Monitoring API Thread-Index: AQHSH+Vo8L5e77e05EilIke+qTFtNKC58YgAgAL11ACACR6joA== Date: Wed, 2 Nov 2016 16:05:29 +0000 Message-ID: <87fc2dbf2cdf4d378749e9d0a4a883a5@EX2.corp.digicert.com> References: <55796DF2.9050705@comodo.com> <557A0067.1060003@bbn.com> <557AAD15.8060001@comodo.com> <557B1834.8040706@bbn.com> <20161025103652.da027f9a7ebeb06eb42c358b@andrewayer.name> <618E8DBD-7C62-458B-9DD3-847029A26F38@umich.edu> In-Reply-To: <618E8DBD-7C62-458B-9DD3-847029A26F38@umich.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00AC_01D234F0.A369EFF0" MIME-Version: 1.0 Archived-At: Cc: Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] Log Monitoring API X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 16:05:32 -0000 ------=_NextPart_000_00AC_01D234F0.A369EFF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We're happy to be involved. Clint Wilson will be contributing from our side. -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Zakir Durumeric Sent: Thursday, October 27, 2016 8:49 AM To: Andrew Ayer Cc: Rob Stradling ; trans@ietf.org Subject: Re: [Trans] Log Monitoring API I would be happy to be involved, and the Censys Project would be interested in implementing an agreed API as part of its CT monitoring. Zakir > On Oct 25, 2016, at 12:36 PM, Andrew Ayer wrote: > > On Thu, 6 Oct 2016 16:21:59 +0100 > Rob Stradling wrote: > >> Now we've completed WGLC for 6962-bis, I'd like to pick this thread >> back up again. >> >> Several different public CT monitoring services now exist (crt.sh, >> Cert Spotter, Censys.io, etc). ISTM that it would be useful to >> define a common API that could be implemented by each monitor, so >> that end-users don't have to implement multiple APIs in order to talk >> to multiple monitors. >> >> Matt Palmer and I made a start on a (very drafty) draft a while ago: >> https://github.com/tobermorytech/ct-monitor-api-rfc/blob/master/draft >> -palmer-ct-monitor-api.md >> >> Who's interested in working on this? > > Count me in. > > Regards, > Andrew > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans ------=_NextPart_000_00AC_01D234F0.A369EFF0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMTAyMTYwNTI4WjAj BgkqhkiG9w0BCQQxFgQUCvJvKw2Jv7XrNagGnWgn3SAp9cEwgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAFkqfzOB+L6m5S5EFfLQ2egZqwp3p97r7Bv/8wWX JkGEpZL3uBDGgMmSfxOGOG6i6g2vDuOLK5Fu1wgsoddgIuJG7/gOLFh8dH8k8bbSEAbi2jMAvndh LqqlyfIbexqzr1E8O6Hj1urSXp9PHrWptl8ZmoTF1W3C3dDdsj+LCckwtgfJsm7amxfSFvEelwLr sGOeVAiAIlHH/6Eg4ewMyQSibWf79M9xxufiszLZi+ErNXCHTmsdYbCUQHOmrPGpSvNrHyDTH4gr yOAIaRTK4uEm5ERztTPU3jiSoTupIHRBrjBSQhEydq+ZK+T5+bHEgOT6YzBHfVPA9gKHJygTay0A AAAAAAA= ------=_NextPart_000_00AC_01D234F0.A369EFF0-- From nobody Wed Nov 2 09:13:35 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839FA1293F3 for ; Wed, 2 Nov 2016 09:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2kzgfXZhswH for ; Wed, 2 Nov 2016 09:13:32 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0C11296B9 for ; Wed, 2 Nov 2016 09:13:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8F296BE55; Wed, 2 Nov 2016 16:13:29 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3eYznFT6Z1k; Wed, 2 Nov 2016 16:13:29 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AC8EEBE2F; Wed, 2 Nov 2016 16:13:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1478103209; bh=DevHwsdTQ5CfwLqk/qayUZi66/eIqnZ9AK3XB2T3GQM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ZRexbW8LI30gSbILzJAx70RAaB5ZXYI+YCpCbVRGQZTHgVafBp3B+ciZeppxlIk2D EdjB9X0HX7aV0ODdD1+TLyPCwkXglutMNjLU21He9NyyzwPTXusBJZpFOopqFa97oi mt6+Wc3GxbG8dhHYxs4g3gqiGFrItUl+Jsjj7Q/Q= To: Jeremy Rowley , Peter Bowen , Melinda Shore References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> <501775b31e9a49ec962512b7aa48e3cd@EX2.corp.digicert.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 2 Nov 2016 16:13:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <501775b31e9a49ec962512b7aa48e3cd@EX2.corp.digicert.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000708050301060200040003" Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 16:13:34 -0000 This is a cryptographically signed message in MIME format. --------------ms000708050301060200040003 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/11/16 15:57, Jeremy Rowley wrote: > Here's what we are dealing with on this front: >=20 > The EU has a right to be forgotten which requires a data controller > to remove data that is no longer necessary or irrelevant for the > original purposes for which the data was collected. Primarily, courts > have interpreted this as requiring a search engine to remove > information about a person at that individual=E2=80=99s request. This h= as > caused consider headaches for Google. >=20 > CT monitors are likely considered a search engine that identify > certificates with personal information included. However, CT, by > design, cannot delete information from logs and any deletion will > cause the log to fail. This puts CT at odds with EU privacy laws as > certificate subjects often contain individual information, email > addresses specified in the SANs, and SANS DNS entries that identify > an individual (albeit this is a stretch). >=20 > I'm having trouble reconciling how a monitoring service/log operator > is supposed to comply with the EU requirements without supporting > redaction. What makes you think redaction would help? If anything from the entry in the log correlates with the cert then some wacky court could decide who knows what... Particularly with stuff like that so-called right to be forgotten, I'm not clear that we can plan ahead and guess what courts might or might not decide. (And IANAL of course:-) S. PS: As with the rest of this thread, the above is with no hats. >=20 > Jeremy >=20 >=20 > -----Original Message----- From: Trans > [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: > Monday, October 31, 2016 4:03 PM To: Peter Bowen ; > Melinda Shore Cc: trans@ietf.org Subject: > Re: [Trans] Topicality >=20 >=20 > Peter, >=20 > On 31/10/16 19:01, Peter Bowen wrote: >> On Mon, Oct 24, 2016 at 9:37 PM, Melinda Shore >> wrote: >>> You may have seen the recent announcement from the Chrome team >>> that as of October 2017 certificates will need to comply with >>> Chrome's CT policy in order to be trusted. There was also an >>> invitation to discuss that on the trans mailing list. This is a >>> reminder that mailing list discussions need to remain focused on >>> the specifications being produced by the working group - that is >>> to say, policies related to individual implementations are out of >>> scope for the working group except to the extent that they bear >>> on decisions related to our working group drafts. >>=20 >> Paul and Melinda, >>=20 >> Do you consider discussion of use cases for privacy to be in-scope >> for this group or do you consider only the technical implementation >> of privacy (e.g. section 4 of 6962-bis and the redaction draft) to >> be in-scope? >=20 > (Wearing no IETF hat, but perhaps the hat of someone interested in > privacy...) >=20 > I do not believe that it makes sense for us to talk as if privacy was > a concept that applies to corporate entities. >=20 > I do believe that your text above conflates privacy (a human concept) > with corporate secrecy (a useful but different thing) in ways that > are in the end damaging to both. (I further and even moreso believe > that such conflation would be damaging to the IETF were we to slip > into the bad practice of not calling out that terminological > sloppiness.) >=20 > I totally get that redaction has utility for folks who need corporate > secrecy on a temporary basis. I absolutely do not accept that that > has any privacy aspect. >=20 > Can you call out the privacy aspect that applies to humans and that > is a real part of the question related to support for redaction in > CT? >=20 > Thanks, S. >=20 >=20 >>=20 >> Thanks, Peter >>=20 >> _______________________________________________ Trans mailing list=20 >> Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans >>=20 >=20 --------------ms000708050301060200040003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDIx NjEzMjdaMC8GCSqGSIb3DQEJBDEiBCDdCHdnGSt8Uqc2kczDgKEJB3/WFLwsutz1qCEkL0VL FTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA0QjiCFQlEDAhXhJN6J0uNpuJddfTo8DhuHhI620i9dIrH76QyzdUJ PAt03e+V/Ed49s1YwDBU2Craav3G+pl8REuU/fGa7689buGhRveImx1fOlVdNh7D48w9yaUd i49aXRIgkTQMrDEe7QoeuC1lfLwLg2ALQkNmkOnkZB26xwrCEwyOYAv0dbBYr8k4ME/lla3L l9hqpOAC0y832mj1FcWSf5F7IpcSQYH+LS6hHb1j8lBj0bzUuogYMBKEfNqyAAIezetSNODE 6gf+ie5w1W8gQlAKCKS51rxHE6PhEQVwWsZFNV7nd2q0y2jGhCFW04h2dw92HP16QQVl8PH+ AAAAAAAA --------------ms000708050301060200040003-- From nobody Wed Nov 2 09:20:50 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94421296DB for ; Wed, 2 Nov 2016 09:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lMVxe6dVLln for ; Wed, 2 Nov 2016 09:20:47 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3AC1296E0 for ; Wed, 2 Nov 2016 09:20:45 -0700 (PDT) From: Jeremy Rowley Authentication-Results: mail.digicert.com; dkim=permerror (bad message/signature format) To: Stephen Farrell , Peter Bowen , Melinda Shore Thread-Topic: [Trans] Topicality Thread-Index: AQHSLnmWWB7iOlW+ek2jHVncrasLD6DDWgcAgAAypQCAAlix8IAAaluA//+b1iA= Date: Wed, 2 Nov 2016 16:20:37 +0000 Message-ID: <256566a33bd642368f46cdb62dba4eee@EX2.corp.digicert.com> References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> <501775b31e9a49ec962512b7aa48e3cd@EX2.corp.digicert.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0105_01D234F2.C0B4CC90" MIME-Version: 1.0 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 16:20:50 -0000 ------=_NextPart_000_0105_01D234F2.C0B4CC90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Wacky court decisions are always a risk. However, the EU has established = that data collectors must delete public facing personal information at = the information holder's request. There's a big difference between = planning for unknown legal changes and accounting for decisions already = made. By requiring logging of PII, we're essentially asking logs to fail = on a regular basis. Although redaction of subject info doesn't guarantee = a log won't fail because of a right to be forgotten request, it does = move logs in the direction of compliance. Jeremy -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Wednesday, November 2, 2016 10:13 AM To: Jeremy Rowley ; Peter Bowen = ; Melinda Shore Cc: trans@ietf.org Subject: Re: [Trans] Topicality On 02/11/16 15:57, Jeremy Rowley wrote: > Here's what we are dealing with on this front: >=20 > The EU has a right to be forgotten which requires a data controller > to remove data that is no longer necessary or irrelevant for the > original purposes for which the data was collected. Primarily, courts > have interpreted this as requiring a search engine to remove > information about a person at that individual=E2=80=99s request. This = has > caused consider headaches for Google. >=20 > CT monitors are likely considered a search engine that identify > certificates with personal information included. However, CT, by > design, cannot delete information from logs and any deletion will > cause the log to fail. This puts CT at odds with EU privacy laws as > certificate subjects often contain individual information, email > addresses specified in the SANs, and SANS DNS entries that identify > an individual (albeit this is a stretch). >=20 > I'm having trouble reconciling how a monitoring service/log operator > is supposed to comply with the EU requirements without supporting > redaction. What makes you think redaction would help? If anything from the entry in the log correlates with the cert then some wacky court could decide who knows what... Particularly with stuff like that so-called right to be forgotten, I'm not clear that we can plan ahead and guess what courts might or might not decide. (And IANAL of course:-) S. PS: As with the rest of this thread, the above is with no hats. >=20 > Jeremy >=20 >=20 > -----Original Message----- From: Trans > [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: > Monday, October 31, 2016 4:03 PM To: Peter Bowen ; > Melinda Shore Cc: trans@ietf.org Subject: > Re: [Trans] Topicality >=20 >=20 > Peter, >=20 > On 31/10/16 19:01, Peter Bowen wrote: >> On Mon, Oct 24, 2016 at 9:37 PM, Melinda Shore >> wrote: >>> You may have seen the recent announcement from the Chrome team >>> that as of October 2017 certificates will need to comply with >>> Chrome's CT policy in order to be trusted. There was also an >>> invitation to discuss that on the trans mailing list. This is a >>> reminder that mailing list discussions need to remain focused on >>> the specifications being produced by the working group - that is >>> to say, policies related to individual implementations are out of >>> scope for the working group except to the extent that they bear >>> on decisions related to our working group drafts. >>=20 >> Paul and Melinda, >>=20 >> Do you consider discussion of use cases for privacy to be in-scope >> for this group or do you consider only the technical implementation >> of privacy (e.g. section 4 of 6962-bis and the redaction draft) to >> be in-scope? >=20 > (Wearing no IETF hat, but perhaps the hat of someone interested in > privacy...) >=20 > I do not believe that it makes sense for us to talk as if privacy was > a concept that applies to corporate entities. >=20 > I do believe that your text above conflates privacy (a human concept) > with corporate secrecy (a useful but different thing) in ways that > are in the end damaging to both. (I further and even moreso believe > that such conflation would be damaging to the IETF were we to slip > into the bad practice of not calling out that terminological > sloppiness.) >=20 > I totally get that redaction has utility for folks who need corporate > secrecy on a temporary basis. I absolutely do not accept that that > has any privacy aspect. >=20 > Can you call out the privacy aspect that applies to humans and that > is a real part of the question related to support for redaction in > CT? >=20 > Thanks, S. >=20 >=20 >>=20 >> Thanks, Peter >>=20 >> _______________________________________________ Trans mailing list=20 >> Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans >>=20 >=20 ------=_NextPart_000_0105_01D234F2.C0B4CC90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMTAyMTYyMDM2WjAj BgkqhkiG9w0BCQQxFgQUSRRbhGQu4y80mlwhCHOTALDH2bUwgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAEb3DhSCNPK7CBpDJczxjqOk/3wQPi+j7stJY2dL QnPq0B2rzAYmaZ2NEe2ylCR1QA9BH2LssC7MWkqEF5xbttPXAFlxfzh/RvWvxRVK6qrPCfQOk07d BS6pEqVyQ7jpEnQ0/HkuMza+L8BEKzhGYTZ/Axr5UvxNFlsorH4n+AurUpnpuiCkwRtTOqzhhMef xcsviBaqmGLjpbUg6oDYSxbHzJVQ418SXRVWAQEVN4GQTZmSf1tluiv73YTWouD4AOtk/wnoGtct 03XDw69kgadRXNRB384qUkhAYiIuNrgREvSNEJ/vatBUFjhABIDKOZsVfuGT5pvv0XzX1/votdEA AAAAAAA= ------=_NextPart_000_0105_01D234F2.C0B4CC90-- From nobody Wed Nov 2 09:49:37 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C61B129466 for ; Wed, 2 Nov 2016 09:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwM0CiVPy9gr for ; Wed, 2 Nov 2016 09:49:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983E712945B for ; Wed, 2 Nov 2016 09:49:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A114CBE6F; Wed, 2 Nov 2016 16:49:32 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KrhYWEQoaZI; Wed, 2 Nov 2016 16:49:32 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2EF4EBE50; Wed, 2 Nov 2016 16:49:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1478105372; bh=KgyUGgeshZ8TloXQyT3CM8s+93j/1YlHRAhFKV1yT6Q=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=z5eRDZ4xuoLyEUw8mKjgHfBkhPEHk78Iev8jWc3r9p8ld/sIHd8sw+1DH+WZY3DLO GUGJ24c0NiPnq3G344HgIfwCzzRAU+JEjutgrmPUahFhZqbzfV19ecJZ3O6Kpu1bhh n04ylz1Lx73hnd6yJerpxuvgdD/kV5ttOVWXzIis= To: Jeremy Rowley , Peter Bowen , Melinda Shore References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> <501775b31e9a49ec962512b7aa48e3cd@EX2.corp.digicert.com> <256566a33bd642368f46cdb62dba4eee@EX2.corp.digicert.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1a797dfa-eb0d-f5df-9401-a6f1dfa4e1dc@cs.tcd.ie> Date: Wed, 2 Nov 2016 16:49:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <256566a33bd642368f46cdb62dba4eee@EX2.corp.digicert.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040305010104050603090502" Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 16:49:36 -0000 This is a cryptographically signed message in MIME format. --------------ms040305010104050603090502 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/11/16 16:20, Jeremy Rowley wrote: > Wacky court decisions are always a risk. However, the EU has > established that data collectors must delete public facing personal > information at the information holder's request.=20 I don't believe "delete" is right there - search engines gave different results when queried in different ways or from different places and the underlying sources (e.g. newspaper articles) weren't affected directly IIUC. While that is an evolving situation I'm not sure we can safely conclude what any of it might mean for CT. (Or for CRLs I guess if we want to get into speculation;-) S > There's a big > difference between planning for unknown legal changes and accounting > for decisions already made. By requiring logging of PII, we're > essentially asking logs to fail on a regular basis. Although > redaction of subject info doesn't guarantee a log won't fail because > of a right to be forgotten request, it does move logs in the > direction of compliance. >=20 > Jeremy >=20 > -----Original Message----- From: Stephen Farrell > [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, November 2, 2016 > 10:13 AM To: Jeremy Rowley ; Peter Bowen > ; Melinda Shore Cc: > trans@ietf.org Subject: Re: [Trans] Topicality >=20 >=20 >=20 > On 02/11/16 15:57, Jeremy Rowley wrote: >> Here's what we are dealing with on this front: >>=20 >> The EU has a right to be forgotten which requires a data >> controller to remove data that is no longer necessary or >> irrelevant for the original purposes for which the data was >> collected. Primarily, courts have interpreted this as requiring a >> search engine to remove information about a person at that >> individual=E2=80=99s request. This has caused consider headaches for >> Google. >>=20 >> CT monitors are likely considered a search engine that identify=20 >> certificates with personal information included. However, CT, by=20 >> design, cannot delete information from logs and any deletion will=20 >> cause the log to fail. This puts CT at odds with EU privacy laws >> as certificate subjects often contain individual information, >> email addresses specified in the SANs, and SANS DNS entries that >> identify an individual (albeit this is a stretch). >>=20 >> I'm having trouble reconciling how a monitoring service/log >> operator is supposed to comply with the EU requirements without >> supporting redaction. >=20 > What makes you think redaction would help? If anything from the entry > in the log correlates with the cert then some wacky court could > decide who knows what... Particularly with stuff like that so-called > right to be forgotten, I'm not clear that we can plan ahead and guess > what courts might or might not decide. (And IANAL of course:-) >=20 > S. >=20 > PS: As with the rest of this thread, the above is with no hats. >=20 >>=20 >> Jeremy >>=20 >>=20 >> -----Original Message----- From: Trans=20 >> [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Farrell Sent:=20 >> Monday, October 31, 2016 4:03 PM To: Peter Bowen >> ; Melinda Shore Cc: >> trans@ietf.org Subject: Re: [Trans] Topicality >>=20 >>=20 >> Peter, >>=20 >> On 31/10/16 19:01, Peter Bowen wrote: >>> On Mon, Oct 24, 2016 at 9:37 PM, Melinda Shore=20 >>> wrote: >>>> You may have seen the recent announcement from the Chrome team=20 >>>> that as of October 2017 certificates will need to comply with=20 >>>> Chrome's CT policy in order to be trusted. There was also an=20 >>>> invitation to discuss that on the trans mailing list. This is >>>> a reminder that mailing list discussions need to remain focused >>>> on the specifications being produced by the working group - >>>> that is to say, policies related to individual implementations >>>> are out of scope for the working group except to the extent >>>> that they bear on decisions related to our working group >>>> drafts. >>>=20 >>> Paul and Melinda, >>>=20 >>> Do you consider discussion of use cases for privacy to be >>> in-scope for this group or do you consider only the technical >>> implementation of privacy (e.g. section 4 of 6962-bis and the >>> redaction draft) to be in-scope? >>=20 >> (Wearing no IETF hat, but perhaps the hat of someone interested in=20 >> privacy...) >>=20 >> I do not believe that it makes sense for us to talk as if privacy >> was a concept that applies to corporate entities. >>=20 >> I do believe that your text above conflates privacy (a human >> concept) with corporate secrecy (a useful but different thing) in >> ways that are in the end damaging to both. (I further and even >> moreso believe that such conflation would be damaging to the IETF >> were we to slip into the bad practice of not calling out that >> terminological sloppiness.) >>=20 >> I totally get that redaction has utility for folks who need >> corporate secrecy on a temporary basis. I absolutely do not accept >> that that has any privacy aspect. >>=20 >> Can you call out the privacy aspect that applies to humans and >> that is a real part of the question related to support for >> redaction in CT? >>=20 >> Thanks, S. >>=20 >>=20 >>>=20 >>> Thanks, Peter >>>=20 >>> _______________________________________________ Trans mailing >>> list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans >>>=20 >>=20 >=20 >=20 >=20 > _______________________________________________ Trans mailing list=20 > Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans >=20 --------------ms040305010104050603090502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDIx NjQ5MzFaMC8GCSqGSIb3DQEJBDEiBCBdTWSO16jGyGWsANHLUaSKCq76KZr/OPZCAHmSljEN 8jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCFcR2jDmAowql7P0xXm4dA04xQcFhXOMT7zf/Z4LJ+bTUoxdgiJ8bD qmm8YKcRdynLHbmUEcMmLTe2XPNT3Hn4fVdl0nYOidQlYoDLQog0QrhnagmV0oI0toO3BF1c nC+gXCVlVaL6kN//Cu0pWrMv4MRvg7n2zIMZlN5thTdqaGdrhMLHbrLenliUnGOon+ygr8Vj EW4x5Ss31QOprmnqA9vtrxalvt7TTtXTzqbB9qf4S5CTWx9GYwIytVZDxsPFUACsZqdyWxzD Zfscz9BLGxBcscGGZUJE5O3W72fivpCHAbB35x8Y0EsSQQshTZ5VqABIYu0ipSdF0bLdEI/L AAAAAAAA --------------ms040305010104050603090502-- From nobody Wed Nov 2 10:09:56 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E171E12968B for ; Wed, 2 Nov 2016 10:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.689 X-Spam-Level: X-Spam-Status: No, score=-5.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmUkqoSFSuJx for ; Wed, 2 Nov 2016 10:09:53 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7471296B4 for ; Wed, 2 Nov 2016 10:09:53 -0700 (PDT) From: Jeremy Rowley Authentication-Results: mail.digicert.com; dkim=permerror (bad message/signature format) To: Stephen Farrell , Peter Bowen , Melinda Shore Thread-Topic: [Trans] Topicality Thread-Index: AQHSLnmWWB7iOlW+ek2jHVncrasLD6DDWgcAgAAypQCAAlix8IAAaluA//+b1iCAAG4+gP//oLFQ Date: Wed, 2 Nov 2016 17:09:51 +0000 Message-ID: <218efee071a248f7bac9691029419501@EX2.corp.digicert.com> References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> <501775b31e9a49ec962512b7aa48e3cd@EX2.corp.digicert.com> <256566a33bd642368f46cdb62dba4eee@EX2.corp.digicert.com> <1a797dfa-eb0d-f5df-9401-a6f1dfa4e1dc@cs.tcd.ie> In-Reply-To: <1a797dfa-eb0d-f5df-9401-a6f1dfa4e1dc@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01E8_01D234F9.A0E2B9C0" MIME-Version: 1.0 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 17:09:55 -0000 ------=_NextPart_000_01E8_01D234F9.A0E2B9C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable CRLs don't contain PII. It's just a serial number and status code. = That's a big difference than email address, names, locations, etc. -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Wednesday, November 2, 2016 10:50 AM To: Jeremy Rowley ; Peter Bowen = ; Melinda Shore Cc: trans@ietf.org Subject: Re: [Trans] Topicality On 02/11/16 16:20, Jeremy Rowley wrote: > Wacky court decisions are always a risk. However, the EU has > established that data collectors must delete public facing personal > information at the information holder's request.=20 I don't believe "delete" is right there - search engines gave different results when queried in different ways or from different places and the underlying sources (e.g. newspaper articles) weren't affected directly IIUC. While that is an evolving situation I'm not sure we can safely conclude what any of it might mean for CT. (Or for CRLs I guess if we want to get into speculation;-) S > There's a big > difference between planning for unknown legal changes and accounting > for decisions already made. By requiring logging of PII, we're > essentially asking logs to fail on a regular basis. Although > redaction of subject info doesn't guarantee a log won't fail because > of a right to be forgotten request, it does move logs in the > direction of compliance. >=20 > Jeremy >=20 > -----Original Message----- From: Stephen Farrell > [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, November 2, 2016 > 10:13 AM To: Jeremy Rowley ; Peter Bowen > ; Melinda Shore Cc: > trans@ietf.org Subject: Re: [Trans] Topicality >=20 >=20 >=20 > On 02/11/16 15:57, Jeremy Rowley wrote: >> Here's what we are dealing with on this front: >>=20 >> The EU has a right to be forgotten which requires a data >> controller to remove data that is no longer necessary or >> irrelevant for the original purposes for which the data was >> collected. Primarily, courts have interpreted this as requiring a >> search engine to remove information about a person at that >> individual=E2=80=99s request. This has caused consider headaches for >> Google. >>=20 >> CT monitors are likely considered a search engine that identify=20 >> certificates with personal information included. However, CT, by=20 >> design, cannot delete information from logs and any deletion will=20 >> cause the log to fail. This puts CT at odds with EU privacy laws >> as certificate subjects often contain individual information, >> email addresses specified in the SANs, and SANS DNS entries that >> identify an individual (albeit this is a stretch). >>=20 >> I'm having trouble reconciling how a monitoring service/log >> operator is supposed to comply with the EU requirements without >> supporting redaction. >=20 > What makes you think redaction would help? If anything from the entry > in the log correlates with the cert then some wacky court could > decide who knows what... Particularly with stuff like that so-called > right to be forgotten, I'm not clear that we can plan ahead and guess > what courts might or might not decide. (And IANAL of course:-) >=20 > S. >=20 > PS: As with the rest of this thread, the above is with no hats. >=20 >>=20 >> Jeremy >>=20 >>=20 >> -----Original Message----- From: Trans=20 >> [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Farrell Sent:=20 >> Monday, October 31, 2016 4:03 PM To: Peter Bowen >> ; Melinda Shore Cc: >> trans@ietf.org Subject: Re: [Trans] Topicality >>=20 >>=20 >> Peter, >>=20 >> On 31/10/16 19:01, Peter Bowen wrote: >>> On Mon, Oct 24, 2016 at 9:37 PM, Melinda Shore=20 >>> wrote: >>>> You may have seen the recent announcement from the Chrome team=20 >>>> that as of October 2017 certificates will need to comply with=20 >>>> Chrome's CT policy in order to be trusted. There was also an=20 >>>> invitation to discuss that on the trans mailing list. This is >>>> a reminder that mailing list discussions need to remain focused >>>> on the specifications being produced by the working group - >>>> that is to say, policies related to individual implementations >>>> are out of scope for the working group except to the extent >>>> that they bear on decisions related to our working group >>>> drafts. >>>=20 >>> Paul and Melinda, >>>=20 >>> Do you consider discussion of use cases for privacy to be >>> in-scope for this group or do you consider only the technical >>> implementation of privacy (e.g. section 4 of 6962-bis and the >>> redaction draft) to be in-scope? >>=20 >> (Wearing no IETF hat, but perhaps the hat of someone interested in=20 >> privacy...) >>=20 >> I do not believe that it makes sense for us to talk as if privacy >> was a concept that applies to corporate entities. >>=20 >> I do believe that your text above conflates privacy (a human >> concept) with corporate secrecy (a useful but different thing) in >> ways that are in the end damaging to both. (I further and even >> moreso believe that such conflation would be damaging to the IETF >> were we to slip into the bad practice of not calling out that >> terminological sloppiness.) >>=20 >> I totally get that redaction has utility for folks who need >> corporate secrecy on a temporary basis. I absolutely do not accept >> that that has any privacy aspect. >>=20 >> Can you call out the privacy aspect that applies to humans and >> that is a real part of the question related to support for >> redaction in CT? >>=20 >> Thanks, S. >>=20 >>=20 >>>=20 >>> Thanks, Peter >>>=20 >>> _______________________________________________ Trans mailing >>> list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans >>>=20 >>=20 >=20 >=20 >=20 > _______________________________________________ Trans mailing list=20 > Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans >=20 ------=_NextPart_000_01E8_01D234F9.A0E2B9C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMTAyMTcwOTQ5WjAj BgkqhkiG9w0BCQQxFgQUIDqxsBgI6MIxO4BsTPeSMhWFBsEwgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAEpzG7E+vJ1tqiBeenxPDdlA2bYb9Q+14bR2DODs NMikhljSU0ndw9HyDfBSt0VL4Ke+M8RnuTii85eDk78pmrWdSXcltSUH1+Td51LUhEsuLTiGFZWt SWNJ+bqonRovUH+IcUBeEvlWEGKQkemgY0n/UjKdaoGRMDKrOma9XQv5fzwzNYEM2TgiEvHLUlIA gPHnLcFUoDNOvCMl502AGRY+iFGkNNRL5FK+pCkzkG+U4P/B9nnuoDoShiTnjpIeZpvtC6ahviRQ +PSCrLzWHbMqlXKXNwYAACXh//RZMy9429vfkgrCx+EDLKjNRcnsUYWMQhmBOsesnxkm7TScqGkA AAAAAAA= ------=_NextPart_000_01E8_01D234F9.A0E2B9C0-- From nobody Wed Nov 2 10:12:32 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BB31296E5 for ; Wed, 2 Nov 2016 10:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ7u7hVHlD9X for ; Wed, 2 Nov 2016 10:12:29 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A511296E1 for ; Wed, 2 Nov 2016 10:12:28 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id t125so14565987ywc.1 for ; Wed, 02 Nov 2016 10:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EhSPX1DahGZhoBG9/RPCwMHImLx0C5hCXXXjp30xkU0=; b=0nQPZr4sdXYD76aV6Vh0mOIztHF4qnumQrZMlNYMaSns+mW+oOrsLXKDIvH1pG80AT ZFeYMn3W4M0j8pFYV7wscC19cNEAT/G8pA/Vl505TXUYDBvte6ven5s91qbaFWiaGzpM p7P2GvgjUr+w41JFz2mwDCIMttOT5/uxqxVgD8seyK0zyh7xBD3vlEd1l0PbWNO+bLwu GqzKZZWuiAXZbYNTQiZxkR9dWh10/dXp2HIZRKW6EeA0RKJuQTfq1dClqD1HOr0b3gws tXpIrgV0mN0dpqmVM7sunILH9/mM4EtnO3p8UT/ZEFcBV7UHg8+ri8SdJobF3vcr03dF 6VYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EhSPX1DahGZhoBG9/RPCwMHImLx0C5hCXXXjp30xkU0=; b=IFfCwSx4qaRSIesglIuS1SLxlMNrwqGJCIOh0VLk90HQxXF212AxkqUFao+OCT2RSY J5US3HBIU/KuCLbBVmWyNuEJfmHAZ701N+GWx+a8WpLE4cK8hz9vQswEtEZY3bfcn1Fi J2DysALVN7xmf5wd+XX1aJyZ41u1+/msoFDcGK+4rphIEsxWa6TbHoW6eq/LcsZNJAC3 B4pvh5q1YakhE7XTqp+9pkRXNBfZr+gop24GTvyYsOj/B6DjMt23WaRQIXIwGC4mJ6yP 8pn8aMKC+Jwp15rJ75aThCjtO/1ZRmJBKrh6CUeMxlL+UgXBUArCF+ZvmLbflugdD6eK 8OfA== X-Gm-Message-State: ABUngvcBAirbqbNYslWcnEnKJO2wdVMOzaPIrYQc8YN6cbYjXPTCvzJ2V3OqS1gE2/6u6kIAMt76r6QedKwhoA== X-Received: by 10.36.125.75 with SMTP id b72mr3366478itc.62.1478106748069; Wed, 02 Nov 2016 10:12:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.39.68 with HTTP; Wed, 2 Nov 2016 10:12:27 -0700 (PDT) In-Reply-To: References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> <501775b31e9a49ec962512b7aa48e3cd@EX2.corp.digicert.com> From: Peter Bowen Date: Wed, 2 Nov 2016 10:12:27 -0700 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Jeremy Rowley Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 17:12:31 -0000 On Wed, Nov 2, 2016 at 9:13 AM, Stephen Farrell wrote: > > > On 02/11/16 15:57, Jeremy Rowley wrote: >> Here's what we are dealing with on this front: >> >> The EU has a right to be forgotten which requires a data controller >> to remove data that is no longer necessary or irrelevant for the >> original purposes for which the data was collected. Primarily, courts >> have interpreted this as requiring a search engine to remove >> information about a person at that individual=E2=80=99s request. This ha= s >> caused consider headaches for Google. >> >> CT monitors are likely considered a search engine that identify >> certificates with personal information included. However, CT, by >> design, cannot delete information from logs and any deletion will >> cause the log to fail. This puts CT at odds with EU privacy laws as >> certificate subjects often contain individual information, email >> addresses specified in the SANs, and SANS DNS entries that identify >> an individual (albeit this is a stretch). >> >> I'm having trouble reconciling how a monitoring service/log operator >> is supposed to comply with the EU requirements without supporting >> redaction. > > What makes you think redaction would help? If anything from the > entry in the log correlates with the cert then some wacky court > could decide who knows what... Particularly with stuff like that > so-called right to be forgotten, I'm not clear that we can plan > ahead and guess what courts might or might not decide. (And IANAL > of course:-) Stephen, We don't need to plan for all eventualities, but I think it is reasonable to plan for cases that are predictable. Consider the following specific case: An individual ("Alex Bauer" as an example) who is a German citizen and resident registers a domain name (contosoedumakation.de) and gets a certificate with GN=3DAlex,SN=3DBauer in the subject and www.contosoedumakation.de as a dNSName type Subject Alternative Name. The certificate has a validity period of 90 days. Alex sells that domain name to someone else and ceases to have any involvement with the domain or new registrant. A year later, the new registrant sells it to someone else who starts to use it to host various content that Alex wants no association with. Alex files a request to remove any information associating Alex Bauer with contosoedumakation.de. What does a CT log operator do? Thanks, Peter From nobody Wed Nov 2 10:48:24 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBF8129597 for ; Wed, 2 Nov 2016 10:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe-cCye1_XIy for ; Wed, 2 Nov 2016 10:48:22 -0700 (PDT) Received: from mail.highwayman.com (happyday.demon.co.uk [80.177.121.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16011294BD for ; Wed, 2 Nov 2016 10:48:21 -0700 (PDT) Received: from localhost ([127.0.0.1]:58423 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.87) (envelope-from ) id 1c1ze5-000Fne-J4; Wed, 02 Nov 2016 17:48:17 +0000 Message-ID: Date: Wed, 2 Nov 2016 17:46:51 +0000 To: Jeremy Rowley From: Richard Clayton References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> <501775b31e9a49ec962512b7aa48e3cd@EX2.corp.digicert.com> <256566a33bd642368f46cdb62dba4eee@EX2.corp.digicert.com> In-Reply-To: <256566a33bd642368f46cdb62dba4eee@EX2.corp.digicert.com> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.03 M Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen , Stephen Farrell Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 17:48:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <256566a33bd642368f46cdb62dba4eee@EX2.corp.digicert.com>, Jeremy Rowley writes >Wacky court decisions are always a risk. However, the EU has established that >data collectors must delete public facing personal information at the >information holder's request. nope it says that the data processor must balance the rights of the data subject with the reason for doing the processing and the legitimate rights of the public to see the result of that processing after that balance has been done then it may well be (as in the Costeja case) that deletion is the correct thing to do. However, in many other cases the data can remain available (and indeed Google regularly rejects requests to remove search results). in this context one might also pay attention to Breyer v Deutschland (where the court held that dynamic IP addresses were capable of being personal data) because the judgment also observed that processing IP addresses in order to keep web servers secure was legitimate... viz: even though it's personal data you can still use it provided that your processing is appropriate IANAL (but I drink coffee with them regularly) - -- Dr Richard Clayton Director, Cambridge Cybercrime Centre mobile: +44 (0)7887 794090 Computer Laboratory, University of Cambridge, CB3 0FD tel: +44 (0)1223 763570 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBWBomizu8z1Kouez7EQKzKQCfXKSrK/BpEGbcYJswm27fBkFPLC4An3QB gOFqMnS8fbRVvUReB8cHigA/ =pvrt -----END PGP SIGNATURE----- From nobody Wed Nov 2 12:51:21 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA1A129872 for ; Wed, 2 Nov 2016 12:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_J3uZEHZjF3 for ; Wed, 2 Nov 2016 12:51:19 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43E512986F for ; Wed, 2 Nov 2016 12:51:19 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 602383C000747 for ; Wed, 2 Nov 2016 12:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=w88u6lICdOX7uB/03YkQ/hEVQdk=; b= MulExzVyV5V/C6m2oLLvuh52QcIbtdOwYRj0EDKfR91RgtqWgaSebfBLfy8pEziu s8kS5CfRU8i/LUIhQLhNyYc2ft1p9mP7A3zPH5xde2PSF0e5V7QbHWrDycHpT0WY 0gMUYVy8spIwSIKGTL00ztB3Foejsbk7UCFJeDwimmA= Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id 5359D3C000746 for ; Wed, 2 Nov 2016 12:51:19 -0700 (PDT) Received: by mail-oi0-f53.google.com with SMTP id 128so34579744oih.0 for ; Wed, 02 Nov 2016 12:51:19 -0700 (PDT) X-Gm-Message-State: ABUngvfGRXASpfcs0S9Kko+0MNuTEXw+Z6cDhFGE1JLSguwDhig/vqzxy4FtEaNrDoxPW17bJXzG1GDG7cCICg== X-Received: by 10.107.19.136 with SMTP id 8mr6752631iot.33.1478116278633; Wed, 02 Nov 2016 12:51:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.24.130 with HTTP; Wed, 2 Nov 2016 12:51:18 -0700 (PDT) In-Reply-To: References: <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> From: Ryan Sleevi Date: Wed, 2 Nov 2016 12:51:18 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Peter Bowen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 19:51:20 -0000 On Wed, Nov 2, 2016 at 7:08 AM, Peter Bowen wrote: > I realize that 6962bis has passed WGLC, so I know there is a high bar > for changes. However I think this might pass that bar. The highly > restrictive language that imposes minimum policy for logs prevents > interoperability with other IETF RFCs on the standards track very > hard. 6962bis appears to assume that DANE (RFCs 7671 and 6698) will > never be implemented and that concepts like RFC 6091 will never come > to fruition. To further expand on Peter's question regarding Section 5.1, as presently specified, it shifts a significant burden to log clients submitted certificates that might otherwise be addressed by log flexibility. Consider a CA which it itself a trust anchor (root cert) and has a certificate cross-signed by another trust anchor (cross-sign). One log may directly support the root, another log may only support the CA issuing of the cross-sign. One interpretation of the text is that "using the chain of intermediate CA certificates provided by the submitter" means that only the first log can be used, and that the second log cannot perform any path building to determine that the cross-sign exists. As such, a client submitting certs must have full knowledge of the PKI graph, prior to submission, to determine which logs it can use, and logs are prevented from using their knowledge. Another interpretation is that the chain of intermediates is merely a 'hint', and may be discarded by the log when evaluating the path. This would at least resolve some of Peter's concerns, but not all. The core of this is the question regarding the MUST level requirement, and whether that language unduly restricts possible implementations in a way that may prevent standards adoption. From nobody Wed Nov 2 13:08:48 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC63129469 for ; Wed, 2 Nov 2016 13:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hjs77LSf62Ip for ; Wed, 2 Nov 2016 13:08:45 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27FCD127076 for ; Wed, 2 Nov 2016 13:08:45 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id x4so35187783oix.2 for ; Wed, 02 Nov 2016 13:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xIfPkEEs/xET6BNZb/noW/rDOay4hz2ZJYmqw7N6Kns=; b=r8KyK1QMWV49mLemJvWVjIiPhrfBrJLiTvMjBlGMsFgDdXIlTLz7W+uIxyNoAzAJ9Q 0tmqIhkfJvtSySWFxPdaGdHCk0h6Gini2xOK1HMR+8+G0s72kgsBA7csqEIZqz0ryR6k CzszJvrWBzqwijtOdP7f9V7wsaKPdDV6XEbQgmVEdNZtPTvGq4h+gQvvKNW2SjnjGx1e K/T/sxrcnYXIcOcgWT6ruMX7DnNBJn4ffSdqUHkzdM/m0KB5Qi8w5ivOlGS5Zo/X+GjR y6g8JINCl/PUPJN85xi9/WWV8djfmtyMiwyctySULl4eIx6VMVIbQaIKoLcYwNYFRIAm yUAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xIfPkEEs/xET6BNZb/noW/rDOay4hz2ZJYmqw7N6Kns=; b=f1aGSsU5R63LwjpUIhySqbhgJoHbb6AO9OXX7VYDJBMhkwOpOASCLC/xQ19k9OYBr3 bBk0M3kl+Z3XEiBWvoDC9/0UP5W9pX2kt5PETqwWmYZuDBfi7zjOo09VohXKhLbv1L8L 0b+DBXE9sThZgRXwielj3ts6iAr6C/WSLjW+N+2PVpgm52FspBLkiD9vCoY903i3Ck16 geZfcEAb0Fx/FfPHKitRvMY739OUN3HK3jWnObQeIQHGjN1WwtH+SxM2QiM18AhMKesp tkX/AIUtCx0EwtqwpJ3/91cBjKSK/eRxWH0+gPe5J08A+nHbLm1YOtis5zMEfuOwHdpD QDFA== X-Gm-Message-State: ABUngvd5cQbA6rhK6OayL1jaqU52EN6UPRfRy5q0//ERf9UtjTB56gu1dpVGietWpjMSKGjj/HTsdnOVmx2cpA== X-Received: by 10.107.7.96 with SMTP id 93mr123863ioh.136.1478117324264; Wed, 02 Nov 2016 13:08:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.85.83 with HTTP; Wed, 2 Nov 2016 13:08:43 -0700 (PDT) In-Reply-To: References: From: Brian Smith Date: Wed, 2 Nov 2016 10:08:43 -1000 Message-ID: To: Peter Bowen Content-Type: multipart/alternative; boundary=001a113ec7d00cad4405405702ac Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 20:08:47 -0000 --001a113ec7d00cad4405405702ac Content-Type: text/plain; charset=UTF-8 Peter Bowen wrote: > Currently 6962bis section 5.1 says: > > "Logs MUST verify that each submitted certificate or precertificate > has a valid signature chain to an accepted trust anchor, using the > chain of intermediate CA certificates provided by the submitter. [...] > logs MUST reject submissions without a > valid signature chain to an accepted trust anchor. Logs MUST also > reject precertificates that do not conform to the requirements in > Section 3.2." > > Is there a reason this is enshrined as a MUST? It seems like it > should be up to the log operator to determine their policy. The log can reject the submission (return a non-2xx response) and still incorporate the certificate into the log, especially if it can build its own path to a trust anchor it trusts. The only thing that the log is prohibited from doing is giving the submitter a 200 response with an SCT when the submitter supplies an incomplete/untrusted chain. In particular, the log can reject a submission (with a non-2xx response) but then re-submit the same certificate to itself with a different certificate chain (returning a 2xx response). A log can store rejected submissions in a holding bin for later self-submission when new intermediates are discovered and/or new roots are trusted. Note that when people query the log using get-entries, the log shouldn't return certificates it has never been able to build a valid chain for, by default, I think. Otherwise the system doing the querying might be DoS'd with untrusted certificates. But, it is probably a good idea to have a way to query rejected/not-yet-trusted submissions too. Cheers, Brian -- https://briansmith.org/ --001a113ec7d00cad4405405702ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pete= r Bowen <pzbowen@gmail.com> wrote:
Currently 6962bis section 5.1 says:

=C2=A0 "Logs MUST verify that each submitted certificate or precertifi= cate
=C2=A0 =C2=A0has a valid signature chain to an accepted trust anchor, using= the
=C2=A0 =C2=A0chain of intermediate CA certificates provided by the submitte= r. [...]
=C2=A0 =C2=A0logs MUST reject submissions without a
=C2=A0 =C2=A0valid signature chain to an accepted trust anchor.=C2=A0 Logs = MUST also
=C2=A0 =C2=A0reject precertificates that do not conform to the requirements= in
=C2=A0 =C2=A0Section 3.2."

Is there a reason this is enshrined as a MUST?=C2=A0 It seems like it
should be up to the log operator to determine their policy.

The log can reject the submission (return a non-2xx respon= se) and still incorporate the certificate into the log, especially if it ca= n build its own path to a trust anchor it trusts. The only thing that the l= og is prohibited from doing is giving the submitter a 200 response with an = SCT when the submitter supplies an incomplete/untrusted chain.
In particular, the log can reject a submission (with a non-2xx= response) but then re-submit the same certificate to itself with a differe= nt certificate chain (returning a 2xx response).

A= log can store rejected submissions in a holding bin for later self-submiss= ion when new intermediates are discovered and/or new roots are trusted.

Note that when people query the log using=C2=A0get-entries, the log = shouldn't return certificates it has never been able to build a valid c= hain for, by default, I think. Otherwise the system doing the querying migh= t be DoS'd with untrusted certificates. But, it is probably a good idea= to have a way to query rejected/not-yet-trusted submissions too.

Cheers,
Brian
--
--001a113ec7d00cad4405405702ac-- From nobody Wed Nov 2 14:40:42 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A220129997 for ; Wed, 2 Nov 2016 14:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unHt1DR62GAo for ; Wed, 2 Nov 2016 14:40:39 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339BA129991 for ; Wed, 2 Nov 2016 14:40:38 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id 128so40332963oih.0 for ; Wed, 02 Nov 2016 14:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SuT8NOnXoaemvbxhZoLes+ZyqG6ksD+5N3tGYnqiexQ=; b=W5MyFAH3vxKeV/Y66E5jcaUee9AO/2A+g5VcaHC1EJaeVlw5ISHnOizxwvsFFqrNl+ DWF6Z+eKPUoE3uDVa7lhv1oCILnnB+fkBKdrFZkoEwNrNsOQFgzz2QZw8+1vtVb6cNKK OUBykbvrCc6zkpSrPPsk6xkjWlUt3zGiEu168QhVQW7borohKqKS6rYWwjKMZ9pwmmTR 8hTnLIpsKCywW3XV3cws+2mXJ5FDMGZwun69lNbiREP5GPoTvWvt55wnnQaL5RzJ7y+G 7Echn2+xI6Ziw40K6wObWv4MBq1DsMD3PPKfkR6Fj7EQC66QuJHSmgxRGxQbZj4yngBp SMDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SuT8NOnXoaemvbxhZoLes+ZyqG6ksD+5N3tGYnqiexQ=; b=K3HtS2k+oJPDpOJdTY4gASYYmBd07NQSCquk6MHKt2TI2W6diKKwmdRO6e6sEmW8V+ 4pRK6lmQSheA4L5OE/c9eJjJAAgHRXvoYQsRyz1YnuAlXyaFyyCxETDqM0FQCWNKxSGa kIhYsXrCYusr02xMtcGt45qxdOBuDBKIJG9iSOTf5t21JFcPFlDO2zz2/EgRwkkQeUxf vF3X3VPSPk3VgthbAKMG0k5ApOhGD2eJEXluu8C91ORRy84jkjRAJ7hsFLp4wxR7eceV XgAafI/Hsm86F7BsjiHqDTTWiUSjJKU2ahamKHSV+j3SamTa8bS/O4EP/mi6taYICatq J0xA== X-Gm-Message-State: ABUngveyORP41rll+5lk7+rnaQZf7Q5UM8SEf5R/HVLdrjO3a0wrEcN6CTV2FnH5XVgDUPYoutpQnRuOJxqHFg== X-Received: by 10.107.20.138 with SMTP id 132mr6114226iou.47.1478122838247; Wed, 02 Nov 2016 14:40:38 -0700 (PDT) MIME-Version: 1.0 References: <55796DF2.9050705@comodo.com> <557A0067.1060003@bbn.com> <557AAD15.8060001@comodo.com> <557B1834.8040706@bbn.com> <20161025103652.da027f9a7ebeb06eb42c358b@andrewayer.name> <618E8DBD-7C62-458B-9DD3-847029A26F38@umich.edu> <87fc2dbf2cdf4d378749e9d0a4a883a5@EX2.corp.digicert.com> In-Reply-To: <87fc2dbf2cdf4d378749e9d0a4a883a5@EX2.corp.digicert.com> From: Clint Wilson Date: Wed, 02 Nov 2016 21:40:26 +0000 Message-ID: To: Jeremy Rowley , Zakir Durumeric , Andrew Ayer Content-Type: multipart/alternative; boundary=001a114fa990b54fab0540584ad1 Archived-At: Cc: Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] Log Monitoring API X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 21:40:41 -0000 --001a114fa990b54fab0540584ad1 Content-Type: text/plain; charset=UTF-8 We're very excited to see this discussed and looking forward to participating. On Wed, Nov 2, 2016 at 10:05 AM Jeremy Rowley wrote: > We're happy to be involved. Clint Wilson will be contributing from our > side. > > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Zakir Durumeric > Sent: Thursday, October 27, 2016 8:49 AM > To: Andrew Ayer > Cc: Rob Stradling ; trans@ietf.org > Subject: Re: [Trans] Log Monitoring API > > I would be happy to be involved, and the Censys Project would be interested > in implementing an agreed API as part of its CT monitoring. > > Zakir > > > On Oct 25, 2016, at 12:36 PM, Andrew Ayer wrote: > > > > On Thu, 6 Oct 2016 16:21:59 +0100 > > Rob Stradling wrote: > > > >> Now we've completed WGLC for 6962-bis, I'd like to pick this thread > >> back up again. > >> > >> Several different public CT monitoring services now exist (crt.sh, > >> Cert Spotter, Censys.io, etc). ISTM that it would be useful to > >> define a common API that could be implemented by each monitor, so > >> that end-users don't have to implement multiple APIs in order to talk > >> to multiple monitors. > >> > >> Matt Palmer and I made a start on a (very drafty) draft a while ago: > >> https://github.com/tobermorytech/ct-monitor-api-rfc/blob/master/draft > >> -palmer-ct-monitor-api.md > >> > >> Who's interested in working on this? > > > > Count me in. > > > > Regards, > > Andrew > > > > _______________________________________________ > > Trans mailing list > > Trans@ietf.org > > https://www.ietf.org/mailman/listinfo/trans > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a114fa990b54fab0540584ad1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We're very excited to see this discussed and looking f= orward to participating.

On Wed, Nov 2, 2016 at 10:05 AM Jeremy Rowley <jeremy.rowley@digicert.com> wrote:
=
We're happy to be involved. Clint Wilson= will be contributing from our side.

-----Original Message-----
From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Zakir Dur= umeric
Sent: Thursday, October 27, 2016 8:49 AM
To: Andrew Ayer <agwa@andrewayer.name>
Cc: Rob Stradling <rob.stradling@comodo.com>; trans@ietf.org<= /a>
Subject: Re: [Trans] Log Monitoring API

I would be happy to be involved, and the Censys Project would be interested=
in implementing an agreed API as part of its CT monitoring.

Zakir

> On Oct 25, 2016, at 12:36 PM, Andrew Ayer <agwa@andrewayer.name<= /a>> wrote:
>
> On Thu, 6 Oct 2016 16:21:59 +0100
> Rob Stradling <rob.stradling@comodo.com> wrote:
>
>> Now we've completed WGLC for 6962-bis, I'd like to pick th= is thread
>> back up again.
>>
>> Several different public CT monitoring services now exist (crt.sh,=
>> Cert Spotter, Censys.io, etc).=C2=A0 ISTM that it would be useful = to
>> define a common API that could be implemented by each monitor, so<= br class=3D"gmail_msg"> >> that end-users don't have to implement multiple APIs in order = to talk
>> to multiple monitors.
>>
>> Matt Palmer and I made a start on a (very drafty) draft a while ag= o:
>> ht= tps://github.com/tobermorytech/ct-monitor-api-rfc/blob/master/draft
>> -palmer-ct-monitor-api.md
>>
>> Who's interested in working on this?
>
> Count me in.
>
> Regards,
> Andrew
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/trans
>

_______________________________________________
Trans mailing list
Tra= ns@ietf.org
https://www.ietf.org/mailman/listinfo= /trans
_______________________________________________
Trans mailing list
Tra= ns@ietf.org
https://www.ietf.org/mailman/listinfo= /trans
--001a114fa990b54fab0540584ad1-- From nobody Wed Nov 2 15:40:51 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EC012955D for ; Wed, 2 Nov 2016 15:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBNBSZ8cXqmh for ; Wed, 2 Nov 2016 15:40:46 -0700 (PDT) Received: from mail.hezmatt.org (minotaur.hezmatt.org [IPv6:2a01:4f8:121:3431:e2e4:22bb:25f5:6cad]) by ietfa.amsl.com (Postfix) with ESMTP id 84F1C12955C for ; Wed, 2 Nov 2016 15:40:46 -0700 (PDT) Received: from mistress.home.hezmatt.org (2001-44b8-510e-8600-fc7c-a44f-ae12-74e1.static.ipv6.internode.on.net [IPv6:2001:44b8:510e:8600:fc7c:a44f:ae12:74e1]) by mail.hezmatt.org (Postfix) with ESMTPSA id 5AAAEA2A64 for ; Wed, 2 Nov 2016 22:40:43 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id B97F5A0158; Thu, 3 Nov 2016 09:40:36 +1100 (AEDT) Date: Thu, 3 Nov 2016 09:40:36 +1100 From: Matt Palmer To: "trans@ietf.org" Message-ID: <20161102224036.GD8852@hezmatt.org> References: <55796DF2.9050705@comodo.com> <557A0067.1060003@bbn.com> <557AAD15.8060001@comodo.com> <557B1834.8040706@bbn.com> <20161025103652.da027f9a7ebeb06eb42c358b@andrewayer.name> <618E8DBD-7C62-458B-9DD3-847029A26F38@umich.edu> <87fc2dbf2cdf4d378749e9d0a4a883a5@EX2.corp.digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Log Monitoring API X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 22:40:49 -0000 Great to see there's a broad set of people looking to work on this. What I'd like to do first up is to try and get as broad a range of use cases as possible enumerated and defined. There's currently a set of actors and use cases in the draft document (https://github.com/tobermorytech/ct-monitor-api-rfc/blob/master/draft-palmer-ct-monitor-api.md, section "Desired Features"). If anyone has any use cases not covered already, or if you think any existing use case needs to be expanded, please drop a PR or raise it here. - Matt On Wed, Nov 02, 2016 at 09:40:26PM +0000, Clint Wilson wrote: > We're very excited to see this discussed and looking forward to > participating. > > On Wed, Nov 2, 2016 at 10:05 AM Jeremy Rowley > wrote: > > > We're happy to be involved. Clint Wilson will be contributing from our > > side. > > > > -----Original Message----- > > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Zakir Durumeric > > Sent: Thursday, October 27, 2016 8:49 AM > > To: Andrew Ayer > > Cc: Rob Stradling ; trans@ietf.org > > Subject: Re: [Trans] Log Monitoring API > > > > I would be happy to be involved, and the Censys Project would be interested > > in implementing an agreed API as part of its CT monitoring. > > > > Zakir > > > > > On Oct 25, 2016, at 12:36 PM, Andrew Ayer wrote: > > > > > > On Thu, 6 Oct 2016 16:21:59 +0100 > > > Rob Stradling wrote: > > > > > >> Now we've completed WGLC for 6962-bis, I'd like to pick this thread > > >> back up again. > > >> > > >> Several different public CT monitoring services now exist (crt.sh, > > >> Cert Spotter, Censys.io, etc). ISTM that it would be useful to > > >> define a common API that could be implemented by each monitor, so > > >> that end-users don't have to implement multiple APIs in order to talk > > >> to multiple monitors. > > >> > > >> Matt Palmer and I made a start on a (very drafty) draft a while ago: > > >> https://github.com/tobermorytech/ct-monitor-api-rfc/blob/master/draft > > >> -palmer-ct-monitor-api.md > > >> > > >> Who's interested in working on this? > > > > > > Count me in. > > > > > > Regards, > > > Andrew > > > > > > _______________________________________________ > > > Trans mailing list > > > Trans@ietf.org > > > https://www.ietf.org/mailman/listinfo/trans > > > > > > > _______________________________________________ > > Trans mailing list > > Trans@ietf.org > > https://www.ietf.org/mailman/listinfo/trans > > _______________________________________________ > > Trans mailing list > > Trans@ietf.org > > https://www.ietf.org/mailman/listinfo/trans > > > -- > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans -- Java/XML are the hammer and the Internet is the thumb. -- rone, in a place that does not exist From nobody Wed Nov 2 18:30:01 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2291297AA for ; Wed, 2 Nov 2016 18:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6jDQCHoppEe for ; Wed, 2 Nov 2016 18:29:58 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BFBD1294F8 for ; Wed, 2 Nov 2016 18:29:58 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id 62so52575124oif.1 for ; Wed, 02 Nov 2016 18:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5zZqb/6XBMgtdtLkUYrnbtZm/pb3ehVmLKksq2OJwUM=; b=C0Y0RHxTuzBjSustPcArVV6ollvGEvbOpST0jdJ9QZFlek3P5W9KglWJCPdMW+y3TS WJ0kKrD3pzBLXSJheMHRcDeOTMpSv1ovdEh7UQmeBCRcBkvmdpTJMuI/HfIgWVAAh86A WbtbN8YJHreaxgzA01XwKBWFnzyVXgl48ooiQSk8+V9+elGxwg1xTX1M+/euueqbPZQe A8e4I50kaFgnnbZCXU1NzQy3ScJ4EtsTCTlHEMirGBUpLlIVzbVEtcKhY5ebrXkC+g99 GfA7D0vskGq30DtHo3Ytca8P/MYAgyMX7KW4rtkcKsRa7wLjUat6AnSwrDHlmZPdTYd4 KNQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5zZqb/6XBMgtdtLkUYrnbtZm/pb3ehVmLKksq2OJwUM=; b=lERrxyXRDk0k7Sfeq4WBDEaGhZNgThuqSBMq3mGU5VyRTZ/ggc7mkqwW3xyJU2K+rS Gtw09Nya7sESGKyfYraW+wQhxp0UYGgl5joL1LIbCc+j8TgnOxYjWBWoEH96jFd77W73 Pxl9GgwHTqiBFwkIZAWd6mCbkPbHIA7yv4eINZI3OcMgWL3dKcZd+KXNzBKsmOkn4CZT HdqnnZiuZw/iYYy9+r1eia52yetw+p49NYPc49zHNekeTL9Yw/dJQXsdZE/BmzSN+qDL UCjmIomnDSsj9O79J/tjRcB437sn+ls9OV6vXQR6DQ4XYe0oqbScEQ0+LhrgJUgx9kZW rUjw== X-Gm-Message-State: ABUngvc5jdyDF9os9G6ED+b8sDCXaAvd8ODlul9v8oVfo1xDZeixSI++HMasKcD+aclCfIYWu5gQrs6WzwawpA== X-Received: by 10.107.184.214 with SMTP id i205mr6660827iof.167.1478136597994; Wed, 02 Nov 2016 18:29:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.39.68 with HTTP; Wed, 2 Nov 2016 18:29:57 -0700 (PDT) In-Reply-To: References: From: Peter Bowen Date: Wed, 2 Nov 2016 18:29:57 -0700 Message-ID: To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 01:30:00 -0000 On Wed, Nov 2, 2016 at 1:08 PM, Brian Smith wrote: > Peter Bowen wrote: >> >> Currently 6962bis section 5.1 says: >> >> "Logs MUST verify that each submitted certificate or precertificate >> has a valid signature chain to an accepted trust anchor, using the >> chain of intermediate CA certificates provided by the submitter. [...] >> logs MUST reject submissions without a >> valid signature chain to an accepted trust anchor. Logs MUST also >> reject precertificates that do not conform to the requirements in >> Section 3.2." >> >> Is there a reason this is enshrined as a MUST? It seems like it >> should be up to the log operator to determine their policy. > > > The log can reject the submission (return a non-2xx response) and still > incorporate the certificate into the log, especially if it can build its own > path to a trust anchor it trusts. The only thing that the log is prohibited > from doing is giving the submitter a 200 response with an SCT when the > submitter supplies an incomplete/untrusted chain. Right, but why? If the log can fix it up on the fly, why not return a SCT? Why can a log not include a certificate it finds acceptable even if it can't link it back to a root? Why should a log have a separate store of certs for "future submission" instead of logging them directly? I see the worry about spam, but this would seem to be a greater risk for the log operator than anyone else. After all the log has to store all the data and transfer it to all the clients, so their bandwidth usage is far greater than any given client. Thanks, Peter From nobody Thu Nov 3 02:35:04 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE692129412 for ; Thu, 3 Nov 2016 02:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tHLSJsrsutt for ; Thu, 3 Nov 2016 02:35:01 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF41129490 for ; Thu, 3 Nov 2016 02:35:00 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id p190so320195154wmp.1 for ; Thu, 03 Nov 2016 02:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vuHHcMZ0xWXrqff9P/NXbAuEM+Ob8bAmwJBnSeNKG40=; b=MCNKK4WLWqD6ARSbgJuJKGvNJDTBK6DsTGiPXstL1/tIpf57ZI2MWtjN9VpoNQEQOh zcD0D+5ENBL8E73nNNrtrYRp0DWKuckWHZBtXBxmXeY1by/IBO4fUMa32yKSXzBwHTSc /ucQtzSDfLTXAyqfFF4lZeuSSZvtcQtbAzRsUfMPiReBM5w0SQGDiKuLJHCSRKFlZzpH ikXzJh5uOehU2MdwRbd5nIhfWfTNnu1/V0Ktq6q10YJ8PQshUd766gcEfmK1Hh0BKmwB sqVTjEH5VOgW/nuAJIDG6C8T3sygXeFkdA2fnP7kd9lbg2oRZqIkL7bQJ4vtOalAGEE0 pSDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vuHHcMZ0xWXrqff9P/NXbAuEM+Ob8bAmwJBnSeNKG40=; b=fJ4JoAbxXHwyzfO1VPvU4lp+SACAlaBDCkUBevipoSrU6kG4GKp8zFzSoWXDUPK5Si jXPswRLlSFsQAHVOEFy0/utaQ8DdIbq4mVh8OSXc5LxUCRX/o1ZolF8EGJjH5HdtqXtM Z/onxScuxAO4L2TXs0cxcZuIiWHpZJ4EJ29yL4sOx0Up2go3Ha5oktE3a3A7AUgCO81x v2VfqKwxqHVbf7aorfd2lmAQAzf46GeGj5flBExV1TQJkO7tzLAb0RMW8Eqo3Ib3t4e2 qmPHyQa6sSHcr0UhqxaqLlnlSr8eNYM546dJLc7o/UWMkXTAV7VhGnyeqLKB9su32EcI 5GNw== X-Gm-Message-State: ABUngvfYMe7xysmVNMFK6r8GJ8EK0g1IsrhOzEyXHp8sDj+gzHEdwOI0MsOabXeVzoYk26Pw/4qZvOc7u3fsuVMY X-Received: by 10.28.49.85 with SMTP id x82mr1004426wmx.129.1478165699219; Thu, 03 Nov 2016 02:34:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.31.21 with HTTP; Thu, 3 Nov 2016 02:34:58 -0700 (PDT) In-Reply-To: References: From: Eran Messeri Date: Thu, 3 Nov 2016 09:34:58 +0000 Message-ID: To: Peter Bowen Content-Type: multipart/alternative; boundary=001a1142dd786c3c4505406245e6 Archived-At: Cc: "trans@ietf.org" , Brian Smith Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 09:35:03 -0000 --001a1142dd786c3c4505406245e6 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 3, 2016 at 1:29 AM, Peter Bowen wrote: > On Wed, Nov 2, 2016 at 1:08 PM, Brian Smith wrote: > > Peter Bowen wrote: > >> > >> Currently 6962bis section 5.1 says: > >> > >> "Logs MUST verify that each submitted certificate or precertificate > >> has a valid signature chain to an accepted trust anchor, using the > >> chain of intermediate CA certificates provided by the submitter. > [...] > >> logs MUST reject submissions without a > >> valid signature chain to an accepted trust anchor. Logs MUST also > >> reject precertificates that do not conform to the requirements in > >> Section 3.2." > >> > >> Is there a reason this is enshrined as a MUST? It seems like it > >> should be up to the log operator to determine their policy. > > > > > > The log can reject the submission (return a non-2xx response) and still > > incorporate the certificate into the log, especially if it can build its > own > > path to a trust anchor it trusts. The only thing that the log is > prohibited > > from doing is giving the submitter a 200 response with an SCT when the > > submitter supplies an incomplete/untrusted chain. > > Right, but why? If the log can fix it up on the fly, why not return a > SCT? Why can a log not include a certificate it finds acceptable even > if it can't link it back to a root? Why should a log have a separate > store of certs for "future submission" instead of logging them > directly? > My answer to those is protocol simplicity: 6962-bis specifies the minimum necessary to build CT logs servers and protocol for clients such that Certificate Transparency can be implemented. I actually like the idea of a ct-log-like service that would take partial submissions and fix them and would be happy to help specifying such a service. The CT team here has some open-source code for fixing chains on which such a service could be based. Such a service (when not constrained by the CT log interface) could be expanded to return multiple valid chains, for example. (It could be combined with a proxy submission service - a log-like interface that takes an add-chain/add-pre-chain submissions and submits them in parallel to multiple log servers, returning the SCTList/TransItemList to be embedded in the final certificate or served alongside it). My point is that I see the value in automatically fixing submissions and would happy to collaborate on specifying/building such a service, simply pointing out it could exist independently of the log specification in 6962-bis. > I see the worry about spam, but this would seem to be a greater risk > for the log operator than anyone else. After all the log has to store > all the data and transfer it to all the clients, so their bandwidth > usage is far greater than any given client. > > Thanks, > Peter > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a1142dd786c3c4505406245e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 3, 2016 at 1:29 AM, Peter Bowen <pzbowen@gmail.com>= wrote:
On Wed, N= ov 2, 2016 at 1:08 PM, Brian Smith <brian@briansmith.org> wrote:
> Peter Bowen <pzbowen@gmail.com= > wrote:
>>
>> Currently 6962bis section 5.1 says:
>>
>>=C2=A0 =C2=A0"Logs MUST verify that each submitted certificate= or precertificate
>>=C2=A0 =C2=A0 has a valid signature chain to an accepted trust anch= or, using the
>>=C2=A0 =C2=A0 chain of intermediate CA certificates provided by the= submitter. [...]
>>=C2=A0 =C2=A0 logs MUST reject submissions without a
>>=C2=A0 =C2=A0 valid signature chain to an accepted trust anchor.=C2= =A0 Logs MUST also
>>=C2=A0 =C2=A0 reject precertificates that do not conform to the req= uirements in
>>=C2=A0 =C2=A0 Section 3.2."
>>
>> Is there a reason this is enshrined as a MUST?=C2=A0 It seems like= it
>> should be up to the log operator to determine their policy.
>
>
> The log can reject the submission (return a non-2xx response) and stil= l
> incorporate the certificate into the log, especially if it can build i= ts own
> path to a trust anchor it trusts. The only thing that the log is prohi= bited
> from doing is giving the submitter a 200 response with an SCT when the=
> submitter supplies an incomplete/untrusted chain.

Right, but why?=C2=A0 If the log can fix it up on the fly, why not r= eturn a
SCT?=C2=A0 Why can a log not include a certificate it finds acceptable even=
if it can't link it back to a root?=C2=A0 Why should a log have a separ= ate
store of certs for "future submission" instead of logging them directly?
My answer to those is protocol simplicity: = =C2=A06962-bis specifies the minimum necessary to build CT logs servers and= protocol for clients such that Certificate Transparency can be implemented= .

I actually like the idea of a ct-log-like servic= e that would take partial submissions and fix them and would be happy to he= lp specifying such a service. The CT team here has some open-source=C2=A0code for fixing chains=C2=A0on which such a service could be = based. Such a service (when not constrained by the CT log interface) could = be expanded to return multiple valid chains, for example.

(It could be combined with a proxy submission service - a log-like = interface that takes an add-chain/add-pre-chain submissions and submits the= m in parallel to multiple log servers, returning the SCTList/TransItemList = to be embedded in the final certificate or served alongside it).
=
My point is that I see the value in automatically fixing sub= missions and would happy to collaborate on specifying/building such a servi= ce, simply pointing out it could exist independently of the log specificati= on in 6962-bis.


I see the worry about spam, but this would seem to be a greater risk
for the log operator than anyone else.=C2=A0 After all the log has to store=
all the data and transfer it to all the clients, so their bandwidth
usage is far greater than any given client.

Thanks,
Peter

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

--001a1142dd786c3c4505406245e6-- From nobody Thu Nov 3 03:29:09 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C774A1294D2 for ; Thu, 3 Nov 2016 03:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkU-62qbvGWP for ; Thu, 3 Nov 2016 03:29:05 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F87129849 for ; Thu, 3 Nov 2016 03:28:59 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id 51so35235136uai.1 for ; Thu, 03 Nov 2016 03:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dw/1bYbMT1jO8JiPoLeeBJvTCYogvNYRBla3Qsg7b8A=; b=n3aVskpWOIeZaTsExux2ts9zMQnQesjUBCBCNxc1E4iTBGq8nDUijHJq0ot2fx5rPy o/mAN4ptgHtpk5vcZnMjBaXG/jhy42TT0FKTtjrr9lYJJegKvrEsCUXAIKn6r6wihqOG KvigvMBN1HvbBRBkkVf11SJeVtrFeDRcuBW5QDnqDtXfrfDbR1EITLo/Xhq/8iNQ27KG D07/o7Gz2t+zBAZfs9xPsEv19M4cl8TbRvsWDH/ekoY1bM4Bpcikg+LFFZFYtgO98a1l KUrylgBDjajLfG+JOIpjkUr0D4HPs57qttL/H+x+LowRRyX7GG00U+SBpKfGto6RWBz8 PdMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dw/1bYbMT1jO8JiPoLeeBJvTCYogvNYRBla3Qsg7b8A=; b=iZxdgZGpINUUAPsEVBSbv8kQivXVb1b5NzWEyuZ5mF+udDyHYGhDIqsfGzWlur/dWD nMXm4AqHtlYiF+mYRAwlZR6Tf+nhlLxsJR4gNUTNlTll2quhG5eGUWKIcuvM/92sBkWS /Y6sqFCNPEAfEHnGlvBgBbyVfSNgyJlmFwKaM3gJ/eumJoZ0o5a9DqfrA4538ul8oCB5 pCNkuEvYp5+ye1kiZood8XQ2xEBUyVLcEQWWyGDge6te6LBostcOsIKZ5PrvmUgkGNZz zK6vFDCfdfY91jRypSolccsyM/+o3bZneZJG3uwaZBl+1dnq80y6dBC6MQk0jDSkFrtI mrjA== X-Gm-Message-State: ABUngvd6JpiCZO/Mv4b34/TZH6yJjJVexwCDuTIYe7mN39srf4gpgRJSgyZe2Q9GDmEydNiYdWusAA16dou5v+ob X-Received: by 10.176.66.131 with SMTP id j3mr5790791uaj.151.1478168938145; Thu, 03 Nov 2016 03:28:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.149.203 with HTTP; Thu, 3 Nov 2016 03:28:57 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Thu, 3 Nov 2016 10:28:57 +0000 Message-ID: To: Peter Bowen Content-Type: multipart/alternative; boundary=001a114cb0d27a2887054063062a Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 10:29:08 -0000 --001a114cb0d27a2887054063062a Content-Type: text/plain; charset=UTF-8 On 2 November 2016 at 02:19, Peter Bowen wrote: > Currently 6962bis section 5.1 says: > > "Logs MUST verify that each submitted certificate or precertificate > has a valid signature chain to an accepted trust anchor, using the > chain of intermediate CA certificates provided by the submitter. [...] > logs MUST reject submissions without a > valid signature chain to an accepted trust anchor. Logs MUST also > reject precertificates that do not conform to the requirements in > Section 3.2." > > Is there a reason this is enshrined as a MUST? It seems like it > should be up to the log operator to determine their policy. For > example, a log operator might want to add a feature to accept > certificates which have incomplete chains and have the log add the > missing links from data it already has or a log operator may want to > allow logging of certificates that are also published for DANE with > TLSA records with certificate usage 2 or 3. It feels very restrictive > to require that every log only accept certificates that follow the > traditional hierarchical PKI model. > > I can see value in providing guidance of what a log MAY want to do. > However requiring such seems to limit the potential of transparency in > undesirable ways. > The problem this was designed to address was that a) knowing of a bad certificate is not all that useful unless you also know who issued it, b) without chaining to some responsible party, it is unclear how to prevent DoS on the log by filling it with nonsense certificates. Technically, I guess, the requirement could be that what is _logged_ MUST blah blah, but then that leaves open the question of how to construct such a chain (which is not standardised). In any case, it seems to me that if a log operator wanted to offer a service to construct chains, it would be trivial to have a different end-point that would accept partial chains, attempt to fix them, then submit them to the log. Also, we do provide code for repairing chains: https://github.com/google/certificate-transparency/tree/master/go/fixchain. Which fixes your first case. The second case sounds more like a job for DNSSEC Transparency... > > Thanks, > Peter > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a114cb0d27a2887054063062a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 2 November 2016 at 02:19, Peter Bowen <pzbowen@gmail.com> wrote:
Currently= 6962bis section 5.1 says:

=C2=A0 "Logs MUST verify that each submitted certificate or precertifi= cate
=C2=A0 =C2=A0has a valid signature chain to an accepted trust anchor, using= the
=C2=A0 =C2=A0chain of intermediate CA certificates provided by the submitte= r. [...]
=C2=A0 =C2=A0logs MUST reject submissions without a
=C2=A0 =C2=A0valid signature chain to an accepted trust anchor.=C2=A0 Logs = MUST also
=C2=A0 =C2=A0reject precertificates that do not conform to the requirements= in
=C2=A0 =C2=A0Section 3.2."

Is there a reason this is enshrined as a MUST?=C2=A0 It seems like it
should be up to the log operator to determine their policy.=C2=A0 For
example, a log operator might want to add a feature to accept
certificates which have incomplete chains and have the log add the
missing links from data it already has or a log operator may want to
allow logging of certificates that are also published for DANE with
TLSA records with certificate usage 2 or 3.=C2=A0 It feels very restrictive=
to require that every log only accept certificates that follow the
traditional hierarchical PKI model.

I can see value in providing guidance of what a log MAY want to do.
However requiring such seems to limit the potential of transparency in
undesirable ways.

The problem this was = designed to address was that a) knowing of a bad certificate is not all tha= t useful unless you also know who issued it, b) without chaining to some re= sponsible party, it is unclear how to prevent DoS on the log by filling it = with nonsense certificates.

Technically, I guess, = the requirement could be that what is _logged_ MUST blah blah, but then tha= t leaves open the question of how to construct such a chain (which is not s= tandardised).

In any case, it seems to me that if = a log operator wanted to offer a service to construct chains, it would be t= rivial to have a different end-point that would accept partial chains, atte= mpt to fix them, then submit them to the log.

Also= , we do provide code for repairing chains:=C2=A0https://github.= com/google/certificate-transparency/tree/master/go/fixchain.
=
Which fixes your first case. The second case sounds more lik= e a job for DNSSEC Transparency...

=C2=A0

Thanks,
Peter

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

--001a114cb0d27a2887054063062a-- From nobody Thu Nov 3 03:31:55 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232621294EC for ; Thu, 3 Nov 2016 03:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j03heHWJX_dJ for ; Thu, 3 Nov 2016 03:31:52 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC53129650 for ; Thu, 3 Nov 2016 03:31:52 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id w194so35637532vkw.2 for ; Thu, 03 Nov 2016 03:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EfN8jccoQ549rPRnoxl/sLNI0fX1VYTTmcnP5DCclPs=; b=Jv5rQYTXFVMLPnT8nXUmDs9QIcZX/LpXJdDeOsyDDBYcaG+LnRjWFZ/PzNjGMJdbU3 kwXp2KYm/RxoJlQrTiMIeNgSFjACthTXsM5Qxln5s0xeXrz5QdMdZAvbNE9JqovfB3vi T/C5oAuSlnn32Vl4ADF6j5NNdHxpPfAyXHJUMY0edqvXWlfjrLv7FN2yYMZ171H70lrT VAd6Xnda6dF3C7qvq3f894yULHV7tqDM76XwpABqx0oTh+YqKGMHdkUSO/3t2GYzljWz TjKlI4gVmTbygDf8iPrO0jp/YimJFZNvwaYS3vmucDk8uzFrHpkgtlTtNS6ZsRJDEkCd D4sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EfN8jccoQ549rPRnoxl/sLNI0fX1VYTTmcnP5DCclPs=; b=O48FfYJ0mL2qvgBJMnad0R/3LET35Z24Twtmpf8IhIbhgwWMjDtS+h8UbiyODYLM6X XvRwXSeiWMZGv6v7W3tCZ1ApIo2g+b2xFjiWUfJfE7cm0yYS3vOWt99MVBlrcSLFtdkG /TEhk4QbSDI3Ta4hgQMz6z4XHQFaFEah3BzMeYsfmkzEaVfAkhhoUghggkiDVZvO/EuM N3ytF6gJg07/OV/atUjO/e+au2efQy/hmK4p6FFzWFuOPwUfDSTomiqreU899AXDqtnk rQHUDQZc0QWbWpZaZca1+qKZdhOTEfD/BtlEC+9QSGRkjKHkX0XVSbC7T0KzJMNNdUeW BDkQ== X-Gm-Message-State: ABUngvffIKFB0HlFyWBAdjn3+9sI8vl9pspc0PV8CxZB1vN/pmdkAWYYi+Jmf+8qHPrE/WI6WyooslAdxCC4UfeS X-Received: by 10.31.99.193 with SMTP id x184mr6569144vkb.161.1478169111342; Thu, 03 Nov 2016 03:31:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.149.203 with HTTP; Thu, 3 Nov 2016 03:31:50 -0700 (PDT) In-Reply-To: References: <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> From: Ben Laurie Date: Thu, 3 Nov 2016 10:31:50 +0000 Message-ID: To: Peter Bowen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 10:31:54 -0000 On 2 November 2016 at 14:08, Peter Bowen wrote: > > By requiring all logs MUST accept any certificate that chains to a > root in the log's root list, 6962bis fails to allow log operators to > mitigate any Denial of Service attacks mounted by attempting to log > massive numbers of certificates that are not relevant to the log > scope. For example, many existing certification authorities issue > both server authentication certificates and certificates for personal > identification. For some roots, acquiring large numbers of these is > relatively easy (see discussion of fetching millions of Taiwanese > Citizen Digital Certificates in > https://smartfacts.cr.yp.to/smartfacts-20130916.pdf). As written > today, a log MUST accept these. There is no option for a log to > require that all certificates must meet some usability criteria. The requirement is to reject certs that don't meet the criteria, not to accept those that do. From nobody Thu Nov 3 03:33:53 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07E312949F for ; Thu, 3 Nov 2016 03:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuUxkC8zucUn for ; Thu, 3 Nov 2016 03:33:49 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4008F129420 for ; Thu, 3 Nov 2016 03:33:49 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id d65so35943974vkg.0 for ; Thu, 03 Nov 2016 03:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XQRPiLYj4q+ikdzOU2VqkW3CS66OyMSFkJ180dfQUO0=; b=CdwhMVjfVvNttPA5DVbOoJZ1H7pVqaOKN41LQo8cEGK5ah1p4F4uvjQfHnwdDBRIqc aKdHAMRRl1QT1rvWexHQr6ftyVJRdMtMmfzsDThAlSnvZab3OWevwynFkXaHuNv1m7KY fakVH4Ewpmf3kZRY3Cgar8UN8tF8bRfqoACZFgahj6ltsnRaIewiz+CWY1fIE9pP3qbQ iFb0v/LRaAQUv5ac7ya+DRw2Ir7KeCaeRdXGmbLYnfjEmY/uNRtMO5gKGxgDAwYczzFH 3K9FK9vijw0PGhG2uGbnkin/HxCA4wihAiIqPsQE3AlTiHMTy14JbQpmAbj6M2ZQ/l6T i8lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XQRPiLYj4q+ikdzOU2VqkW3CS66OyMSFkJ180dfQUO0=; b=eMqevfF50paLpmGZb1goCGZrQbuS36xjXPwkfhDu2Ya000zbcWMMVhdbAe0H1JlO03 aY9NUxsEIcZLF+2cuMrv3d4kXpE2hRrup9eY/w7/91UYFARnF8Jfrgs0FBJ70N1FyFg2 Nh/9aILhoJJ7KRdEOcgyeNCVeouPUCj+H75c/7zyg2F0slhlvO58Zj6z+WFk4Qh4Dcox WuxHxFq238FYim0oxd1UU+UzvCcpZLfCffOAIUtjlVdJsnFgho4tK7zyXuShF06zssDh 3gpywbc4nerZ2ZBToQl0nF5RpQGYQ6PbLWzu1P912l1dvspxkKH0CrEIkDT18u/k2p/a fjig== X-Gm-Message-State: ABUngvfiGudaIor8iyaJuosK0YTmtWRFr+1b40ma8rh/VPmPbNXM30o51o3FUOYFaSou2ZUFT89g+9BbwMkFi0cf X-Received: by 10.31.130.20 with SMTP id e20mr4895548vkd.149.1478169228247; Thu, 03 Nov 2016 03:33:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.149.203 with HTTP; Thu, 3 Nov 2016 03:33:47 -0700 (PDT) In-Reply-To: References: <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> From: Ben Laurie Date: Thu, 3 Nov 2016 10:33:47 +0000 Message-ID: To: Peter Bowen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 10:33:52 -0000 BTW, its probably smart to design a more general transparency standard and then have profiles for different use cases. But we did decide not to do that until we had other examples of transparency (I'm building one right now, as it happens, and it is not the only one I am aware of). On 3 November 2016 at 10:31, Ben Laurie wrote: > On 2 November 2016 at 14:08, Peter Bowen wrote: >> >> By requiring all logs MUST accept any certificate that chains to a >> root in the log's root list, 6962bis fails to allow log operators to >> mitigate any Denial of Service attacks mounted by attempting to log >> massive numbers of certificates that are not relevant to the log >> scope. For example, many existing certification authorities issue >> both server authentication certificates and certificates for personal >> identification. For some roots, acquiring large numbers of these is >> relatively easy (see discussion of fetching millions of Taiwanese >> Citizen Digital Certificates in >> https://smartfacts.cr.yp.to/smartfacts-20130916.pdf). As written >> today, a log MUST accept these. There is no option for a log to >> require that all certificates must meet some usability criteria. > > The requirement is to reject certs that don't meet the criteria, not > to accept those that do. From nobody Thu Nov 3 07:01:26 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF9F129A16 for ; Thu, 3 Nov 2016 07:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zeRUry7rr8P for ; Thu, 3 Nov 2016 07:01:24 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43C8129A25 for ; Thu, 3 Nov 2016 07:01:04 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id v84so88248910oie.3 for ; Thu, 03 Nov 2016 07:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VDp0MlYTtzdFRFmRV/GfgaDkrm9m48vDZdMT61Q5RuM=; b=I0KEap/RSHm6kLT3qMA2ZjSDgsazF/FJuHjAUKjuJ+t6nHczdgqY3vn1wGSYvR2CJ6 ci7wXvnFFZe4aNsdFaJXpFEPRTfrxPAnPamRtYvwIjdcwPxBgW67rcTCdTwW8UBwlNKu F8WwKeOZ5bC28P1zQn5AiYT1F7GidVP2T2fySnpHIz60flR7lbhQX9fS0NkEpvZbKwnG HeSQ0sD8IB8WKTXJlE09ek8WzPfPz4qVvZUv8ip240dRJl6gf2kWRsi4kpl3Zm5gqe43 r0ez40mFcajS2rZ9eOCCqAm+D0qE/qRh4X5v/IetCbt91gTEC7dG+CNKLbvQH+/RCrUt iVtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VDp0MlYTtzdFRFmRV/GfgaDkrm9m48vDZdMT61Q5RuM=; b=EopM6ABU58rromuCNiiUy7ojho24PQyZ1pWmUEFlovg3YtThzYAWmq12zuWLL4Dvhh AfG7EiYXFoZPON7RsJ6dpDQ8+qVy93FUVLTaOaRiYD+v5WDSldCtUSOEAgeMi5td+pS3 nubzzmW+wlaOLVYsiGLeqvicLBD7+sHcwHTHl43Lak8ZGqIxvS/Cz+jWatr80UUkPya3 UPpcpH7ZOzf/QRLzbPtMJPSxNGZq0d9V9nLxUQjr+qW+H3HcX19R/pUom+KjcL5i9LLV 3TuHXCjELu7bSVFubAhW3sSwfcPSkhtnd6/PxXiDdyj8REaFYPSwRCNhRuonFppF3TGP TW4g== X-Gm-Message-State: ABUngvcNUE1LQY6wBDiWiHbESCsr2U1syIlA63lcNHgDz+o5E9LoeP6mCo/TiMbt5e6FYi4NJoglRfct4NIyJQ== X-Received: by 10.107.184.214 with SMTP id i205mr8535069iof.167.1478181663786; Thu, 03 Nov 2016 07:01:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.39.68 with HTTP; Thu, 3 Nov 2016 07:01:02 -0700 (PDT) In-Reply-To: References: <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> From: Peter Bowen Date: Thu, 3 Nov 2016 07:01:02 -0700 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:01:26 -0000 On Thu, Nov 3, 2016 at 3:31 AM, Ben Laurie wrote: > On 2 November 2016 at 14:08, Peter Bowen wrote: >> >> By requiring all logs MUST accept any certificate that chains to a >> root in the log's root list, 6962bis fails to allow log operators to >> mitigate any Denial of Service attacks mounted by attempting to log >> massive numbers of certificates that are not relevant to the log >> scope. For example, many existing certification authorities issue >> both server authentication certificates and certificates for personal >> identification. For some roots, acquiring large numbers of these is >> relatively easy (see discussion of fetching millions of Taiwanese >> Citizen Digital Certificates in >> https://smartfacts.cr.yp.to/smartfacts-20130916.pdf). As written >> today, a log MUST accept these. There is no option for a log to >> require that all certificates must meet some usability criteria. > > The requirement is to reject certs that don't meet the criteria, not > to accept those that do. So the root list is just "advisory" -- I could include roots where my local policy results in rejecting all certs chained to that root? Or I could follow Brian's template and reject all and later add to the log via some other API (or have some rule like "client IP address must be 127.0.0.1" in order to get a cert logged)? These would all be 6962bis compliant? Thanks, Peter From nobody Thu Nov 3 08:45:53 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04BD129452 for ; Thu, 3 Nov 2016 08:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geoUYafl7MgJ for ; Thu, 3 Nov 2016 08:45:50 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7600129690 for ; Thu, 3 Nov 2016 08:45:50 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id p9so43132250vkd.3 for ; Thu, 03 Nov 2016 08:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kvk4Xl9nQvCuowVae1rKCimT+rRkCIVJPIlSc3CAyMg=; b=G0i9idJ6vt3bA/vvSQgrhk/ClFQ3S8bNJZPdahWM5LLUORS+v0tiquXU7SV0q0kf4/ bcivtj4QkHhp11/uPREjMrw8aenxX4DQgSh5vw65F15l0lM5Mwldb/gPiH5NZD94OpB2 6jdW6bcD3dOnMDtmqfc7wAQJbsqIk++5OZAUcjqv7h4UIje1uNHf5u+NoDRovOS6PiX/ Fp8ukN3yMMdtTevk2ISs+EyjpI7enKtVy0CIngNOnPSr6G3WTU8BZoh1tn5EaqTpordU KzYjjxu2y1dJSX+SC9cLlUGI4qMmY8uP3JaX4EiVGL5SQxTSQi6BsvTqWg9iNGqGdJiq ZMAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Kvk4Xl9nQvCuowVae1rKCimT+rRkCIVJPIlSc3CAyMg=; b=jvmTThuq7ojT6NuJquvf/0y7HtAvn5ppUTBurowV7VPi8eabl63+R3Y1H4RCXvy/yl Z4Xy2lHPQI4EpM+I6Mp3IWOMXxjEDrQ3smnOZ+B2eC6Rk7+KdXgk8+2IQIFUAwHDkcMN euOHRNyL20uytGbpb5qV2BdUmRTENRnDroljZ9diAwFNW4ni5KzvqizTW6obkFkn9rnS SrCFaXxG0cbnhYgqPgFsQlAldaJHYDZ9/McJnMUBjLYvQ69PlwYp0cSwMTKmk2pHwy7s CamD0BA0rTs79e1AqriG1XSjaKEKTZjVj2Kpw1sNmKjjTURAbR5btcfpJ6EpPoIKx6HL HrOg== X-Gm-Message-State: ABUngve85FWudPOaydVI1dE21aiBaDPFEq2FlmGwQhepokcQqN8iRG8eJ8aVN+E7s4r5gxm7f1zQ0t2bLQtjg97t X-Received: by 10.31.92.84 with SMTP id q81mr8134642vkb.88.1478187949641; Thu, 03 Nov 2016 08:45:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.149.203 with HTTP; Thu, 3 Nov 2016 08:45:48 -0700 (PDT) In-Reply-To: References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> From: Ben Laurie Date: Thu, 3 Nov 2016 15:45:48 +0000 Message-ID: To: Peter Bowen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Stephen Farrell Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 15:45:53 -0000 On 1 November 2016 at 01:04, Peter Bowen wrote: > > On Mon, Oct 31, 2016 at 3:02 PM, Stephen Farrell > wrote: > > On 31/10/16 19:01, Peter Bowen wrote: > >> On Mon, Oct 24, 2016 at 9:37 PM, Melinda Shore wrote: > >>> You may have seen the recent announcement from the Chrome > >>> team that as of October 2017 certificates will need to comply > >>> with Chrome's CT policy in order to be trusted. There was > >>> also an invitation to discuss that on the trans mailing list. > >>> This is a reminder that mailing list discussions need to > >>> remain focused on the specifications being produced by the > >>> working group - that is to say, policies related to > >>> individual implementations are out of scope for the working > >>> group except to the extent that they bear on decisions related > >>> to our working group drafts. > >> > >> Paul and Melinda, > >> > >> Do you consider discussion of use cases for privacy to be in-scope for > >> this group or do you consider only the technical implementation of > >> privacy (e.g. section 4 of 6962-bis and the redaction draft) to be > >> in-scope? > > > > (Wearing no IETF hat, but perhaps the hat of someone interested > > in privacy...) > > > > I do not believe that it makes sense for us to talk as if > > privacy was a concept that applies to corporate entities. > > > > I do believe that your text above conflates privacy (a human > > concept) with corporate secrecy (a useful but different thing) > > in ways that are in the end damaging to both. (I further and > > even moreso believe that such conflation would be damaging > > to the IETF were we to slip into the bad practice of not > > calling out that terminological sloppiness.) > > > > I totally get that redaction has utility for folks who need > > corporate secrecy on a temporary basis. I absolutely do not > > accept that that has any privacy aspect. > > > > Can you call out the privacy aspect that applies to humans > > and that is a real part of the question related to support for > > redaction in CT? > > There are certificates that have personal information (e.g. given > name, surname, and physical location) in the subject distinguished > name or the subject alternative names. It is very possible that there > may be a desire to redact this information (in fact it could even be > required in some jurisdictions as CT could be considered a database). > We already see this with domains in many countries where the full > registrant details are not publicly available. > > Additionally, while 6962-bis does focus on certificates used for TLS > server authentication, there are other types of certificates that > could be logged. For example a certificate that is used with email > and contains both the email address and given/surname. It might be > that the owner of the certificate only wishes to disclose this binding > to people receiving email from them rather than publicly disclosing > it. We have also seen requests for certificates that cover phone > numbers. A similar situation would apply -- having an "unlisted" > number should be possible, where the subject details (other than phone > number) are only known to a group of people who communicate with the > number. For these use cases, something CONIKS-like is probably more appropriate. > So I think there is a privacy aspect here in addition to any corporate > secrecy aspect. > > Thanks, > Peter > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Thu Nov 3 09:36:46 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED753129648 for ; Thu, 3 Nov 2016 09:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_Lej4HbdVx7 for ; Thu, 3 Nov 2016 09:36:43 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A912D12949B for ; Thu, 3 Nov 2016 09:36:43 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id l124so53836876ywb.3 for ; Thu, 03 Nov 2016 09:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MeLhFn6PfxK6DBy9mBVfDshGd3lcYIfiJCUh0jV5rMY=; b=fpGCL9LCjVGKahvF3TXr+xC0zqgPaAbnVbM6XE24D7zK+nKGdrl+4cVq9ur1GYb9PB ULzokKJMl2Ieq4Fp0uhrDczv7ISDBGSlzTXIUCgtUxawM+Yf8UQR+HR06S/olVOKdDUx NodQpUriXF0RXfGt9jt71xm368hx2kQj2a3S++cgDVp4/4nI3PRG+RBj6qGmxk6pecq7 5afqaOjK3TPfZTCVzzX8ARWIrUZRBotBJl40/S6RlXCBY6shqrtAj0cpxHZSJ2KtsU+p RJLCx32d8fPBYjjnXoG9StGSEdttiAMzBtyTRSiQC3yZsoxVsAZHIfseuugpJVK2PhNH m5dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MeLhFn6PfxK6DBy9mBVfDshGd3lcYIfiJCUh0jV5rMY=; b=GpyEaWP581tUrz6kd5mk93Q8gDmGGXbPFoFZfZwjFArLUMdrOUAUSrdZn0AKI3BZao heXk0HRfG/AOE8OI/TYsrRB88ZXrwfdMHdt+pzkxe/uQVkNeZ+f/ZfQU96n71pmsJlyq NJXTFIX5KY/dFhKVFOiahhGdn6Tc6ViUUehG95gv3wyQKZG6f4pyGHM4/zjlQllFRLxG Vx9WhuYnC9LmwWdGd/ZKHds4K0kQckd9uceeedJIFklV+wmpbErt3p7wU0p9TkrdRCtF xwSzPkNqWfkHCdOE5KWVPZfZRnsIY37HMhaIBLN/I/4qUmNDn1sPLJX8VEel/c3ERH9s JuTQ== X-Gm-Message-State: ABUngvez4TkXlCyCFC/fEGrrjGfdGqqNv34phTvkTNu2RL/MQ1w0VXJ65qY0Ni2jSr9JV02cQWMeAIIpEUn2cQ== X-Received: by 10.36.106.76 with SMTP id l73mr5897796itc.115.1478191002894; Thu, 03 Nov 2016 09:36:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.39.68 with HTTP; Thu, 3 Nov 2016 09:36:42 -0700 (PDT) In-Reply-To: References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> From: Peter Bowen Date: Thu, 3 Nov 2016 09:36:42 -0700 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Stephen Farrell Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 16:36:45 -0000 On Thu, Nov 3, 2016 at 8:45 AM, Ben Laurie wrote: > On 1 November 2016 at 01:04, Peter Bowen wrote: >> >> There are certificates that have personal information (e.g. given >> name, surname, and physical location) in the subject distinguished >> name or the subject alternative names. It is very possible that there >> may be a desire to redact this information (in fact it could even be >> required in some jurisdictions as CT could be considered a database). >> We already see this with domains in many countries where the full >> registrant details are not publicly available. >> >> Additionally, while 6962-bis does focus on certificates used for TLS >> server authentication, there are other types of certificates that >> could be logged. For example a certificate that is used with email >> and contains both the email address and given/surname. It might be >> that the owner of the certificate only wishes to disclose this binding >> to people receiving email from them rather than publicly disclosing >> it. We have also seen requests for certificates that cover phone >> numbers. A similar situation would apply -- having an "unlisted" >> number should be possible, where the subject details (other than phone >> number) are only known to a group of people who communicate with the >> number. > > For these use cases, something CONIKS-like is probably more appropriate. How does CONIKS doesn't solve the problem of server authentication certificates that identify an individual as the certificate subscriber? Even if we assume for the moment that 6962bis is only for "traditional" PKI and only for server authentication, these certs are still problematic to log unredacted. Thanks, Peter From nobody Thu Nov 3 10:31:21 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B890129A99 for ; Thu, 3 Nov 2016 10:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8mKMTK8MsES for ; Thu, 3 Nov 2016 10:31:11 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3CA129AAE for ; Thu, 3 Nov 2016 10:31:01 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id p9so45955616vkd.3 for ; Thu, 03 Nov 2016 10:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EClVmar5gh8PAgyD6M/VJiXML1C1Mpb1hauSzkw90jA=; b=RsL+O0Ie01Ra0PEmQxghfN//Fht2/EMpNFKVYf2pcwmOyTJdVMT02xOyQ68Ds6oX0r HmCld0oERw3X2lza8ZVfjrBKdOSzTkaSBVypa+stFFAnuQAmr04m4IN9oLWg8IpcCose w95hdGnUrCu8i3tryMpN/oGamEgbcgq4s3B7LvJpL/0ek6JnnYsSYSQtvZt7B90npu9r 8Cx0+Oe9HdVX2tlRR0bUwOQBidrTjTdywCZ4+d61v8sJ0iTWxNo/wcTsodjiKVEwYVFw 7i/3DujU3eM5i9qSDRwrn4df0TUR941K8xZgE7oPZD3PGjNUmDDqBN/+Eu6mstV7ed0C z6YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EClVmar5gh8PAgyD6M/VJiXML1C1Mpb1hauSzkw90jA=; b=FMYTA8TdaaF0nVsEoz8SmWZfCr+aVqJb5Hjf04MXPztXltfgnxJ/SMvFVf07MTHHZh pcnwm8PgBwJuPqEk8RU3qYV6SopjAugn8AZaESjsWCqseVRJ92hwUwMcZkSh+WwrPkeg nB2AcFsxzf/ypZDRh5zCxkDkwFtbFtZyvgcwG/d21BdswBKDv1g486siRtG2C2fgmgIr gyby1eKepJM7B2ACUnZdKCz9n68RHme49YCua6q2dyevNNlyXzLQ9z9t6lnay8LDzu5M LOECS0RRgW3FUEo3+cUKOTvZ2aTFdoChFa7WCfqWi14eyyv8D6NE/y6L8iYqFna4ja1u G8YA== X-Gm-Message-State: ABUngvfBhJ+6T3uH2iOqeiQJjDC4yiGnpcf1XP7y2+WbDQ7TyArcEcZz3oqB/86cgb3s6W5+8pnNVGn++SMACtLI X-Received: by 10.31.92.84 with SMTP id q81mr8532477vkb.88.1478194260586; Thu, 03 Nov 2016 10:31:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.149.203 with HTTP; Thu, 3 Nov 2016 10:30:59 -0700 (PDT) In-Reply-To: References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> From: Ben Laurie Date: Thu, 3 Nov 2016 17:30:59 +0000 Message-ID: To: Peter Bowen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Stephen Farrell Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 17:31:17 -0000 On 3 November 2016 at 16:36, Peter Bowen wrote: > On Thu, Nov 3, 2016 at 8:45 AM, Ben Laurie wrote: >> On 1 November 2016 at 01:04, Peter Bowen wrote: >>> >>> There are certificates that have personal information (e.g. given >>> name, surname, and physical location) in the subject distinguished >>> name or the subject alternative names. It is very possible that there >>> may be a desire to redact this information (in fact it could even be >>> required in some jurisdictions as CT could be considered a database). >>> We already see this with domains in many countries where the full >>> registrant details are not publicly available. >>> >>> Additionally, while 6962-bis does focus on certificates used for TLS >>> server authentication, there are other types of certificates that >>> could be logged. For example a certificate that is used with email >>> and contains both the email address and given/surname. It might be >>> that the owner of the certificate only wishes to disclose this binding >>> to people receiving email from them rather than publicly disclosing >>> it. We have also seen requests for certificates that cover phone >>> numbers. A similar situation would apply -- having an "unlisted" >>> number should be possible, where the subject details (other than phone >>> number) are only known to a group of people who communicate with the >>> number. >> >> For these use cases, something CONIKS-like is probably more appropriate. > > How does CONIKS doesn't solve the problem of server authentication > certificates that identify an individual as the certificate > subscriber? Sorry, I was referring to the latter cases - e.g. S/MIME (which is what you seem to be describing). > Even if we assume for the moment that 6962bis is only for > "traditional" PKI and only for server authentication, these certs are > still problematic to log unredacted. Since the personal info in those cases is not relevant to browsers validation of the cert, in principle I can't see why we would care if it were redacted. OTOH, the certificate is public anyway, so not sure why redacting it in the log is useful. The real problem is the certificate, not the log entry! From nobody Thu Nov 3 10:42:25 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDD0129ABF for ; Thu, 3 Nov 2016 10:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plejyV5Cjlft for ; Thu, 3 Nov 2016 10:42:21 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB86129AB9 for ; Thu, 3 Nov 2016 10:42:21 -0700 (PDT) From: Jeremy Rowley Authentication-Results: mail.digicert.com; dkim=permerror (bad message/signature format) To: Ben Laurie , Peter Bowen Thread-Topic: [Trans] Topicality Thread-Index: AQHSLnmWWB7iOlW+ek2jHVncrasLD6DDWgcAgAAypQCAADLBgIAEGuYAgAAOOQCAAA8qgP//njnA Date: Thu, 3 Nov 2016 17:42:19 +0000 Message-ID: References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02FE_01D235C7.54F96440" MIME-Version: 1.0 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Stephen Farrell Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 17:42:24 -0000 ------=_NextPart_000_02FE_01D235C7.54F96440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Unlike the certificate, which can be deleted, revoked, or in some other way removed from the CA's database and the server, a certificate cannot be removed from a CT log, meaning it's impossible to delete PII in compliance with the EU directive. -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ben Laurie Sent: Thursday, November 3, 2016 11:31 AM To: Peter Bowen Cc: Melinda Shore ; trans@ietf.org; Stephen Farrell Subject: Re: [Trans] Topicality On 3 November 2016 at 16:36, Peter Bowen wrote: > On Thu, Nov 3, 2016 at 8:45 AM, Ben Laurie wrote: >> On 1 November 2016 at 01:04, Peter Bowen wrote: >>> >>> There are certificates that have personal information (e.g. given >>> name, surname, and physical location) in the subject distinguished >>> name or the subject alternative names. It is very possible that >>> there may be a desire to redact this information (in fact it could >>> even be required in some jurisdictions as CT could be considered a database). >>> We already see this with domains in many countries where the full >>> registrant details are not publicly available. >>> >>> Additionally, while 6962-bis does focus on certificates used for TLS >>> server authentication, there are other types of certificates that >>> could be logged. For example a certificate that is used with email >>> and contains both the email address and given/surname. It might be >>> that the owner of the certificate only wishes to disclose this >>> binding to people receiving email from them rather than publicly >>> disclosing it. We have also seen requests for certificates that >>> cover phone numbers. A similar situation would apply -- having an "unlisted" >>> number should be possible, where the subject details (other than >>> phone >>> number) are only known to a group of people who communicate with the >>> number. >> >> For these use cases, something CONIKS-like is probably more appropriate. > > How does CONIKS doesn't solve the problem of server authentication > certificates that identify an individual as the certificate > subscriber? Sorry, I was referring to the latter cases - e.g. S/MIME (which is what you seem to be describing). > Even if we assume for the moment that 6962bis is only for > "traditional" PKI and only for server authentication, these certs are > still problematic to log unredacted. Since the personal info in those cases is not relevant to browsers validation of the cert, in principle I can't see why we would care if it were redacted. OTOH, the certificate is public anyway, so not sure why redacting it in the log is useful. The real problem is the certificate, not the log entry! _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans ------=_NextPart_000_02FE_01D235C7.54F96440 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMTAzMTc0MjE4WjAj BgkqhkiG9w0BCQQxFgQUCCep6SeNMzcFQGZr0q+2THeZSgowgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAKfqMQgicgB/7Cj5HOtea5FKRyngSQjwvmnsF5QV yw36MsMn8+BjcneTpJBssoXVOSTtnIAvdAAbvX4lOc4QHz6Rr2lpl5fsTgsabq+bpwW4dyEPsti6 HZEK6faDfzUjGNk0ETBqu5GqhPa3wrto4t0R+U3ne1+U54eYlDwM/useFfUDY01NWZDrTAOJeQLa H7LraTf5XtUH17eoBXXnpd3MRPBsjnYWxWdpKbzy2fEW/A+6BcAV/Ul0fF9oMLyOy29ZSJdXhubn I7tECbgkPfdqgVbIBeMJbMsjmDtEnbkT9tzHZiz6jNugwtOFPwCWhQe9jprmNUk4jSjHGFJRNWYA AAAAAAA= ------=_NextPart_000_02FE_01D235C7.54F96440-- From nobody Thu Nov 3 12:13:32 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B131294C4 for ; Thu, 3 Nov 2016 12:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSWCBeryv3Jt for ; Thu, 3 Nov 2016 12:13:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86787129431 for ; Thu, 3 Nov 2016 12:13:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B404ABE79; Thu, 3 Nov 2016 19:13:27 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW89aRmI9gKm; Thu, 3 Nov 2016 19:13:26 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8E642BE7B; Thu, 3 Nov 2016 19:13:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1478200406; bh=78K8qQUwK7JkfKa1v35tlvU2IayQuK/7nhG4mx5/Vos=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=OgiZ0LgT5wxyybRB3OZ/99vW3D+yFBEz/Y8iXcJ/2faXkRjvUz8iUoyswKlSnMMPO yQykAG3yy0tLz4Zbpo3eWn36Ao+yCpNufdOmVRxGdomqM7GzLCy54GpkU3qVch/x9Z gdF+/YLqzd0G445y2hwyESfBookNywKgDgzW91Sc= To: Jeremy Rowley , Ben Laurie , Peter Bowen References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 3 Nov 2016 19:13:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090103070401080202060000" Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 19:13:31 -0000 This is a cryptographically signed message in MIME format. --------------ms090103070401080202060000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/11/16 17:42, Jeremy Rowley wrote: > Unlike the certificate, which can be deleted, revoked, or in some other= way > removed from the CA's database and the server, a certificate cannot be > removed from a CT log, meaning it's impossible to delete PII in complia= nce > with the EU directive.=20 Again - there is no "EU directive" that calls for deletion of this PII, that's just speculation. S. >=20 > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ben Laurie > Sent: Thursday, November 3, 2016 11:31 AM > To: Peter Bowen > Cc: Melinda Shore ; trans@ietf.org; Stephen Fa= rrell > > Subject: Re: [Trans] Topicality >=20 > On 3 November 2016 at 16:36, Peter Bowen wrote: >> On Thu, Nov 3, 2016 at 8:45 AM, Ben Laurie wrote: >>> On 1 November 2016 at 01:04, Peter Bowen wrote: >>>> >>>> There are certificates that have personal information (e.g. given=20 >>>> name, surname, and physical location) in the subject distinguished=20 >>>> name or the subject alternative names. It is very possible that=20 >>>> there may be a desire to redact this information (in fact it could=20 >>>> even be required in some jurisdictions as CT could be considered a > database). >>>> We already see this with domains in many countries where the full=20 >>>> registrant details are not publicly available. >>>> >>>> Additionally, while 6962-bis does focus on certificates used for TLS= =20 >>>> server authentication, there are other types of certificates that=20 >>>> could be logged. For example a certificate that is used with email = >>>> and contains both the email address and given/surname. It might be = >>>> that the owner of the certificate only wishes to disclose this=20 >>>> binding to people receiving email from them rather than publicly=20 >>>> disclosing it. We have also seen requests for certificates that=20 >>>> cover phone numbers. A similar situation would apply -- having an > "unlisted" >>>> number should be possible, where the subject details (other than=20 >>>> phone >>>> number) are only known to a group of people who communicate with the= =20 >>>> number. >>> >>> For these use cases, something CONIKS-like is probably more appropria= te. >> >> How does CONIKS doesn't solve the problem of server authentication=20 >> certificates that identify an individual as the certificate=20 >> subscriber? >=20 > Sorry, I was referring to the latter cases - e.g. S/MIME (which is what= you > seem to be describing). >=20 >> Even if we assume for the moment that 6962bis is only for=20 >> "traditional" PKI and only for server authentication, these certs are= =20 >> still problematic to log unredacted. >=20 > Since the personal info in those cases is not relevant to browsers > validation of the cert, in principle I can't see why we would care if i= t > were redacted. OTOH, the certificate is public anyway, so not sure why > redacting it in the log is useful. >=20 > The real problem is the certificate, not the log entry! >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans >=20 >=20 >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans >=20 --------------ms090103070401080202060000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDMx OTEzMjVaMC8GCSqGSIb3DQEJBDEiBCDMiZByk9Zhxdp5cYIYNze8kChad55LoNRaX1SSBvbs 2DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAYGIWTG9essyosli7M5fYWEpwMf1/PY/v7vixbSz+HhpEHvnx02xPa nFE/kY+THrl8XGq7hFMDJtH7z+NEi+w+Vc7z7jEEz3JOWMVXholqo1f8nczpwmGCQbrfHerz uJUd3tOVpKbdDaBU8rm2M3dWEXZaX1cheqJ2nGoQhEIRBnFl0AXTkPYqeee8Ey5de9DIyQvs s7MHMJLO+o2Alt2M6Abr/BHEM5nFIEBSyC2ix1WEJVBCk12nRV/HZSzcBQeT0lkuLmrcuHrU KZBoR2Bprcyi7HiQvs72GKYan9oSUWj23d6MfVav8KK27CyTzv0fqeKLO0RxozTrBTWhPG8W AAAAAAAA --------------ms090103070401080202060000-- From nobody Thu Nov 3 12:33:35 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB9D12956A for ; Thu, 3 Nov 2016 12:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.689 X-Spam-Level: X-Spam-Status: No, score=-5.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYt_oGBZfLkt for ; Thu, 3 Nov 2016 12:33:32 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3202C129431 for ; Thu, 3 Nov 2016 12:33:32 -0700 (PDT) From: Jeremy Rowley Authentication-Results: mail.digicert.com; dkim=permerror (bad message/signature format) To: Stephen Farrell , Ben Laurie , Peter Bowen Thread-Topic: [Trans] Topicality Thread-Index: AQHSLnmWWB7iOlW+ek2jHVncrasLD6DDWgcAgAAypQCAADLBgIAEGuYAgAAOOQCAAA8qgP//njnAgAB+ZoD//50qIA== Date: Thu, 3 Nov 2016 19:33:30 +0000 Message-ID: <3bab9fbea67c482b98a44555d60cd406@EX2.corp.digicert.com> References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03AB_01D235D6.DD2EC8F0" MIME-Version: 1.0 Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 19:33:34 -0000 ------=_NextPart_000_03AB_01D235D6.DD2EC8F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Depends on your interpretation of Article 12 of Directive 95/46/EC, the ECHR, and the potential impact of Article 17 of the new GDRP, although I suppose the data is still considered necessary in relation to purposes for which it was discussed and there are legitimate grounds for the processing. Given that names and email addresses will be discussed if subject information is included (especially if we'd like CT to eventually apply to s/MIME certs), I'd like a way to redact the info as it's questionable whether "forever" on a CT long complies with the requirement to keep the data no longer than necessary. -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, November 3, 2016 1:13 PM To: Jeremy Rowley ; Ben Laurie ; Peter Bowen Cc: Melinda Shore ; trans@ietf.org Subject: Re: [Trans] Topicality On 03/11/16 17:42, Jeremy Rowley wrote: > Unlike the certificate, which can be deleted, revoked, or in some other way > removed from the CA's database and the server, a certificate cannot be > removed from a CT log, meaning it's impossible to delete PII in compliance > with the EU directive. Again - there is no "EU directive" that calls for deletion of this PII, that's just speculation. S. > > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ben Laurie > Sent: Thursday, November 3, 2016 11:31 AM > To: Peter Bowen > Cc: Melinda Shore ; trans@ietf.org; Stephen Farrell > > Subject: Re: [Trans] Topicality > > On 3 November 2016 at 16:36, Peter Bowen wrote: >> On Thu, Nov 3, 2016 at 8:45 AM, Ben Laurie wrote: >>> On 1 November 2016 at 01:04, Peter Bowen wrote: >>>> >>>> There are certificates that have personal information (e.g. given >>>> name, surname, and physical location) in the subject distinguished >>>> name or the subject alternative names. It is very possible that >>>> there may be a desire to redact this information (in fact it could >>>> even be required in some jurisdictions as CT could be considered a > database). >>>> We already see this with domains in many countries where the full >>>> registrant details are not publicly available. >>>> >>>> Additionally, while 6962-bis does focus on certificates used for TLS >>>> server authentication, there are other types of certificates that >>>> could be logged. For example a certificate that is used with email >>>> and contains both the email address and given/surname. It might be >>>> that the owner of the certificate only wishes to disclose this >>>> binding to people receiving email from them rather than publicly >>>> disclosing it. We have also seen requests for certificates that >>>> cover phone numbers. A similar situation would apply -- having an > "unlisted" >>>> number should be possible, where the subject details (other than >>>> phone >>>> number) are only known to a group of people who communicate with the >>>> number. >>> >>> For these use cases, something CONIKS-like is probably more appropriate. >> >> How does CONIKS doesn't solve the problem of server authentication >> certificates that identify an individual as the certificate >> subscriber? > > Sorry, I was referring to the latter cases - e.g. S/MIME (which is what you > seem to be describing). > >> Even if we assume for the moment that 6962bis is only for >> "traditional" PKI and only for server authentication, these certs are >> still problematic to log unredacted. > > Since the personal info in those cases is not relevant to browsers > validation of the cert, in principle I can't see why we would care if it > were redacted. OTOH, the certificate is public anyway, so not sure why > redacting it in the log is useful. > > The real problem is the certificate, not the log entry! > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > ------=_NextPart_000_03AB_01D235D6.DD2EC8F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMTAzMTkzMzI5WjAj BgkqhkiG9w0BCQQxFgQUcztFnJDxZ8I5/zAG2MsmzR44xU8wgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAJKuSlc3xVhcUWhQHaqMRKU1uU4UM2W8PrK2poiT VuEqWqH6kXk6pEW8WKzPAEb6zWki/ei1bhoZfmMqhmLlt8ATSXP0B/Xv8xCmSXtxDuNxmcvxhhVa Ko7+MYt+VHMd9b5FXivteBl2JE2LF2kNLi5ca11GYWjRZytmtegRPoTnJk9sI/r4WrDB6dOQD68o 3Fya4Mue6VCMl6AB3omu9BQ61LNry5SnWF2g3UZqwQPoU/U52pPxvRGr/ftrGX+Ylf5SS4PzsA+/ Yeu0qsxbiMgWP4l5ErikP0OVHQGxK9e/+Mb6P3ML2nSZhTlHJ9jUBb4tjrCBa9OAa0mmg14/CFcA AAAAAAA= ------=_NextPart_000_03AB_01D235D6.DD2EC8F0-- From nobody Fri Nov 4 05:29:50 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34C4129572 for ; Fri, 4 Nov 2016 05:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVSPMXrTJf1M for ; Fri, 4 Nov 2016 05:29:45 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDDE71294DD for ; Fri, 4 Nov 2016 05:29:45 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id b35so64612863uaa.3 for ; Fri, 04 Nov 2016 05:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZTjZSyj/VvToiWBKpddLvYg6vSQsyjl8DqA+SryVLgk=; b=Ft7IjZVhDQE4Z9C5831kK6G1RK/sgK75zkI+n1L9U3dIwvw+Pf4Nn+cj09UtiPCibm z0BBAtNHrE5Sj6naoPOzpJG/OkWG3f6XHaCzfnuakbnQHXKu2qjUksbVVGi7PMR1UG1x cKSZzA79WthQSbvhTObPlVACLS9jFDi4nalldy+m+v7cGdSg3tDHG/adyRrwWP0m6v+w reA6iDR+f6POzQrzFicJKyrvLXhJDEdpVcCawzIFQuwXwgxWkDWfc5j0PXKXeOdBm01X tiFtgdHDLINKzOkJOKC6OTOvK0Qc8DwIrLAHw/8Ei6Hwr2oYDSsFE/Vs/78TB4VlgC5Q JPXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZTjZSyj/VvToiWBKpddLvYg6vSQsyjl8DqA+SryVLgk=; b=E30IIj4v/k/tID/ZwbphaJIwHQixUBLcmA7hUiT5lQh7rRwyicWpmWZlr72/kvyCnr vn+NGKIE+Q6ndwLuwN01ApGXQFHhdJPDt4v7EQ1qJcgtQEBKMR8fb+Csb3A+t+rZ9rxV U6a1FdCogPiNYB8wxg9zKfbXNWxarOMHNLEesjaPRs4TbXwxFNPQZtIlmT/xsx3MRiHQ VVW7tR9Qsmk1SM9cD5yvSTXnFwKJmwhL/ZYofzhj/KQaP5ZCiBmG1fMoTpNIkCOohmTk fuS4m/VHu/pXEuS09M7c9UhtwX4U5R25porR6flOk72eVPehR0m5xb9UE0ptRE+c0Wg8 Mw4w== X-Gm-Message-State: ABUngvfNkGSly3KdJQeAEGPwPlzz7yoAjM6WJCWEKC9k6a5ngFflXwIEuc9fEO4uQ6knsRdhoEeEEnyehSHdHxpH X-Received: by 10.176.64.3 with SMTP id h3mr10664385uad.176.1478262584686; Fri, 04 Nov 2016 05:29:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.149.203 with HTTP; Fri, 4 Nov 2016 05:29:43 -0700 (PDT) In-Reply-To: <3bab9fbea67c482b98a44555d60cd406@EX2.corp.digicert.com> References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> <3bab9fbea67c482b98a44555d60cd406@EX2.corp.digicert.com> From: Ben Laurie Date: Fri, 4 Nov 2016 12:29:43 +0000 Message-ID: To: Jeremy Rowley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen , Stephen Farrell Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 12:29:48 -0000 On 3 November 2016 at 19:33, Jeremy Rowley wrote: > Depends on your interpretation of Article 12 of Directive 95/46/EC, the ECHR, > and the potential impact of Article 17 of the new GDRP, although I suppose the > data is still considered necessary in relation to purposes for which it was > discussed and there are legitimate grounds for the processing. Given that > names and email addresses will be discussed if subject information is included > (especially if we'd like CT to eventually apply to s/MIME certs), Redaction is not the correct solution for S/MIME certs. As I already said, something CONIKS-like would be more appropriate (i.e. something that hides the email in a verifiable way). I imagine there are other possibilities. > I'd like a > way to redact the info as it's questionable whether "forever" on a CT long > complies with the requirement to keep the data no longer than necessary. > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, November 3, 2016 1:13 PM > To: Jeremy Rowley ; Ben Laurie ; > Peter Bowen > Cc: Melinda Shore ; trans@ietf.org > Subject: Re: [Trans] Topicality > > > > On 03/11/16 17:42, Jeremy Rowley wrote: >> Unlike the certificate, which can be deleted, revoked, or in some other way >> removed from the CA's database and the server, a certificate cannot be >> removed from a CT log, meaning it's impossible to delete PII in compliance >> with the EU directive. > > Again - there is no "EU directive" that calls for deletion of > this PII, that's just speculation. > > S. > >> >> -----Original Message----- >> From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ben Laurie >> Sent: Thursday, November 3, 2016 11:31 AM >> To: Peter Bowen >> Cc: Melinda Shore ; trans@ietf.org; Stephen Farrell >> >> Subject: Re: [Trans] Topicality >> >> On 3 November 2016 at 16:36, Peter Bowen wrote: >>> On Thu, Nov 3, 2016 at 8:45 AM, Ben Laurie wrote: >>>> On 1 November 2016 at 01:04, Peter Bowen wrote: >>>>> >>>>> There are certificates that have personal information (e.g. given >>>>> name, surname, and physical location) in the subject distinguished >>>>> name or the subject alternative names. It is very possible that >>>>> there may be a desire to redact this information (in fact it could >>>>> even be required in some jurisdictions as CT could be considered a >> database). >>>>> We already see this with domains in many countries where the full >>>>> registrant details are not publicly available. >>>>> >>>>> Additionally, while 6962-bis does focus on certificates used for TLS >>>>> server authentication, there are other types of certificates that >>>>> could be logged. For example a certificate that is used with email >>>>> and contains both the email address and given/surname. It might be >>>>> that the owner of the certificate only wishes to disclose this >>>>> binding to people receiving email from them rather than publicly >>>>> disclosing it. We have also seen requests for certificates that >>>>> cover phone numbers. A similar situation would apply -- having an >> "unlisted" >>>>> number should be possible, where the subject details (other than >>>>> phone >>>>> number) are only known to a group of people who communicate with the >>>>> number. >>>> >>>> For these use cases, something CONIKS-like is probably more appropriate. >>> >>> How does CONIKS doesn't solve the problem of server authentication >>> certificates that identify an individual as the certificate >>> subscriber? >> >> Sorry, I was referring to the latter cases - e.g. S/MIME (which is what you >> seem to be describing). >> >>> Even if we assume for the moment that 6962bis is only for >>> "traditional" PKI and only for server authentication, these certs are >>> still problematic to log unredacted. >> >> Since the personal info in those cases is not relevant to browsers >> validation of the cert, in principle I can't see why we would care if it >> were redacted. OTOH, the certificate is public anyway, so not sure why >> redacting it in the log is useful. >> >> The real problem is the certificate, not the log entry! >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> >> >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> > From nobody Fri Nov 4 06:41:13 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49925129526 for ; Fri, 4 Nov 2016 06:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A1vfHb-cQtU for ; Fri, 4 Nov 2016 06:41:08 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB0A129503 for ; Fri, 4 Nov 2016 06:40:55 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id b35so66188644uaa.3 for ; Fri, 04 Nov 2016 06:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kiT97HdHcCSgpQ0Kh6SWNa2S4wcjtqLZ8Rjr6mH6GNg=; b=dUVGpjAuS95cB65a7HzmAFe8effM//FMSd6LaoJ9DKxr+iuyvrrI0fjWfcLlehTjoX E1RjcfOwyp4ZAbdGcZidAnI0ok7q2dg4qZOhQ5i97hI9UlGVdEVEbb4x6uBsEhf/sjkr 5XTBBGPEtwCFTcKZ3Cc3JijrRJhwv2MKKqIOqJLYeQFQS7K0nkQor36NiKuegmPwedHw Cdzptc8McK6ndCz416Z1LIP2NZbL4+6vW5RJt3wFCEct8KRffBiUNRt6vMX3msrUkZxe ffLvQrj1puZulDYFMKBJTwWx7MGLtMkumookvTlfZ//qWb2nsOIni2L+oInF3/+rsGx8 GDaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kiT97HdHcCSgpQ0Kh6SWNa2S4wcjtqLZ8Rjr6mH6GNg=; b=CzqmI3W9hDWc7WRFLHXwzZBhpUCYF7IT+yX3O6YY9rIcBLigWCyRiIapDUWQV2z7YM UAWnuYX2bHZXwxDRoZQ+5PS1BFiLwOgTj4jPS0Bd3RKjtyrIJHbFWb+vhwLjQ7tZtlBX fNRFLkJ748n7vDmr5aj+oMjODda5WOC2wBb+aAcPkM7+vSs3PDaVj3mKMaFQKTYYgkL1 XmAALROg9bGoQcS/IQWgV66qhuI9MBVcV0KCs/DUjdYH/rI1yGwhQmp9dnrKOozJgiAV yhTUy4v83Wx0sEIdw2qWND/oyorMThd+uPplBFxHunBwLgSpeAPMquNITS7X6Fbdkofn 7RRA== X-Gm-Message-State: ABUngvc8BFVSyNm0llF7/CfKAnyFWR4PH/+OWOg2gYrFgOULLzKVexo85xtrS3aGLtBWCpj7IkTNt+PNVVcyLMN8 X-Received: by 10.176.64.3 with SMTP id h3mr10850316uad.176.1478266389879; Fri, 04 Nov 2016 06:33:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.149.203 with HTTP; Fri, 4 Nov 2016 06:33:09 -0700 (PDT) In-Reply-To: References: <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> From: Ben Laurie Date: Fri, 4 Nov 2016 13:33:09 +0000 Message-ID: To: Peter Bowen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 13:41:10 -0000 On 3 November 2016 at 14:01, Peter Bowen wrote: > On Thu, Nov 3, 2016 at 3:31 AM, Ben Laurie wrote: >> On 2 November 2016 at 14:08, Peter Bowen wrote: >>> >>> By requiring all logs MUST accept any certificate that chains to a >>> root in the log's root list, 6962bis fails to allow log operators to >>> mitigate any Denial of Service attacks mounted by attempting to log >>> massive numbers of certificates that are not relevant to the log >>> scope. For example, many existing certification authorities issue >>> both server authentication certificates and certificates for personal >>> identification. For some roots, acquiring large numbers of these is >>> relatively easy (see discussion of fetching millions of Taiwanese >>> Citizen Digital Certificates in >>> https://smartfacts.cr.yp.to/smartfacts-20130916.pdf). As written >>> today, a log MUST accept these. There is no option for a log to >>> require that all certificates must meet some usability criteria. >> >> The requirement is to reject certs that don't meet the criteria, not >> to accept those that do. > > So the root list is just "advisory" -- I could include roots where my > local policy results in rejecting all certs chained to that root? Or > I could follow Brian's template and reject all and later add to the > log via some other API (or have some rule like "client IP address must > be 127.0.0.1" in order to get a cert logged)? These would all be > 6962bis compliant? I was just reading what the language you quoted says. I don't actually have the whole of 6962bis in my head right now. The bit you didn't quote does say they the log has to accept valid certs, tho: "Logs MUST accept certificates and precertificates that are fully valid according to RFC 5280 [RFC5280] verification rules and are submitted with such a chain." From nobody Fri Nov 4 07:07:55 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3011294FE for ; Fri, 4 Nov 2016 07:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNTm5EaT-pgA for ; Fri, 4 Nov 2016 07:07:52 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43615129495 for ; Fri, 4 Nov 2016 07:07:52 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id d128so31094144ybh.2 for ; Fri, 04 Nov 2016 07:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rox/k2TptN5JOKZoxWSQlNUdIsdZrxq63pkyzysm5A4=; b=jM4fJSmgP4DIeQ6oM7VEXghxOtRrR0M0U4tpelvAv+47RikVJo0KH5T+/lLfYzsUAk fMCPhG+d2RksvgALzdHExCKdFf3ym1g9RqzVZ070UnnAK8fiwTdjPI69Fys/fslGxEWU IdWeCisDnl7GhdcLkh77YZ02uN7fNduAE5Jwudxmn8QfCmJcpLP0dP5lC+E9H56KBNfM nRmKd9U+RnUJrmL/2LtZdKn9oe61IVxdaGVDTN7iF35j2v89ucEE8eF6G4TkoZz1LDqr HNkjd7AWyGwYBupBo1jtHysRmfQgHkUo45WAlF51TOqXl7ijlahk1htc8fzZDmK3z9mu 4cJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rox/k2TptN5JOKZoxWSQlNUdIsdZrxq63pkyzysm5A4=; b=LSBGtswsjL2XtlOoTBe1JSN3/qxslve1Ix3KtQ0uVQl1aFw7NI6tDb+5Pzyag5s9jH rJoArNus9zlbVs8M3kmGqu/p5f2mT0Tt5/e2+mibP5VVPue/iQUkK7PrdJKD09LJQXtl aBPeiH0+4m6fe3RKXESEjaOtmiDKXWq3X7fmjEzinVyFuQa1ISZ59lJApyEgHOUn8sKR D/w3Mw6zBIK3tBRfgNiMfVROzXS6BrHrX66xxvmUv0ThhV9I9OJGni2BzhnurEbte58J fm1ZVIkptLAOX2/NbL4zgnsnIdL06wrhg3Pp94IvOxOjRWo6E3QKsmKO8Enyljcz1+J8 n0yA== X-Gm-Message-State: ABUngvfZRtp034KyN48DkfEQuvU77kyKjObo1nSBc2NWRwd7WyubAUvdv2RxQ7q4XfYdBkWi/B8dKWreB30+GQ== X-Received: by 10.36.106.76 with SMTP id l73mr1946849itc.115.1478268471285; Fri, 04 Nov 2016 07:07:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.39.68 with HTTP; Fri, 4 Nov 2016 07:07:50 -0700 (PDT) In-Reply-To: References: <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> From: Peter Bowen Date: Fri, 4 Nov 2016 07:07:50 -0700 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 14:07:53 -0000 On Fri, Nov 4, 2016 at 6:33 AM, Ben Laurie wrote: > > The bit you didn't quote does say they the log has to accept valid > certs, tho: "Logs MUST accept certificates and precertificates that > are fully valid according to RFC 5280 [RFC5280] verification rules and > are submitted with such a chain." Sorry about that. So the three MUSTs together are: - Logs MUST verify that each submitted certificate or precertificate has a valid signature chain to an accepted trust anchor, using the chain of intermediate CA certificates provided by the submitter. - Logs MUST reject submissions without a valid signature chain to an accepted trust anchor. - Logs MUST accept certificates and precertificates that are fully valid according to RFC 5280 verification rules and are submitted with such a chain. When I read these together, I read that Logs must accept _any_ certificate that is fully valid according to RFC 5280 verification rules and chains to any root the log trusts and logs must _only_ log such certificates (and no others). If this is accurate, we need to account for all types of certificates being logged, as a log cannot choose to reject certificates for usages other than server authentication and the log cannot reject certificates that have personal information (e.g. an server authentication certificate that states which human requested the certificate in the subject). This seems like a very strong assertion of policy rather than a technical discussion of how the CT protocol works. I would again ask the WG to reconsider the requirement levels specified in this section. Thanks, Peter From nobody Fri Nov 4 07:28:48 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF8E129503 for ; Fri, 4 Nov 2016 07:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi9U4Mf0-h8v for ; Fri, 4 Nov 2016 07:28:39 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296491294DC for ; Fri, 4 Nov 2016 07:28:38 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id h14so88043895ywa.2 for ; Fri, 04 Nov 2016 07:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g1khPCyIyhT2YE2mo0nxnhjCTnmq1R9OG5hh6h2abL8=; b=Yf1PFJdei0EPb8KilV65D3382msUKPCNBk6FkQJkn0j4nicvhV3H0HW8+0ojIhSW/4 rWlMT9d84ZEU8omWVR3/DSlY6iktUxbk1m/hjekMxKNNZtPoIXpxdaVNQAubyFB+PMwl 8RJIqkznsnVxXxJILufDDX4KtTZGS0AO/YxzNUdOx3wpSeCcfWh/vnUkWylGKoXgKPHt yLUzvdPMQ/WpwPCDBshDYrfVV49e4Gi7P/x2dEz+qNrzY8JrqgbMyfw1+abNXg4KSaeY rhwrcZB3UJPzjnIxZnIMmQ05bgeTBwfYmW11g8EXFQyOdQytbj5HVytk2woA6CScNw1c XKmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g1khPCyIyhT2YE2mo0nxnhjCTnmq1R9OG5hh6h2abL8=; b=EsoqzFgFOY2g5Z0OadeRfovsG5KSZTQq5DjPHh87QFLw6zlv0ju7loNbrnUpTFCCUt 0dmBPw1+XSX5MIdXWTIxaCL7LHHEHUC0D2kRhK7w5beYCqQyuCaYNjd1wR4n+YpGiqkx DS31j0TphXsiXIg/7UVIf3RFnSgVKsFysPTOX2gV/AMZ/lujYoVVaM8ZAM6tYYTqQEEv UcTzRIcYVq/gxo/bg42n2mPfpgSzCITy+ulfLV5Kr2zLJCBp5oYCk/tnhV3FGVW+vv5H k0EX39h0mN4uDoIOG/inzi+JhigNLiMtTfutpY3C14QzVmp7NRly+dk5TblVmogyifpY dz1Q== X-Gm-Message-State: ABUngvcHGHKwt6yHZUngowXb6r+zgu1cLN+oXQmXAHqcwnFm3b9giHWow6JpA2yM4rAdn52yHuBUoVO6R3h6G87S X-Received: by 10.107.17.205 with SMTP id 74mr13214518ior.96.1478269717106; Fri, 04 Nov 2016 07:28:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.195.226 with HTTP; Fri, 4 Nov 2016 07:28:35 -0700 (PDT) In-Reply-To: <8229e7fa-9763-41b7-b08b-ce1286dcb389@chromium.org> References: <8229e7fa-9763-41b7-b08b-ce1286dcb389@chromium.org> From: Pierre Phaneuf Date: Fri, 4 Nov 2016 14:28:35 +0000 Message-ID: To: "Florian M." Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Certificate Transparency Policy , trans@ietf.org, certificate-transparency Subject: Re: [Trans] [ct-policy] Re: Certificate Transparency Mirrors (experimental) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 14:28:43 -0000 On Fri, Nov 4, 2016 at 1:42 PM, Florian M. wrote: > if, for whatever reason, a get-entries response is corrupted, the root hash > will be incorrect. If the user has no access to intermediate STH, there is > no way to narrow down and track the corrupted get-entries result. The user > can only start over. That's not entirely true, there's a strategy you can use to find where the corruption occurred. If the root hash of the whole Merkle tree doesn't compute correctly, you can do a binary search for the corrupted entry, by using the MerkleTree::RootAtSnapshot method in the C++ implementation (for example) to compute the root hash of your tree at half the size, and do a get-sth-consistency between that tree size and the full one. If the proof applies correctly, then you know the entries below are good, and you can repeat the operation, until you isolate the tree size that stops validating with the consistency proof. You could then drop all the entries from there on and resume from there (simpler), or maybe just re-fetch a chunk and recompute the Merkle tree (hoping the corruption was localised). You can also spot check single entries using inclusion proofs. From nobody Fri Nov 4 08:42:28 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC76812958C for ; Fri, 4 Nov 2016 08:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si4dD_2lzUxM for ; Fri, 4 Nov 2016 08:42:25 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405DC129590 for ; Fri, 4 Nov 2016 08:42:25 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id 12so69361268uas.2 for ; Fri, 04 Nov 2016 08:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XD55RBBTge+fwH82DULdl4Ba59U0HsGayQJnE46HbtI=; b=llPa4u6L6H9ZFLvqmCoUVni7kPV+iiG/7zPy5uk6xB7Aep2rCy0nljq4lwEwil+Uyq PpAGF6CtxJTmJSfB5xk6h2Ge0oBCktx+MCKULIDmu2xWwauRQSeBvJJ2UP21pZkWek5L P5bor6JPUvzZc4dzjHefyuElJDSPH3AFM1faOMUr14zF4NnTS5f/5tJ3njx44fHNH/0a bzs1Z0HXYl7wY8mp7aS8ZTIXfeoZjmEGJ3ZiUnkoekjv5G7ZT7FqZsnr6KhT/LnZE+4k ur3rw7H2eLSNAYIYbTvLX8/+JoAyZW5mZMDfpdQGQB1MlMWCB6kiWxNQ8XgXtBBFSukB NXIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XD55RBBTge+fwH82DULdl4Ba59U0HsGayQJnE46HbtI=; b=UzocUtAePAeRLBHQo0Fw7IR/pOxw61ffkQ9y03mo6weVqbmDCpM35KCkamhj/pGUGk dXcsy+76Rsqo1JKK8i1no9yMcqyoLn/4nIAphJruLPWyoYnWHVRLc1MMzw241kFyalOM Gy6Zqf7QdXexrxVVzHJuPV4iF+iS2VuxE6wbhySDpMNaJHuqZlTfQ7ItSGUIbHC5Ma1y /4GTiNDRu7zIRwBVBnudoQsQmp4RZgaQtayaRd6Eyj83nzK/TQFacEK8e4ZJ0JGBr/k4 ULebqmcSNeDp+RamgrDztczQLg+tvatMa9VOrK96RyNuc/9MiU14JbmjOkIJA9yTpdwP VfXw== X-Gm-Message-State: ABUngve6qT2GCjXOmFjZW8xyQstZoBj+Ww8L8b/wHx8+JEHN6TLLmRzMHkTlm1bldnnUEkpqYXX8CBwaGMzjTVKu X-Received: by 10.159.38.133 with SMTP id 5mr8048755uay.102.1478274144180; Fri, 04 Nov 2016 08:42:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.149.203 with HTTP; Fri, 4 Nov 2016 08:42:23 -0700 (PDT) In-Reply-To: References: <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> From: Ben Laurie Date: Fri, 4 Nov 2016 15:42:23 +0000 Message-ID: To: Peter Bowen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 15:42:27 -0000 On 4 November 2016 at 14:07, Peter Bowen wrote: > On Fri, Nov 4, 2016 at 6:33 AM, Ben Laurie wrote: >> >> The bit you didn't quote does say they the log has to accept valid >> certs, tho: "Logs MUST accept certificates and precertificates that >> are fully valid according to RFC 5280 [RFC5280] verification rules and >> are submitted with such a chain." > > Sorry about that. So the three MUSTs together are: > > - Logs MUST verify that each submitted certificate or precertificate > has a valid signature chain to an accepted trust anchor, using the > chain of intermediate CA certificates provided by the submitter. > > - Logs MUST reject submissions without a valid signature chain to an > accepted trust anchor. > > - Logs MUST accept certificates and precertificates that are fully > valid according to RFC 5280 verification rules and are submitted with > such a chain. > > When I read these together, I read that Logs must accept _any_ > certificate that is fully valid according to RFC 5280 verification > rules and chains to any root the log trusts and logs must _only_ log > such certificates (and no others). > > If this is accurate, we need to account for all types of certificates > being logged, as a log cannot choose to reject certificates for usages > other than server authentication and the log cannot reject > certificates that have personal information (e.g. an server > authentication certificate that states which human requested the > certificate in the subject). > > This seems like a very strong assertion of policy rather than a > technical discussion of how the CT protocol works. I would again ask > the WG to reconsider the requirement levels specified in this section. FWIW, I tend to agree. I would also note that operationally, we have already discussed options for logs that are incompatible with these requirements, for example: * sharded logs (e.g. by hash(cert) mod n). * logs that only accept short or long lifetime certificates (this would allow the working set to be reduced in size for CAs that issue a lot of short-lived certs). From florian.maury@gmail.com Fri Nov 4 06:42:08 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797811294FB for ; Fri, 4 Nov 2016 06:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dun-ce6q5RJD for ; Fri, 4 Nov 2016 06:42:06 -0700 (PDT) Received: from mail-vk0-x23b.google.com (mail-vk0-x23b.google.com [IPv6:2607:f8b0:400c:c05::23b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C92B129418 for ; Fri, 4 Nov 2016 06:42:06 -0700 (PDT) Received: by mail-vk0-x23b.google.com with SMTP id x186so38622878vkd.0 for ; Fri, 04 Nov 2016 06:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=BtXSRuHNuRx9Ajm9cHQOht7yuQ5kEU/57zDpqmjdX10=; b=FWTWBdGVhpbRfLSO8lG4vPBN+Nf/CQHxiRHSbEFXSi4gC28SmwT+RXJo7cYR0VI2MB zYfEx5kZLVMq++Rk1GF7CS2QhDQyrvFG6QPPxL5nrWL7ZER/hCX4F0pPFPVu4DpiLM2f y7kxhNRX1Kp4IqjMPAUQ1NxL3gJy/jHgcJGF9W4BL/I+t2dGUXyh/O3cunyCxuNspktG CQQrdW7/ziKB/Nes6YMJG7nOXlhVyDLnD9YxUlZ55db1j0kqg/mF5e7kqZf6zLsLX46N ae6muth2goIUWLupNVkp4TXeKo6BP+xcsq2OVHjT4ePY/BurpBzOoAw73UylUNYC/z6b 4PUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=BtXSRuHNuRx9Ajm9cHQOht7yuQ5kEU/57zDpqmjdX10=; b=knYpXbeRzeRDNy9JluduxoWu5bwLD8rv6ZaaVgti7rYkf24uP96zGr73+xIW31JbPy SrDHBwmiQu30XGod60b4sYADvpB5ZHULzi3Z+HNn3jj+tXrPbh6LZyx2RUavCzNUpZZo OzkMadeaDbd8LafByyzxO8wlp+WKjufqHknI21HdFwcg4+YmS2hvUPJCX36UsFHm6ceQ /6TRXN+yytzFB05Lvl0fCQp8G/PthXZtde9SQWQD5K5kKDD/l6T/Y55lwXN2ZVWl81ma i0WFzhWOO/kPHDDKuOmeywbYZz/efMbUhSUF5sBQza18XPQnNXQ5s5rZC5jsgsi/jyFH HZnw== X-Gm-Message-State: ABUngvcNErtzjQhZ4/OxOaORi/bsvK8jh+Db4C3NxFmqnn5/XahSCzsb8z5uzphkpX5+PZxfBic+ X-Received: by 10.157.54.141 with SMTP id h13mr1613369otc.20.1478266925372; Fri, 04 Nov 2016 06:42:05 -0700 (PDT) X-Google-Already-Archived: Yes X-Google-Already-Archived-Group-Id: fe7fce7372 X-Google-Doc-Id: 4e6d839466988 X-Google-Thread-Id: a8f335da1112abf5 X-Google-Message-Url: http://groups.google.com/a/chromium.org/group/ct-policy/msg/4e6d839466988 X-Google-Thread-Url: http://groups.google.com/a/chromium.org/group/ct-policy/t/a8f335da1112abf5 X-Google-Web-Client: true Date: Fri, 4 Nov 2016 06:42:04 -0700 (PDT) From: "Florian M." To: Certificate Transparency Policy Message-Id: <8229e7fa-9763-41b7-b08b-ce1286dcb389@chromium.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_793_336421361.1478266924827" X-Google-Token: EKyg8sAFp9zuJyDasgk0 X-Google-IP: 86.65.182.2 Archived-At: X-Mailman-Approved-At: Fri, 04 Nov 2016 13:18:14 -0700 Cc: trans@ietf.org, certificate-transparency@googlegroups.com Subject: Re: [Trans] Certificate Transparency Mirrors (experimental) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 13:43:12 -0000 ------=_Part_793_336421361.1478266924827 Content-Type: multipart/alternative; boundary="----=_Part_794_1969092104.1478266924831" ------=_Part_794_1969092104.1478266924831 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi list, I recently developed a small tool to create offline mirrors of some of the logs. I wrote it when I realized that bootstrapping a monitor to try and validate a whole log from scratch can be difficult. The difficulties come from: - a slow download procedure (some log get-entries calls can be relatively slow (seconds and sometimes tens of seconds per query) - if, for whatever reason, a get-entries response is corrupted, the root hash will be incorrect. If the user has no access to intermediate STH, there is no way to narrow down and track the corrupted get-entries result. The user can only start over. I also think that Chrom(e|ium) does not currently fully implement the auditor role. On Fri, Oct 28, 2016 at 1:16 AM, Ryan Sleevi wrote: > Although CT is designed to prevent the damage any one of these > organizations can do, it relies on a fully functioning ecosystem of > gossip and accountability. I've repeatedly made clear that we're > committed to moving towards that system, but I don't think it would be > wise to create a false sense of urgency and suggest it be relaxed. I > say this because relaxing, prior to that robustness, would > particularly benefit organizations who may not be able to ensure their > employees follow proper procedures, or which may not keep up to date > with changes in the log policy, as that could allow for misissuance to > happen without detection, or through coercion. > > Again, we're very much committed to the long term and exploring ways > to relax the policy, but at present, Chrome feels that while it's > reasonable to (for the short-term), trust Google to be honest, it's > not reasonable to trust all logs to do so. Which is why the policy > exists :) As such, I think that Google initiative to set up mirrors is a valid temporary approach, which helps mitigating split view attacks. My tool assists the creation of offline mirrors, by: - downloading the log entries; - building partial tree hashes; - generating Bittorrent metainfo files to allow these mirrors to be downloaded quickly; - providing ways to verify partial downloads. You may find some documentation and the torrents I generated at the following website: https://www.x-cli.eu/ct New torrents will be published every week or so, with the latest entries. The source code of my tool is available at: https://github.com/X-Cli/ATBTCT Cheers, Florian ------=_Part_794_1969092104.1478266924831 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi list,

I recently develope= d a small tool to create offline mirrors of some of the logs.
I wrote it when I realized that bootstrapping a monitor to try = and validate a whole log from scratch can be difficult. The difficulties co= me from:
  • a slow download procedure (some log get-entries = calls can be relatively slow (seconds and sometimes tens of seconds per que= ry)
  • if, for whatever reason, a get-entries response is corrupted, t= he root hash will be incorrect. If the user has no access to intermediate S= TH, there is no way to narrow down and track the corrupted get-entries resu= lt. The user can only start over.

I also= think that Chrom(e|ium) does not=C2=A0currently fully implement the audito= r role.

On Fri, Oct 28, 2016 at 1:16 AM, Ryan Slee= vi wrote:
> Although CT is designed to prevent the damage any = one of these
> organizations can do, it relies on a fully func= tioning ecosystem of
> gossip and accountability. I've rep= eatedly made clear that we're
> committed to moving toward= s that system, but I don't think it would be
> wise to cre= ate a false sense of urgency and suggest it be relaxed. I
> sa= y this because relaxing, prior to that robustness, would
> par= ticularly benefit organizations who may not be able to ensure their
> employees follow proper procedures, or which may not keep up to dat= e
> with changes in the log policy, as that could allow for mi= sissuance to
> happen without detection, or through coercion.<= /div>
>=C2=A0
> Again, we're very much committed to= the long term and exploring ways
> to relax the policy, but a= t present, Chrome feels that while it's
> reasonable to (f= or the short-term), trust Google to be honest, it's
> not = reasonable to trust all logs to do so. Which is why the policy
&g= t; exists :)

As such, I think that Google initiati= ve to set up mirrors is a valid temporary approach, which helps mitigating = split view attacks.

My tool assists the creation o= f offline mirrors, by:
  • downloading the log entries;
  • building partial tree hashes;=C2=A0
  • generating Bittorren= t metainfo files to allow these mirrors to be downloaded quickly;
    • <= li>providing ways to verify partial downloads.

=
You may find some documentation and the torrents I generated at = the following website:


New torrents = will be published every week or so, with the latest entries.

=
The source code of my tool is available at:


Cheers,<= /div>
Florian

------=_Part_794_1969092104.1478266924831-- ------=_Part_793_336421361.1478266924827-- From nobody Sat Nov 5 10:25:35 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166FB129566 for ; Sat, 5 Nov 2016 01:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJmw90uA6AyB for ; Sat, 5 Nov 2016 01:15:23 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B81D1293E8 for ; Sat, 5 Nov 2016 01:15:23 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id n204so113966408qke.2 for ; Sat, 05 Nov 2016 01:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ouZqpVgW2pK3Y61XMcApWf87EiLlS1f1iyvubZ2tvyc=; b=lTXolnLEsEfGJD4C2araNt0LGKxORloUWt7jeT/hBpY7RsSbW545NkPWoxGbcejitP Bx7Z58r3SQ+GAciw4YwQ2vxftfFb5zpg8Y8QKjAP6KLtj8kkeokcieMs8jBt3Ky3jwE+ FTOB8Q81VTrIQx+rIUdqIO8EEwv3Z3cCpQz3gbYLZD3jOEk7G5s+raMZyDlIzzDDYY5s NiOlE2IQhJu6DSBmzGkSQ3wc5uGnW/bNgi69W5Pf6aiXHsMgqvPIUe7O/yi0H7jOIyr8 TOxzE0/tsvlA2XWO7scqcJvcaFqIRfiVwQwOcJH8y2pwPcIcKHTFukX09SxH4gaNLmHM xoIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ouZqpVgW2pK3Y61XMcApWf87EiLlS1f1iyvubZ2tvyc=; b=YzA+XDjKFlB49yYeAM+UfT6qWj17ttMiK+XEwg3QNiea/K0EiOnFpOC6ONpYHiCudh xyD2yACMpKSFgXCTShg+JhywW+AzNz/0Dq5BEWUWLGQ0B4v+Ub3DKYVX6Yky3sbGq8qD zsBka9VZk9QFol5PTecGwUKgigJwRrUtjDEWm2o4okLmFeFhvV04kBb9Np4tTLoKyIwO R52U2LGktfIkXcvZfG/IRS5Kz3CCIRuxh0aV9Y5ssZ54D8tJB9Vk5Nh9yUXaCGuUyd9Q yzoQI6SMmT/5xb9t0MBDwattNXx2t3ZLMCt92BMOZmEcpFCIBH2fGPfetk6wzqaio8ji GTQA== X-Gm-Message-State: ABUngveEKoBak7P00+8bbQP5EVbX2gSEGj8O6fJRelO9BwLwjH52MEuFodBtO1zmNIK5HqC3eSK/Ru0z+72GZg== X-Received: by 10.55.16.147 with SMTP id 19mr16654355qkq.255.1478333722355; Sat, 05 Nov 2016 01:15:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.36.15 with HTTP; Sat, 5 Nov 2016 01:15:01 -0700 (PDT) In-Reply-To: References: <8229e7fa-9763-41b7-b08b-ce1286dcb389@chromium.org> From: Florian MAURY Date: Sat, 5 Nov 2016 09:15:01 +0100 Message-ID: To: Pierre Phaneuf Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Sat, 05 Nov 2016 10:25:34 -0700 Cc: Certificate Transparency Policy , trans@ietf.org, certificate-transparency Subject: Re: [Trans] [ct-policy] Re: Certificate Transparency Mirrors (experimental) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 08:15:25 -0000 Hi lists, I decided to discuss this in private with Pierre, so that we would not spam the list. Here is a summary of our conversation. Pierre, please feel free to comment that report, in case I missed something or if the report is inaccurate. Pierre statement in the previous email is accurate. One could request a consistency proof between a subtree and the latest tree head to check if this subtree contains corrupted data or not. This is an efficient way to detect which entry or set of entries are invalid. Current Google implementations (and some others) are willing to return such proofs. It is however noteworthy that this behavior is not required by RFC6962 and RFC69626-bis current draft. These documents only require that logs be able to return consistency proofs between STHs. This requirement is probably to allow precomputation to limit abusive behavior impacts on log load. Since all subtree roots are not necessarily STHs, the consistency checks suggested by Pierre are nice to have but cannot be expected from all logs. We both agreed that it would be great to have some way to find out previous STH. I would suggest adding a tree_size optional parameter to the v2 get-sth endpoint. If present, the returned STH would be the STH with the greatest tree_size inferior to the tree_size parameter. I have not given it much thoughts and this might not be a good idea. Anyway, this is probably not the right place to discuss this. Pierre's suggestion to use inclusion proofs to verify that a specific entry is consistent is an excellent idea. However, if you don't know for sure which entry or set of entries are corrupted, then we agreed that this check method is less efficient than downloading everything all over again. Finally, Pierre suggested that computing the root hash from the downloaded entries is not sufficient to ensure an entry consistency. Indeed, downloaded data include an extra_data field that should be checked too, by verifying the signature chain up to a trust anchor. This is an excellent idea that I added on my TODO list. Thanks! Cheers, Florian On Fri, Nov 4, 2016 at 3:28 PM, Pierre Phaneuf wrote: > On Fri, Nov 4, 2016 at 1:42 PM, Florian M. wrote: > >> if, for whatever reason, a get-entries response is corrupted, the root hash >> will be incorrect. If the user has no access to intermediate STH, there is >> no way to narrow down and track the corrupted get-entries result. The user >> can only start over. > > That's not entirely true, there's a strategy you can use to find where > the corruption occurred. > > If the root hash of the whole Merkle tree doesn't compute correctly, > you can do a binary search for the corrupted entry, by using the > MerkleTree::RootAtSnapshot method in the C++ implementation (for > example) to compute the root hash of your tree at half the size, and > do a get-sth-consistency between that tree size and the full one. If > the proof applies correctly, then you know the entries below are good, > and you can repeat the operation, until you isolate the tree size that > stops validating with the consistency proof. You could then drop all > the entries from there on and resume from there (simpler), or maybe > just re-fetch a chunk and recompute the Merkle tree (hoping the > corruption was localised). > > You can also spot check single entries using inclusion proofs. From nobody Mon Nov 7 02:54:33 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9BD129682 for ; Mon, 7 Nov 2016 02:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWyVPYGGZtzV for ; Mon, 7 Nov 2016 02:54:29 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F759129A6F for ; Mon, 7 Nov 2016 02:54:28 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id o141so37947532lff.1 for ; Mon, 07 Nov 2016 02:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MhMouIkoGIkQp7DIR+QD/gkDLc8W24jIJG5NHPivViE=; b=ZHiR/Q4/UfOUgEwkac6ckVbGqzcdTegVmthWD3k6OYd9/B7ybB4VXcsGdpdwk2TEi0 Lhg1/ZCpQ3lTE6uMfMO051YlOzvWg6lhCrNWQLxrOe6+ayoEGsStveOoyMctm6jVQIgw EfBMXD9KPYBHZyFKf/pVYQDBCmioQs9OdYouDmUmWb+Pfi94XijnyB/m8HY+2br+/akF WeMGwD9M+wiBd3MSU8ltf+1u6gtAUJXNGqAMw7y+BYItCXYcZbUIY0famx232US1a/nq FDRnl1LO16zLD6rcJBWLcMTjOxHXx72s1Ym7dGmiieF+1ycdYz099Q87Lx1Pww8CVeOD ErzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MhMouIkoGIkQp7DIR+QD/gkDLc8W24jIJG5NHPivViE=; b=VBjtHipo5Rm82kUIHgMHWezNcvFvFjvs4nhvYiv1Kho2jAC4x9Zgg4QHb0UDzBqWFC B+81c69YmaJw4nXSLfZa2det5VdiR6I7xKEslaVMWa/LcjiHhQq/wxx/4o4C0lfnWX9B kbVCVSWbIthSQUvememwy4yV9kfO7l9lzXjDlYxqJKCln3U5Q++e5ZnUpuh3fffIodII XzjX2sNzfrSmQKA8j3xHTOZiIo4QN7CePujPlaqLnaaw7vDVAwunGis9CwZEOwRP+qOX +ZRlawsmbAYsy+vmqsdItJUacW2+h0wqNIMsm0jCm15j1LmaSSJDpde224bC1IsacqGD 0EkQ== X-Gm-Message-State: ABUngveCN7sF78e2IpNNOUJXdce780AsXs502lqpHMjNFMkPS/JOQTdz2+bUbIJZa1218WB/qYkvQs+l3qtKoBJo X-Received: by 10.25.150.210 with SMTP id y201mr3191018lfd.58.1478516066420; Mon, 07 Nov 2016 02:54:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.221.91 with HTTP; Mon, 7 Nov 2016 02:54:25 -0800 (PST) In-Reply-To: References: <8229e7fa-9763-41b7-b08b-ce1286dcb389@chromium.org> From: Paul Hadfield Date: Mon, 7 Nov 2016 10:54:25 +0000 Message-ID: To: Florian MAURY Content-Type: multipart/alternative; boundary=001a114017ceef5da60540b3d887 Archived-At: Cc: Pierre Phaneuf , trans@ietf.org, Certificate Transparency Policy , certificate-transparency Subject: Re: [Trans] [ct-policy] Re: Certificate Transparency Mirrors (experimental) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 10:54:32 -0000 --001a114017ceef5da60540b3d887 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 5, 2016 at 8:15 AM, Florian MAURY wrote: > Hi lists, > > I decided to discuss this in private with Pierre, so that we would not > spam the list. Here is a summary of our conversation. Pierre, please > feel free to comment that report, in case I missed something or if the > report is inaccurate. > > Pierre statement in the previous email is accurate. One could request > a consistency proof between a subtree and the latest tree head to > check if this subtree contains corrupted data or not. This is an > efficient way to detect which entry or set of entries are invalid. > Current Google implementations (and some others) are willing to return > such proofs. It is however noteworthy that this behavior is not > required by RFC6962 and RFC69626-bis current draft. These documents > only require that logs be able to return consistency proofs between > STHs. This requirement is probably to allow precomputation to limit > abusive behavior impacts on log load. Since all subtree roots are not > necessarily STHs, the consistency checks suggested by Pierre are nice > to have but cannot be expected from all logs. > > We both agreed that it would be great to have some way to find out > previous STH. I would suggest adding a tree_size optional parameter to > the v2 get-sth endpoint. If present, the returned STH would be the STH > with the greatest tree_size inferior to the tree_size parameter. I > have not given it much thoughts and this might not be a good idea. > Anyway, this is probably not the right place to discuss this. > Hi Florian, there's been some recent discussion on [trans] about adding a new endpoint for v2 that permits a client to retrieve historic STHs. It sounds like what you are interested in is quite similar. Rob Stradling has taken the proposal for this and created a pull request on the RFC repo: https://github.com/google/certificate-transparency-rfcs/pull/200 Perhaps you could comment there? regards, Paul > > Pierre's suggestion to use inclusion proofs to verify that a specific > entry is consistent is an excellent idea. However, if you don't know > for sure which entry or set of entries are corrupted, then we agreed > that this check method is less efficient than downloading everything > all over again. > > Finally, Pierre suggested that computing the root hash from the > downloaded entries is not sufficient to ensure an entry consistency. > Indeed, downloaded data include an extra_data field that should be > checked too, by verifying the signature chain up to a trust anchor. > This is an excellent idea that I added on my TODO list. Thanks! > > Cheers, > Florian > > On Fri, Nov 4, 2016 at 3:28 PM, Pierre Phaneuf > wrote: > > On Fri, Nov 4, 2016 at 1:42 PM, Florian M. > wrote: > > > >> if, for whatever reason, a get-entries response is corrupted, the root > hash > >> will be incorrect. If the user has no access to intermediate STH, there > is > >> no way to narrow down and track the corrupted get-entries result. The > user > >> can only start over. > > > > That's not entirely true, there's a strategy you can use to find where > > the corruption occurred. > > > > If the root hash of the whole Merkle tree doesn't compute correctly, > > you can do a binary search for the corrupted entry, by using the > > MerkleTree::RootAtSnapshot method in the C++ implementation (for > > example) to compute the root hash of your tree at half the size, and > > do a get-sth-consistency between that tree size and the full one. If > > the proof applies correctly, then you know the entries below are good, > > and you can repeat the operation, until you isolate the tree size that > > stops validating with the consistency proof. You could then drop all > > the entries from there on and resume from there (simpler), or maybe > > just re-fetch a chunk and recompute the Merkle tree (hoping the > > corruption was localised). > > > > You can also spot check single entries using inclusion proofs. > > -- > You received this message because you are subscribed to the Google Groups > "Certificate Transparency Policy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ct-policy+unsubscribe@chromium.org. > To post to this group, send email to ct-policy@chromium.org. > To view this discussion on the web visit https://groups.google.com/a/ > chromium.org/d/msgid/ct-policy/CAKMP%2BkdESqbM-DQ-9egZQzM7kgbzV% > 3DaffU6uwYRHizmTJC_%3Dhg%40mail.gmail.com. > --001a114017ceef5da60540b3d887 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Nov 5, 2016 at 8:15 AM, Florian MAURY <florian.maury@gmail.com> wrote:
H= i lists,

I decided to discuss this in private with Pierre, so that we would not
spam the list. Here is a summary of our conversation. Pierre, please
feel free to comment that report, in case I missed something or if the
report is inaccurate.

Pierre statement in the previous email is accurate. One could request
a consistency proof between a subtree and the latest tree head to
check if this subtree contains corrupted data or not. This is an
efficient way to detect which entry or set of entries are invalid.
Current Google implementations (and some others) are willing to return
such proofs. It is however noteworthy that this behavior is not
required by RFC6962 and RFC69626-bis current draft. These documents
only require that logs be able to return consistency proofs between
STHs. This requirement is probably to allow precomputation to limit
abusive behavior impacts on log load. Since all subtree roots are not
necessarily STHs, the consistency checks suggested by Pierre are nice
to have but cannot be expected from all logs.

We both agreed that it would be great to have some way to find out
previous STH. I would suggest adding a tree_size optional parameter to
the v2 get-sth endpoint. If present, the returned STH would be the STH
with the greatest tree_size inferior to the tree_size parameter. I
have not given it much thoughts and this might not be a good idea.
Anyway, this is probably not the right place to discuss this.

Hi Florian,

there's bee= n some recent discussion on [trans] about adding a new endpoint
f= or v2 that permits a client to retrieve historic STHs.=C2=A0 It sounds like= what you
are interested in is quite similar.

Rob Stradling has taken the proposal for this and created a pull requ= est on

Perhaps you could comme= nt there?

regards,
Paul

Pierre's suggestion to use inclusion proofs to verify that a specific entry is consistent is an excellent idea. However, if you don't know for sure which entry or set of entries are corrupted, then we agreed
that this check method is less efficient than downloading everything
all over again.

Finally, Pierre suggested that computing the root hash from the
downloaded entries is not sufficient to ensure an entry consistency.
Indeed, downloaded data include an extra_data field that should be
checked too, by verifying the signature chain up to a trust anchor.
This is an excellent idea that I added on my TODO list. Thanks!

Cheers,
Florian

On Fri, Nov 4, 2016 at 3:28 PM, Pierre Phaneuf <pphaneuf@google.com> wrote:
> On Fri, Nov 4, 2016 at 1:42 PM, Florian M. <florian.maury@gmail.com> wrote:
>
>> if, for whatever reason, a get-entries response is corrupted, the = root hash
>> will be incorrect. If the user has no access to intermediate STH, = there is
>> no way to narrow down and track the corrupted get-entries result. = The user
>> can only start over.
>
> That's not entirely true, there's a strategy you can use to fi= nd where
> the corruption occurred.
>
> If the root hash of the whole Merkle tree doesn't compute correctl= y,
> you can do a binary search for the corrupted entry, by using the
> MerkleTree::RootAtSnapshot method in the C++ implementation (for
> example) to compute the root hash of your tree at half the size, and > do a get-sth-consistency between that tree size and the full one. If > the proof applies correctly, then you know the entries below are good,=
> and you can repeat the operation, until you isolate the tree size that=
> stops validating with the consistency proof. You could then drop all > the entries from there on and resume from there (simpler), or maybe > just re-fetch a chunk and recompute the Merkle tree (hoping the
> corruption was localised).
>
> You can also spot check single entries using inclusion proofs.

--
You received this message because you are subscribed to the Google Groups &= quot;Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to ct-policy+u= nsubscribe@chromium.org.
To post to this group, send email to ct-policy@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/= CAKMP%2BkdESqbM-DQ-9egZQzM7kgbzV%3DaffU6uwYRHizmTJC_%3Dhg%40= mail.gmail.com.

--001a114017ceef5da60540b3d887-- From nobody Mon Nov 7 03:15:54 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA29129E12 for ; Mon, 7 Nov 2016 03:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5VzYYPELr-T for ; Mon, 7 Nov 2016 03:15:50 -0800 (PST) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD87F129E11 for ; Mon, 7 Nov 2016 03:15:49 -0800 (PST) Received: (qmail 7550 invoked by uid 1004); 7 Nov 2016 11:15:47 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 07 Nov 2016 11:15:47 +0000 Received: (qmail 16713 invoked by uid 1000); 7 Nov 2016 11:15:47 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 07 Nov 2016 11:15:47 +0000 To: Paul Hadfield , Florian MAURY References: <8229e7fa-9763-41b7-b08b-ce1286dcb389@chromium.org> From: Rob Stradling Message-ID: <75df4d95-c923-00bd-4eee-0027d7dbfd8b@comodo.com> Date: Mon, 7 Nov 2016 11:15:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Pierre Phaneuf , trans@ietf.org, Certificate Transparency Policy , certificate-transparency Subject: Re: [Trans] [ct-policy] Re: Certificate Transparency Mirrors (experimental) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 11:15:53 -0000 On 07/11/16 10:54, Paul Hadfield wrote: > Hi Florian, > > there's been some recent discussion on [trans] about adding a new endpoint > for v2 that permits a client to retrieve historic STHs. It sounds like > what you are interested in is quite similar. > > Rob Stradling has taken the proposal for this and created a pull request on > the RFC repo: > https://github.com/google/certificate-transparency-rfcs/pull/200 > > Perhaps you could comment there? A few days ago Melinda wrote: "6962-bis has completed working group last call. Minor editorial changes are fine, but let's try to avoid major changes that would require yet another WGLC." I don't yet know if the Chairs consider a new endpoint to be a "major change". -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Nov 7 03:26:35 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CB012969E for ; Mon, 7 Nov 2016 03:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DX1cY80qbYGU for ; Mon, 7 Nov 2016 03:26:30 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0088.outbound.protection.outlook.com [104.47.32.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22946129E1B for ; Mon, 7 Nov 2016 03:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n5FSHGlsQP6EbFP/mbflOnaeSsd/STLbN8JlS5k4tgc=; b=fSGgw9d2XCer8SxtLeyNlfOuARklFSLWUC17ds47aENT73Hlzs8WSjXlWZJKe69VXKIwzl59zMfe1SKNmxnu/lvME0b9uHxKtiZuljlI0VvQ6CnRj/xqHNfCPpFWpgyFserBE1YjsONESXsQTUgNNcmQERxeVDfSnsZnDlpoNoQ= Received: from BN6PR06MB3025.namprd06.prod.outlook.com (10.173.141.23) by BN6PR06MB3026.namprd06.prod.outlook.com (10.173.141.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Mon, 7 Nov 2016 11:26:28 +0000 Received: from BN6PR06MB3025.namprd06.prod.outlook.com ([10.173.141.23]) by BN6PR06MB3025.namprd06.prod.outlook.com ([10.173.141.23]) with mapi id 15.01.0707.006; Mon, 7 Nov 2016 11:26:28 +0000 From: Robin Wilton To: Stephen Farrell Thread-Topic: [Trans] Topicality Thread-Index: AQHSLnmVNtEZ+kSnUku+FO6fLILZoaDC9XIAgAAypQCAADLBgIAEGuYAgAAOOQCAAA8qgIAAAyuAgAAZdICABcbd4Q== Date: Mon, 7 Nov 2016 11:26:28 +0000 Message-ID: <1E8966F8-7F18-4505-95E4-DCE5F27BA1B1@isoc.org> References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [82.37.250.203] x-ms-office365-filtering-correlation-id: 3f86bb7a-35a0-4410-c8f2-08d40700eac8 x-microsoft-exchange-diagnostics: 1; BN6PR06MB3026; 7:zLeCyvLJWNycPbL1EssKDFPrRTZhTktrAcwviv0lKM4ia4pYM+a++jnq3A0g211RRISOiSPnpHQAGGh5feslojYdwoEuDQ9JDNk65VSPFjgeJ3BsT6RSxXh+AITaZ6jz7RARxQmN65gqGNLd06vUE53Ucr8BN+dNepBwbSg01kGL4iB2kfLJ8t5IkSI9oVtkfQrZpXk/3fePLbXlQACbW/BqzV/fP14aEgY6wJkQaPPgdALNlsO83WsKwETLytjCxDPt7jPdTWMKNChvCRNYTw1F3MobFVtwSpxr3oAs/oQCFIao1xwg6XsQnTdnX5DvkSdOL8dEdEHltuOzToou8NPco6/01vfw0Mtq7RkDYHc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB3026; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN6PR06MB3026; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB3026; x-forefront-prvs: 0119DC3B5E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(13464003)(199003)(377454003)(52314003)(189002)(93886004)(3660700001)(66066001)(586003)(6116002)(102836003)(3846002)(2906002)(15975445007)(2950100002)(6916009)(2900100001)(3280700002)(4326007)(110136003)(7846002)(122556002)(68736007)(82746002)(83716003)(81166006)(81156014)(189998001)(87936001)(8676002)(36756003)(8936002)(7736002)(50986999)(305945005)(101416001)(33656002)(97736004)(86362001)(19580395003)(19580405001)(92566002)(10400500002)(77096005)(5660300001)(5002640100001)(105586002)(106356001)(106116001)(99286002)(76176999)(54356999)(11100500001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR06MB3026; H:BN6PR06MB3025.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2016 11:26:28.4372 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB3026 Archived-At: Cc: "trans@ietf.org" , Melinda Shore , Ben Laurie , Peter Bowen , Jeremy Rowley Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 11:26:33 -0000 On 3 Nov 2016, at 19:13, "Stephen Farrell" wrot= e: >=20 >=20 > On 03/11/16 17:42, Jeremy Rowley wrote: >> Unlike the certificate, which can be deleted, revoked, or in some other = way >> removed from the CA's database and the server, a certificate cannot be >> removed from a CT log, meaning it's impossible to delete PII in complian= ce >> with the EU directive.=20 >=20 > Again - there is no "EU directive" that calls for deletion of > this PII, that's just speculation. +1; and, much as I hate to draw attention to something which I think is bou= nd to be misused (not by the CT community, I hasten to clarify...), the Dat= a Protection Directive and the GDPR both contain a provision for processing= of personal data "in the legitimate interests of the data controller". It = seems to me that CT could build a strong case on that basis, since maintena= nce of an audit trail of certificate-related activity is its raison d'=EAtr= e. Yrs., Robin >=20 > S. >=20 >>=20 >> -----Original Message----- >> From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ben Laurie >> Sent: Thursday, November 3, 2016 11:31 AM >> To: Peter Bowen >> Cc: Melinda Shore ; trans@ietf.org; Stephen Far= rell >> >> Subject: Re: [Trans] Topicality >>=20 >> On 3 November 2016 at 16:36, Peter Bowen wrote: >>> On Thu, Nov 3, 2016 at 8:45 AM, Ben Laurie wrote: >>>> On 1 November 2016 at 01:04, Peter Bowen wrote: >>>>>=20 >>>>> There are certificates that have personal information (e.g. given=20 >>>>> name, surname, and physical location) in the subject distinguished=20 >>>>> name or the subject alternative names. It is very possible that=20 >>>>> there may be a desire to redact this information (in fact it could=20 >>>>> even be required in some jurisdictions as CT could be considered a >> database). >>>>> We already see this with domains in many countries where the full=20 >>>>> registrant details are not publicly available. >>>>>=20 >>>>> Additionally, while 6962-bis does focus on certificates used for TLS= =20 >>>>> server authentication, there are other types of certificates that=20 >>>>> could be logged. For example a certificate that is used with email=20 >>>>> and contains both the email address and given/surname. It might be=20 >>>>> that the owner of the certificate only wishes to disclose this=20 >>>>> binding to people receiving email from them rather than publicly=20 >>>>> disclosing it. We have also seen requests for certificates that=20 >>>>> cover phone numbers. A similar situation would apply -- having an >> "unlisted" >>>>> number should be possible, where the subject details (other than=20 >>>>> phone >>>>> number) are only known to a group of people who communicate with the= =20 >>>>> number. >>>>=20 >>>> For these use cases, something CONIKS-like is probably more appropriat= e. >>>=20 >>> How does CONIKS doesn't solve the problem of server authentication=20 >>> certificates that identify an individual as the certificate=20 >>> subscriber? >>=20 >> Sorry, I was referring to the latter cases - e.g. S/MIME (which is what = you >> seem to be describing). >>=20 >>> Even if we assume for the moment that 6962bis is only for=20 >>> "traditional" PKI and only for server authentication, these certs are= =20 >>> still problematic to log unredacted. >>=20 >> Since the personal info in those cases is not relevant to browsers >> validation of the cert, in principle I can't see why we would care if it >> were redacted. OTOH, the certificate is public anyway, so not sure why >> redacting it in the log is useful. >>=20 >> The real problem is the certificate, not the log entry! >>=20 >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >>=20 >>=20 >>=20 >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >>=20 >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Mon Nov 7 05:36:04 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9076512965A for ; Mon, 7 Nov 2016 05:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OJU-WWqLIfU for ; Mon, 7 Nov 2016 05:35:58 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0086.outbound.protection.outlook.com [104.47.42.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B6F129633 for ; Mon, 7 Nov 2016 05:35:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RJDzu9ldfSgooNCrtMoBWE8ouodQAUAbQN0/zWUpOxc=; b=m/4avxIhAzE/7v2cfWjDE6m0sNB+S1tGazUkXVyfId/DnnYDVj/BzciM/BirnlDylpvC9eBP0Zw+bthFPsjOSHAtQCOmSPd6AckmlvLUHTczGAUdzhBLoW2bvf7yqlJ2wCAmuc/RlTlUhlQwn44pHeQ1puTUvUufCtNWok6GVzo= Received: from BN6PR06MB3025.namprd06.prod.outlook.com (10.173.141.23) by BN6PR06MB3025.namprd06.prod.outlook.com (10.173.141.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Mon, 7 Nov 2016 13:35:56 +0000 Received: from BN6PR06MB3025.namprd06.prod.outlook.com ([10.173.141.23]) by BN6PR06MB3025.namprd06.prod.outlook.com ([10.173.141.23]) with mapi id 15.01.0707.006; Mon, 7 Nov 2016 13:35:56 +0000 From: Robin Wilton To: Stephen Farrell Thread-Topic: [Trans] Topicality Thread-Index: AQHSLnmVNtEZ+kSnUku+FO6fLILZoaDC9XIAgAAypQCAAr64AIAABFSAgAACAICAAAgTgIAHpZLj Date: Mon, 7 Nov 2016 13:35:55 +0000 Message-ID: References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> <501775b31e9a49ec962512b7aa48e3cd@EX2.corp.digicert.com> <256566a33bd642368f46cdb62dba4eee@EX2.corp.digicert.com>, <1a797dfa-eb0d-f5df-9401-a6f1dfa4e1dc@cs.tcd.ie> In-Reply-To: <1a797dfa-eb0d-f5df-9401-a6f1dfa4e1dc@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [82.37.250.203] x-ms-office365-filtering-correlation-id: 4d8c2c41-67fc-44be-22ca-08d407130083 x-microsoft-exchange-diagnostics: 1; BN6PR06MB3025; 7:XghWSaBOiyQVbgM6W9C3ks23lwN0+WwlTVA8ZZonYycaB8cX9DPbklZFA/cUjFIDKAnQpjmB39YC3fDiXwd+AkCTdDlKzHgdKA4z4ZUh5xItWe+Q1NfDokIftmB6Emx7MCY3u8TtuzYHKCjzWqoXSlFGra4+GtusZAgHAZhXbneQcHspwACJYub2WX3QeuCfqFN7SxU/tl3oEio2c11ioFsB9xKcGvYIt9SSK5HTW5rJOB0Hi0sjeHBCWG3jiABCSzIx2ao302ChXgA2G/BxxBNB2i3m5Lgzj1AaGtE/HI40ErZ7qp96PALoA6YaZDUtSB7VZXwq66S6b9k7uVf5NTDcdEmSch4KVUnNn0DV5PE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB3025; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(72170088055959); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN6PR06MB3025; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB3025; x-forefront-prvs: 0119DC3B5E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(13464003)(377454003)(24454002)(189002)(199003)(3660700001)(122556002)(3280700002)(7736002)(7846002)(305945005)(8936002)(101416001)(86362001)(50986999)(54356999)(76176999)(33656002)(92566002)(10400500002)(68736007)(11100500001)(189998001)(93886004)(81156014)(2900100001)(81166006)(19580405001)(19580395003)(5002640100001)(97736004)(82746002)(8676002)(5660300001)(106116001)(106356001)(3846002)(6916009)(102836003)(6116002)(2950100002)(99286002)(110136003)(586003)(105586002)(36756003)(2906002)(77096005)(15975445007)(66066001)(83716003)(4326007)(87936001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR06MB3025; H:BN6PR06MB3025.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2016 13:35:55.8027 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB3025 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen , Jeremy Rowley Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 13:36:00 -0000 On 2 Nov 2016, at 16:49, "Stephen Farrell" wrot= e: >=20 >=20 > On 02/11/16 16:20, Jeremy Rowley wrote: >> Wacky court decisions are always a risk. However, the EU has >> established that data collectors must delete public facing personal >> information at the information holder's request.=20 >=20 > I don't believe "delete" is right there - search engines gave > different results when queried in different ways or from > different places and the underlying sources (e.g. newspaper > articles) weren't affected directly IIUC. While that is an > evolving situation I'm not sure we can safely conclude what > any of it might mean for CT. (Or for CRLs I guess if we > want to get into speculation;-) Correct. The "Google Spain" ruling specified that under certain circumstanc= es, search engines should "de-list" results identifying the claimant by nam= e. As Stephen says, the ruling didn't oblige data controllers to delete the= material itself.=20 Whether or not the court expressed this as part of its rationale (I don't k= now), part of the practical issue they we trying to address was the ease wi= th which copies of the material could be published. The court chose to make= it harder to locate the material, rather than try to stamp it all out at s= ource. HTH, Robin >=20 > S >=20 >> There's a big >> difference between planning for unknown legal changes and accounting >> for decisions already made. By requiring logging of PII, we're >> essentially asking logs to fail on a regular basis. Although >> redaction of subject info doesn't guarantee a log won't fail because >> of a right to be forgotten request, it does move logs in the >> direction of compliance. >>=20 >> Jeremy >>=20 >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, November 2, 2016 >> 10:13 AM To: Jeremy Rowley ; Peter Bowen >> ; Melinda Shore Cc: >> trans@ietf.org Subject: Re: [Trans] Topicality >>=20 >>=20 >>=20 >> On 02/11/16 15:57, Jeremy Rowley wrote: >>> Here's what we are dealing with on this front: >>>=20 >>> The EU has a right to be forgotten which requires a data >>> controller to remove data that is no longer necessary or >>> irrelevant for the original purposes for which the data was >>> collected. Primarily, courts have interpreted this as requiring a >>> search engine to remove information about a person at that >>> individual=92s request. This has caused consider headaches for >>> Google. >>>=20 >>> CT monitors are likely considered a search engine that identify=20 >>> certificates with personal information included. However, CT, by=20 >>> design, cannot delete information from logs and any deletion will=20 >>> cause the log to fail. This puts CT at odds with EU privacy laws >>> as certificate subjects often contain individual information, >>> email addresses specified in the SANs, and SANS DNS entries that >>> identify an individual (albeit this is a stretch). >>>=20 >>> I'm having trouble reconciling how a monitoring service/log >>> operator is supposed to comply with the EU requirements without >>> supporting redaction. >>=20 >> What makes you think redaction would help? If anything from the entry >> in the log correlates with the cert then some wacky court could >> decide who knows what... Particularly with stuff like that so-called >> right to be forgotten, I'm not clear that we can plan ahead and guess >> what courts might or might not decide. (And IANAL of course:-) >>=20 >> S. >>=20 >> PS: As with the rest of this thread, the above is with no hats. >>=20 >>>=20 >>> Jeremy >>>=20 >>>=20 >>> -----Original Message----- From: Trans=20 >>> [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Farrell Sent:=20 >>> Monday, October 31, 2016 4:03 PM To: Peter Bowen >>> ; Melinda Shore Cc: >>> trans@ietf.org Subject: Re: [Trans] Topicality >>>=20 >>>=20 >>> Peter, >>>=20 >>> On 31/10/16 19:01, Peter Bowen wrote: >>>> On Mon, Oct 24, 2016 at 9:37 PM, Melinda Shore=20 >>>> wrote: >>>>> You may have seen the recent announcement from the Chrome team=20 >>>>> that as of October 2017 certificates will need to comply with=20 >>>>> Chrome's CT policy in order to be trusted. There was also an=20 >>>>> invitation to discuss that on the trans mailing list. This is >>>>> a reminder that mailing list discussions need to remain focused >>>>> on the specifications being produced by the working group - >>>>> that is to say, policies related to individual implementations >>>>> are out of scope for the working group except to the extent >>>>> that they bear on decisions related to our working group >>>>> drafts. >>>>=20 >>>> Paul and Melinda, >>>>=20 >>>> Do you consider discussion of use cases for privacy to be >>>> in-scope for this group or do you consider only the technical >>>> implementation of privacy (e.g. section 4 of 6962-bis and the >>>> redaction draft) to be in-scope? >>>=20 >>> (Wearing no IETF hat, but perhaps the hat of someone interested in=20 >>> privacy...) >>>=20 >>> I do not believe that it makes sense for us to talk as if privacy >>> was a concept that applies to corporate entities. >>>=20 >>> I do believe that your text above conflates privacy (a human >>> concept) with corporate secrecy (a useful but different thing) in >>> ways that are in the end damaging to both. (I further and even >>> moreso believe that such conflation would be damaging to the IETF >>> were we to slip into the bad practice of not calling out that >>> terminological sloppiness.) >>>=20 >>> I totally get that redaction has utility for folks who need >>> corporate secrecy on a temporary basis. I absolutely do not accept >>> that that has any privacy aspect. >>>=20 >>> Can you call out the privacy aspect that applies to humans and >>> that is a real part of the question related to support for >>> redaction in CT? >>>=20 >>> Thanks, S. >>>=20 >>>=20 >>>>=20 >>>> Thanks, Peter >>>>=20 >>>> _______________________________________________ Trans mailing >>>> list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans >>>>=20 >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ Trans mailing list=20 >> Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans >>=20 >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Mon Nov 7 05:51:33 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC249127735 for ; Mon, 7 Nov 2016 05:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCIXpRJ3z059 for ; Mon, 7 Nov 2016 05:51:26 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0067.outbound.protection.outlook.com [104.47.34.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF08E1296CF for ; Mon, 7 Nov 2016 05:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TmjCaXh7OECv0ab1QmKt5q7UykxPcxZirKRyaSm4b5w=; b=nwQUELBnIFo6Ub4x7D7uKHSDaqj4j5+nOmq76wW6gI1+bn4DoPxIpffdRLQUTTT+luV6TjAkRvmk2tU/Fu9l1aLqcgey2WbNeTwUVx6+4pJneEuv6i8jPYl6QSNk3JD+96Aza0ZooW0owLOID6Gk/DoDmiy4SJ9P0LcziabNsBs= Received: from BN6PR06MB3025.namprd06.prod.outlook.com (10.173.141.23) by BN6PR06MB3026.namprd06.prod.outlook.com (10.173.141.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Mon, 7 Nov 2016 13:51:25 +0000 Received: from BN6PR06MB3025.namprd06.prod.outlook.com ([10.173.141.23]) by BN6PR06MB3025.namprd06.prod.outlook.com ([10.173.141.23]) with mapi id 15.01.0707.006; Mon, 7 Nov 2016 13:51:25 +0000 From: Robin Wilton To: Jeremy Rowley Thread-Topic: [Trans] Topicality Thread-Index: AQHSLnmVNtEZ+kSnUku+FO6fLILZoaDC9XIAgAAypQCAAr64AIAHuEw8 Date: Mon, 7 Nov 2016 13:51:24 +0000 Message-ID: <046F4FED-5B2C-4CF2-9732-DDE6766BD04C@isoc.org> References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie>, <501775b31e9a49ec962512b7aa48e3cd@EX2.corp.digicert.com> In-Reply-To: <501775b31e9a49ec962512b7aa48e3cd@EX2.corp.digicert.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [82.37.250.203] x-ms-office365-filtering-correlation-id: 8452214b-188b-4a62-c63b-08d407152a3e x-microsoft-exchange-diagnostics: 1; BN6PR06MB3026; 7:VwwXGCW6Hz8rnrtMhn50afmcLYwm4Oi97V2TCjrrvxXpE5e6zi0c6xy8zcy/swo9Z/sQ/4L6n28qW8ksPspiAgqav/zYdNRi8slBpjSBaFQyPvkVMZ8EabL6I554IJSg0qFwAaFnGGzKgDMYTx4XSoY90wMwmEY60aXbpYIB8VpCLv5Ln3iR75H0Df3gl4acP4miY7U75ITD7O6P8nVZja2t9AKr8jP7872HsIrC92fMxukAxCbFnl/f2Uen/uTNfm+AAKLmt7yC9dsu3Iy/n6uU/ZOl5kKEBdNf4dGWkw7iinBXWGaKZhubfCA09GazVGAN1AOQYZqWyxQlUJUoRFGeOo/GYrh+PyIfEa5uOL0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB3026; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(72170088055959); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN6PR06MB3026; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB3026; x-forefront-prvs: 0119DC3B5E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(13464003)(199003)(377454003)(189002)(93886004)(3660700001)(66066001)(586003)(6116002)(102836003)(3846002)(2906002)(15975445007)(2950100002)(6916009)(2900100001)(3280700002)(4326007)(110136003)(7846002)(122556002)(68736007)(82746002)(83716003)(81166006)(81156014)(189998001)(87936001)(8676002)(8936002)(36756003)(7736002)(305945005)(101416001)(50986999)(33656002)(97736004)(86362001)(19580405001)(19580395003)(92566002)(10400500002)(77096005)(5660300001)(5002640100001)(105586002)(106116001)(106356001)(99286002)(54356999)(76176999)(11100500001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR06MB3026; H:BN6PR06MB3025.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2016 13:51:24.7654 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB3026 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen , Stephen Farrell Subject: Re: [Trans] Topicality X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 13:51:29 -0000 One last comment and then I'll leave this alone; Apologies, too, for chimin= g in late, but I was away last week... Robin Wilton Technical Outreach Director - Identity and Privacy On 2 Nov 2016, at 15:58, "Jeremy Rowley" wrote= : > Here's what we are dealing with on this front: >=20 > The EU has a right to be forgotten which requires a data controller to re= move data that is no longer necessary or irrelevant for the original purpo= ses for which the data was collected. Primarily, courts have interpreted th= is as requiring a search engine to remove information about a person at tha= t individual=92s request. This has caused consider headaches for Google.=20 There's a long-standing privacy principle that data should not be retained = for longer than is necessary for the purpose for which it was collected*. T= he simplest defence against possible "wacky" court decisions is for CT oper= ators to be transparent about what they are logging, why, and how long they= expect the data to be needed for. If you say "we collect this data in orde= r to produce an audit trail of CA activity, and because the data is of most= use retrospectively we expect to need to keep it for [n] years", you estab= lish a clear baseline during which, in the absence of any other specific pr= ivacy harms, your legitimate default position can be to retain the data. It does, however, imply that a log owner should have a process for deleting= log data at the end of that n-year period. The good news is that CT log d= ata, by its very nature, is already conveniently time-stamped, batched, etc= ., so managing its expiry should not require any changes to the data schema= itself. (Very few data controllers put this into practice, regrettably, but that's = a whole other rant). Yrs., Robin >=20 > CT monitors are likely considered a search engine that identify certifica= tes with personal information included. However, CT, by design, cannot dele= te information from logs and any deletion will cause the log to fail. This = puts CT at odds with EU privacy laws as certificate subjects often contain = individual information, email addresses specified in the SANs, and SANS DNS= entries that identify an individual (albeit this is a stretch).=20 >=20 > I'm having trouble reconciling how a monitoring service/log operator is s= upposed to comply with the EU requirements without supporting redaction.=20 >=20 > Jeremy >=20 >=20 > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Monday, October 31, 2016 4:03 PM > To: Peter Bowen ; Melinda Shore > Cc: trans@ietf.org > Subject: Re: [Trans] Topicality >=20 >=20 > Peter, >=20 > On 31/10/16 19:01, Peter Bowen wrote: >> On Mon, Oct 24, 2016 at 9:37 PM, Melinda Shore = wrote: >>> You may have seen the recent announcement from the Chrome team that=20 >>> as of October 2017 certificates will need to comply with Chrome's CT=20 >>> policy in order to be trusted. There was also an invitation to=20 >>> discuss that on the trans mailing list. >>> This is a reminder that mailing list discussions need to remain=20 >>> focused on the specifications being produced by the working group -=20 >>> that is to say, policies related to individual implementations are=20 >>> out of scope for the working group except to the extent that they=20 >>> bear on decisions related to our working group drafts. >>=20 >> Paul and Melinda, >>=20 >> Do you consider discussion of use cases for privacy to be in-scope for=20 >> this group or do you consider only the technical implementation of=20 >> privacy (e.g. section 4 of 6962-bis and the redaction draft) to be=20 >> in-scope? >=20 > (Wearing no IETF hat, but perhaps the hat of someone interested in privac= y...) >=20 > I do not believe that it makes sense for us to talk as if privacy was a c= oncept that applies to corporate entities. >=20 > I do believe that your text above conflates privacy (a human > concept) with corporate secrecy (a useful but different thing) in ways th= at are in the end damaging to both. (I further and even moreso believe that= such conflation would be damaging to the IETF were we to slip into the bad= practice of not calling out that terminological sloppiness.) >=20 > I totally get that redaction has utility for folks who need corporate sec= recy on a temporary basis. I absolutely do not accept that that has any pri= vacy aspect. >=20 > Can you call out the privacy aspect that applies to humans and that is a = real part of the question related to support for redaction in CT? >=20 > Thanks, > S. >=20 >=20 >>=20 >> Thanks, >> Peter >>=20 >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >>=20 >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From bryan.ford@epfl.ch Thu Nov 10 03:37:28 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42CA129603 for ; Thu, 10 Nov 2016 03:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkdXfSu0vZmb for ; Thu, 10 Nov 2016 03:37:26 -0800 (PST) Received: from smtp0.epfl.ch (smtp0.epfl.ch [IPv6:2001:620:618:1e0:1:80b2:e058:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B49B12958A for ; Thu, 10 Nov 2016 03:37:26 -0800 (PST) Received: (qmail 21693 invoked by uid 107); 10 Nov 2016 11:37:18 -0000 X-Virus-Scanned: ClamAV Received: from rexa.epfl.ch (HELO REXA.intranet.epfl.ch) (128.178.50.11) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTP; Thu, 10 Nov 2016 12:37:19 +0100 Received: from REXF.intranet.epfl.ch (128.178.50.53) by REXA.intranet.epfl.ch (128.178.50.11) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 10 Nov 2016 12:37:18 +0100 Received: from REXF.intranet.epfl.ch ([fe80::6c1e:95ab:3984:37fc]) by rexf.intranet.epfl.ch ([fe80::6c1e:95ab:3984:37fc%22]) with mapi id 15.00.1178.000; Thu, 10 Nov 2016 12:37:18 +0100 From: Ford Bryan To: Trans Thread-Topic: Threat model Thread-Index: AQHSO0bK7OjTFr+jwUqQPhZRgMdWbg== Date: Thu, 10 Nov 2016 11:37:18 +0000 Message-ID: <18D520ED-3C2B-48BB-9314-79FA157CB48B@epfl.ch> Accept-Language: en-US, fr-CH Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [50.251.152.5] Content-Type: multipart/signed; boundary="Apple-Mail=_5319F61D-EA2A-455F-AD8B-ED49386013BA"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: [Trans] Threat model X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 11:38:47 -0000 --Apple-Mail=_5319F61D-EA2A-455F-AD8B-ED49386013BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I haven=E2=80=99t had time to keep up on this list in a long time so = sorry if I=E2=80=99m out of the loop. But given recent events, I just = needed to ask once more=E2=80=A6 Do you all still feel that an adversary who can (a) control the = victim=E2=80=99s network access, (b) acquire any one CA key, and (c) = acquire any two log server keys is not a sufficiently realistic threat = model for CT to motivate the incorporation of collective witness = cosigning? Background reminder: - = https://freedom-to-tinker.com/2016/03/10/apple-fbi-and-software-transparen= cy/ - http://dedis.cs.yale.edu/dissent/papers/witness-abs Thanks Bryan --Apple-Mail=_5319F61D-EA2A-455F-AD8B-ED49386013BA Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ8jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBTswggQjoAMCAQICEHrwz+c6WsXcpTunbADfRSwwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNjA2MjQwMDAwMDBaFw0xNzA2 MjQyMzU5NTlaMCMxITAfBgkqhkiG9w0BCQEWEmJyeWFuLmZvcmRAZXBmbC5jaDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANjcUl9X0BRf5Wuzjh6EC6Q5RgjJZKXExgk0vL5SqUNjB/M/ VGRHc7reosM6zEPSfSwwKTZfQ+DTAvdpwgEV0mV0nVbN5AEdvgLcf6dyI79iTA2eED3+voKyEq3R 8mKPwaOROsV2A/ruEbFf7AeS6kHdNtZ4Fn8zOP4YaWwniAhPGuFWD7WQrXjFBFJNd3NvGlGafsAU LcVfi/whzRiNpQKZOzq4Ez6Y9cfDWl/zJAPJv9BAVNhZgdGUC6X4rARQgy0ycVap7GB4qUPNlu2B dT4Z/QAFWbAIj6mYtLpZPmE1roxOcTaPYrLJTHlkgonSltwx2CHILqhFgeKUpdnZPDkCAwEAAaOC AfAwggHsMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBS5U2J+yoON B9xIAKw9244mR/YiCDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0G A1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgG CCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHQYDVR0RBBYwFIESYnJ5YW4uZm9yZEBlcGZsLmNoMA0GCSqGSIb3DQEBCwUA A4IBAQBOEPgbDA2paw0LkOn7XlFiKLXGE6Vc9qML8U6+mFCSdQn+VzGoJlLykGb66nKTkNjpiOB1 WiZQIRdrdDxpA2f+rtt/jeJFX5LI1g85jEKUJ6YttBMrGGAGW2KEoNMsbLExOhZ1G1UKYVVRiKuG ddDVo/JNSsUUF0uZSAIYi7wm8qGKe2xNBOiXlfhx0uaJx0dHZsNINE6yor4EfkvPxMwvSKSDwqX0 jipS/Xi28B8j7a0LqXey6Pe8B80y93bTWBn5UxmxVHWCX9JSAh0rEZ+HthUvQ0cXlAkvBP9GVf5Z fX49lF0+jw/8qgS2apZfBtWUZQLIRuZXN6CWklmkjMapMYIDwzCCA78CAQEwgbAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQevDP5zpaxdylO6dsAN9FLDAJBgUr DgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEx MTAxMTM3MTZaMCMGCSqGSIb3DQEJBDEWBBRxA5wBekkk7klT6iC6RN8jAAuEAzCBwQYJKwYBBAGC NxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09N T0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEHrw z+c6WsXcpTunbADfRSwwgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEHrwz+c6WsXcpTunbADfRSwwDQYJKoZIhvcNAQEBBQAE ggEAljcho+CE8Nqpu954aTucWO1dKHS100Awu57LZO0K2yflyZ2pfHcjNpzB0lw3C8UyHX5BBgzF +V4nsXMdb5uxLsWaGujvhrld1A/FV6ToQ3zSBnnkAn3dNiNksW9f13lLxZsiV6Yl6vWpXBtj1hEB ZYoXTaeUW6dZ0Vi8joPf1PmKnuHU5xOrFSfyj3xHfF1w4Nzj4XPqK3yvIdHMq+vWys1SjG27R/md hyLF9jAp6a/Xt+36JSkzm7o5KT5uQEVfpNJIgtNDq0nhgX0U/ysyRIB11ujmOKeMOit+fagXGHR5 kJbifzYKw78LiYKhm2V1XKseferQRPxNJgztBZtrIgAAAAAAAA== --Apple-Mail=_5319F61D-EA2A-455F-AD8B-ED49386013BA-- From nobody Mon Nov 14 16:22:49 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F0C12957C for ; Mon, 14 Nov 2016 16:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRQOUt_ChLQZ for ; Mon, 14 Nov 2016 16:22:47 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D8B124281 for ; Mon, 14 Nov 2016 16:22:46 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tHp4g18HjzDD4; Tue, 15 Nov 2016 01:22:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479169363; bh=VXjiFi5TGrXYomZa9EyLAH3HPOLuu72u1KcfQMHSqlg=; h=Date:From:To:Subject; b=Kr+2rB4rZqCBblvHmw5PM3QrfTSMfvhs1yxiG6FfIBslK/WgGAPSyCVyZ6Vp0SdwY My8DVIz9FiEzrDGGOpwOzcW8Z04zcq7nOsKdcXcyzxznHhf96c0h+mghi83gRx2z1/ ZOYYc/qpZdn/lWjuG0ALDVQoSmQX+/FLB5tImyG0= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id CMFadOTdATLb; Tue, 15 Nov 2016 01:22:42 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 15 Nov 2016 01:22:42 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 24E018DB9D; Mon, 14 Nov 2016 19:22:40 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 24E018DB9D Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0E6C840DAA3E; Mon, 14 Nov 2016 19:22:39 -0500 (EST) Date: Mon, 14 Nov 2016 19:22:39 -0500 (EST) From: Paul Wouters To: Trans , Melinda Shore Message-ID: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [Trans] Session today starts at 11:00 in studio 4 (not 9.30) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 00:22:48 -0000 There is quite some confusion about the trans session because the paper copy says 11:30 (leaving 30 minutes only) and the online calendar says 9.30. It is a shared session, and the previous group (modern) promises to be done at 11:00am, so let's aim for 11:00 instead of 11:30 Paul From nobody Tue Nov 15 11:49:28 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F0612956C for ; Tue, 15 Nov 2016 11:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vX5qSNr5G-p for ; Tue, 15 Nov 2016 11:49:20 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064AC129556 for ; Tue, 15 Nov 2016 11:49:20 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id x186so97680873vkd.1 for ; Tue, 15 Nov 2016 11:49:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=YqK5/6deFwjCRtEP69X9hfNPv3orN1kwnSoekJe2B1Y=; b=NXQCRDq5c6bO9o5e8+ZQP33r41VtdhtESwJoo6T/bRcSHmJ9gJe1FLXHFZuWFFt3ge MlhDtxcKQjKUvdloW+WcexsoE1OSVJuOW9AU0FdJT0NIhO/tos7zxaeV5i3uuKxnAbC8 O9YFbyHG50GnZvPgMLHl2S/v33TUBdzmLikhADmiVOlN9KuzEk8hvt7iKptWhVDbwiUr RqKT/UOO2RiCYr3Lk068g70V4bEzGSNrWXgTOJYYAUGCKqWZg5Pk//7D0tjoC/FgEK9t nizXr+BpJgEDcRaxqo4P6Q16Y5adLKReYL/kX/dtBfgDoXge0oapEo6iW0hjdrZYy0la Fu2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YqK5/6deFwjCRtEP69X9hfNPv3orN1kwnSoekJe2B1Y=; b=QCzSO0rhzNeFS2PTr2RT9KdS6JPM4Y4nLKkw2pppD6jZZ/uCIMInjUw8OEY9fpLrXO KHmAdpkLx7J9fiQKTJqtF1wWHOMulbYnPzx6leEBzP1blDFaV7BWAJk2ARJweywSSIHw x48kJ83IkSV6px8LUK6LNlAu8H5VJVlJ+3ybWruBRDwv0qxBkNzfSa6nAeOQqAYSYwER dR89XAPMpJg0V9l5ZUJCOSZ68Uh0BTGwdF5yH5aCq0DpP2Khfh1+vI0WInijCd5kAlGl XRwieGujuPONK0r5Vqk2+DYAwT7uk49SuacD4ipvE0iw7ITwT3NFx8s8vFFnkvO/T5E/ f5gg== X-Gm-Message-State: ABUngvdCNnbxbSAeN2fsfI/DOzZETck/HbUNvRHKZoL7zLI+T/W/wumnE2ets94eaVlVzugg0gZ395d+bUpR+sdZ X-Received: by 10.31.174.2 with SMTP id x2mr14595957vke.40.1479239358881; Tue, 15 Nov 2016 11:49:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.162.67 with HTTP; Tue, 15 Nov 2016 11:49:18 -0800 (PST) From: Ben Laurie Date: Tue, 15 Nov 2016 19:49:18 +0000 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Trans] How to redact an entry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 19:49:21 -0000 Eran asked me to briefly describe how redaction in a transparency log would work. First, we introduce a new leaf type, "Redacted". The content of this leaf is simply the hash of the original leaf, the entry number of the redaction reason entry (see below) and a signature over the content by the log key. Rather than hashing this entry, verifiers simply use the enclosed hash to calculate the tree hash. Secondly, we introduce a second new leaf type, "Redaction reason". This leaf contains two things: the entry number of the redacted entry and a textual explanation of why it was redacted (possibly we need to get a little more elaborate here, but perhaps the simplest thing to do is to allow it to include URLs to point to any supporting material). This leaf type would be hashed in the usual way. Observers of the log can verify that every redacted entry has a corresponding redaction reason entry, and if not, can produce proof it does not (this is why the redacted entry has to be signed directly). Note that the redacted entry could not include the entry number of the redaction reason, if preferred, though that would force an observer of that entry to download the whole log to verify the reason and also would make proof of non-compliance bulky. :-) From nobody Tue Nov 15 17:01:20 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B88F1295E0 for ; Tue, 15 Nov 2016 17:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgnCZ8LDf073 for ; Tue, 15 Nov 2016 17:01:18 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96CE129592 for ; Tue, 15 Nov 2016 17:01:17 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id a197so204755622wmd.0 for ; Tue, 15 Nov 2016 17:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dT1E1odGOjs/YqJKoAdQpDVUWNB7JKftEA3Rt+mAEWg=; b=nhH0HZBPhGD97vJx/CiZZQL74gysG3KJOzvI2dMMpW+YUYVM7F3DKg1i0jpSA18vYb sjBWoSNbknEtXlSAJZbK+jiIbUAObRpwARvCVRvLWrD5Ed6e4N3hrxSaG8rEvf0LrNyu ddEGeNKdjrk12RhqXEER0zNniLaYqu8UoBnPkbQRl7WajqxAEkgPfRhCoLGUGnldGD7g 87nJpYguFh5tO69yVMIYZS0UFXDcdV2pwyi6COE++zk4a8dX9+fqAPmLZuMfzfcRe2ME d5MSMWtRGlNLDLmrcMVV0wtBgzvhceQFInFtO4zBsZSKDAWxDD48GvihrL9o6CsScEf2 fkWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dT1E1odGOjs/YqJKoAdQpDVUWNB7JKftEA3Rt+mAEWg=; b=heuZ+nAahEMfjFUyS3mHEjMLG41t08rGP1/vdjl9R6/GLvtU4ACLxP5lqL6NBwRhTW pjrM0tHR5NdYSIOBf6uZChXfJfSyzFgW3+GkrzA7K1QQODVR9E0pui0xMsSu4U/mUtOr lpJgL8ENXCcktWItoiKgaz+M2KB4Vm4Kt8PRIHQzzl6MCZi3WY0WokSx6ufLtUkKp1Jy LAGcshysaiJGjbQ0V+oANiYpIDZWfpnn83TG5edN7RbnJLjzOIR81qESAPkmixhj8omA vwwKzeXyr2LUhtpNusnbp3Bw9xUnvEtW1iSK6Ez7hSG2QN7gs+lrW9i6G09EVC/bviXM Uh5g== X-Gm-Message-State: ABUngvfV2NPL4ng0B80FEyducDovcXMvbFFKG3YdJriZ37URqPUtc4WsMqgGa03crqkgkKy6ldgiVXWAHmGyVg== X-Received: by 10.194.187.103 with SMTP id fr7mr96320wjc.99.1479258076340; Tue, 15 Nov 2016 17:01:16 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.3.41 with HTTP; Tue, 15 Nov 2016 17:01:15 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Tue, 15 Nov 2016 20:01:15 -0500 X-Google-Sender-Auth: oRj9_--FoM94T2TBMwcFmkokAU0 Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=047d7bd6bc9c2bf3660541609ce7 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] How to redact an entry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:01:19 -0000 --047d7bd6bc9c2bf3660541609ce7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 15, 2016 at 2:49 PM, Ben Laurie wrote: > Eran asked me to briefly describe how redaction in a transparency log > would work. > > First, we introduce a new leaf type, "Redacted". The content of this > leaf is simply the hash of the original leaf, the entry number of the > redaction reason entry (see below) and a signature over the content by > the log key. > > Rather than hashing this entry, verifiers simply use the enclosed hash > to calculate the tree hash. > > Secondly, we introduce a second new leaf type, "Redaction reason". > This leaf contains two things: the entry number of the redacted entry > and a textual explanation of why it was redacted (possibly we need to > get a little more elaborate here, but perhaps the simplest thing to do > is to allow it to include URLs to point to any supporting material). > This leaf type would be hashed in the usual way. > > Observers of the log can verify that every redacted entry has a > corresponding redaction reason entry, and if not, can produce proof it > does not (this is why the redacted entry has to be signed directly). > > Note that the redacted entry could not include the entry number of the > redaction reason, if preferred, though that would force an observer of > that entry to download the whole log to verify the reason and also > would make proof of non-compliance bulky. :-) > =E2=80=8BI decided I had to do something of this sort in the Mesh notary lo= g. It is probably a good idea to do it as a matter of course. Lets consider the general case for a moment, what happens if someone puts some child pornography into the log. Obviously you can't publish it or you go to jail. So you have to take it out which breaks the log. So either you have to devise a scheme that you are certain cannot be used to publish abusive material or you have to have a way to suppress it either. I think the second approach is better. Of course putting bad stuff in a Trans log would be a lot more effort than putting it into the blockchain or the like. But don't think it is impossible. I have a few attacks that are worrying enough not to want to share in public. The sort of thing that has Special Branch making house calls. So I would hash the received data values before enrolling the hash in the notary log as a matter of course. --047d7bd6bc9c2bf3660541609ce7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, No= v 15, 2016 at 2:49 PM, Ben Laurie <benl@google.com> wrote:
=
Eran asked me to briefly describe how redact= ion in a transparency log
would work.

First, we introduce a new leaf type, "Redacted". The content of t= his
leaf is simply the hash of the original leaf, the entry number of the
redaction reason entry (see below) and a signature over the content by
the log key.

Rather than hashing this entry, verifiers simply use the enclosed hash
to calculate the tree hash.

Secondly, we introduce a second new leaf type, "Redaction reason"= .
This leaf contains two things: the entry number of the redacted entry
and a textual explanation of why it was redacted (possibly we need to
get a little more elaborate here, but perhaps the simplest thing to do
is to allow it to include URLs to point to any supporting material).
This leaf type would be hashed in the usual way.

Observers of the log can verify that every redacted entry has a
corresponding redaction reason entry, and if not, can produce proof it
does not (this is why the redacted entry has to be signed directly).

Note that the redacted entry could not include the entry number of the
redaction reason, if preferred, though that would force an observer of
that entry to download the whole log to verify the reason and also
would make proof of non-compliance bulky. :-)

=E2=80=8BI de= cided I had to do something of this sort in the Mesh notary log. It is prob= ably a good idea to do it as a matter of course.

Lets consider the general case for a moment, what h= appens if someone puts some child pornography into the log. Obviously you c= an't publish it or you go to jail. So you have to take it out which bre= aks the log.
So either yo= u have to devise a scheme that you are certain cannot be used to publish ab= usive material or you have to have a way to suppress it either. I think the= second approach is better.


Of cour= se putting bad stuff in a Trans log would be a lot more effort than putting= it into the blockchain or the like. But don't think it is impossible. = I have a few attacks that are worrying enough not to want to share in publi= c. The sort of thing that has Special Branch making house calls.

So I would hash the received = data values before enrolling the hash in the notary log as a matter of cour= se.
--047d7bd6bc9c2bf3660541609ce7-- From nobody Tue Nov 15 17:55:08 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B57B1295C9 for ; Tue, 15 Nov 2016 17:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndeU_RlwO94I for ; Tue, 15 Nov 2016 17:55:05 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51141295FC for ; Tue, 15 Nov 2016 17:54:59 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id f82so39693387wmf.1 for ; Tue, 15 Nov 2016 17:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qz4ry2C4gJQji0HfkKyS8xLyPTcGhP1TVhRynMAn6sg=; b=bxjHDOu4P2+RBPGOv00X6JtyQUx+3NH1Lw6iqBua7LjwkCEKjoVJuqu3+xgBynXvPI TyKBIpVb1MXflY2tETTfGsBoaOBDDIz/zV5vGaA66kR/dPlycv619ICmaHswi2V5tulF FjikuHYH2HxRn0PYiCRStITevnbklCHeoh7DoF30j+TxCyQrBF+Ox7tR4Akd078mWcKk ZbFvprUz6OoaJ8++pfbonLZc/46t3epVhoqJKiklxKLdhIuHmrHn83sVgUp2B8p6ttX7 EF1Emzl5uG4Zv9cBgE0jGli2ppTsml9vfQMsmN6Y5/tnwBIvmfSJjmaNaCziA6cFKIrC u+SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qz4ry2C4gJQji0HfkKyS8xLyPTcGhP1TVhRynMAn6sg=; b=IDm1vwPqy8iC107tBmBCYxWBTG2jmbrPxs4hRpAf+6X5S+uhYDQxUGSjqQ0wQi+OjO B0jlBtp95tIjoVgVAZXybbR6rwKRaK4MTC9s1m8Kj6iRUFlFAEpErxx+nl5vM49veP7O mI5nZshksd7l/KMYxSwabugUudJFtnTe2cLHSg16lHZ9ap19v+BTX2PhRDIF4lfQqiGQ a0Ca+bwE2LVDxA9YvxNNotS0fYjbyfBGcn3aNy+reKSRk8vZGwyh3MwcCEZfIQslHWRP CLKm5Powbhil6maRcYHVFlmbvmdXABWF/SU6UVVDNF7sPObgD77KPJ863tQhzf6e4CZz c60g== X-Gm-Message-State: ABUngvf5fcH6S1EDwFIAe7kTZdeWmOxWFIdwZDYo0u86kGAGLhxJhRwIYOUBtFKXlUjk5D0uhEeTh8roaWiUY+Wf X-Received: by 10.194.142.243 with SMTP id rz19mr186016wjb.132.1479261297817; Tue, 15 Nov 2016 17:54:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.21 with HTTP; Tue, 15 Nov 2016 17:54:57 -0800 (PST) In-Reply-To: <75df4d95-c923-00bd-4eee-0027d7dbfd8b@comodo.com> References: <8229e7fa-9763-41b7-b08b-ce1286dcb389@chromium.org> <75df4d95-c923-00bd-4eee-0027d7dbfd8b@comodo.com> From: Eran Messeri Date: Wed, 16 Nov 2016 10:54:57 +0900 Message-ID: To: Rob Stradling Content-Type: multipart/alternative; boundary=089e0112be48306c9e0541615c0d Archived-At: Cc: Pierre Phaneuf , "trans@ietf.org" , certificate-transparency , Florian MAURY , Certificate Transparency Policy , Paul Hadfield Subject: Re: [Trans] [ct-policy] Re: Certificate Transparency Mirrors (experimental) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:55:07 -0000 --089e0112be48306c9e0541615c0d Content-Type: text/plain; charset=UTF-8 Regarding the ability to get a consistency proof between any two arbitrary tree sizes, I agree it's useful for this scenario. Note it is not essential for correct operation of the protocol - for correct operation of the protocol only consistency proofs between STHs issued by the log are needed (so, for simplicity of log implementation, the standard does not require logs to provide consistency proofs between arbitrary tree sizes). Regarding Rob Stradling's suggested get-sths, the consensus at the trans WG meeting yesterday seemed to be that this belongs in the monitoring API document rather than 6962-bis. On Mon, Nov 7, 2016 at 8:15 PM, Rob Stradling wrote: > On 07/11/16 10:54, Paul Hadfield wrote: > > > Hi Florian, > > > > there's been some recent discussion on [trans] about adding a new > endpoint > > for v2 that permits a client to retrieve historic STHs. It sounds like > > what you are interested in is quite similar. > > > > Rob Stradling has taken the proposal for this and created a pull request > on > > the RFC repo: > > https://github.com/google/certificate-transparency-rfcs/pull/200 > > > > Perhaps you could comment there? > > A few days ago Melinda wrote: > "6962-bis has completed working group last call. Minor editorial > changes are fine, but let's try to avoid major changes that would > require yet another WGLC." > > I don't yet know if the Chairs consider a new endpoint to be a "major > change". > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > -- > You received this message because you are subscribed to the Google Groups > "Certificate Transparency Policy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ct-policy+unsubscribe@chromium.org. > To post to this group, send email to ct-policy@chromium.org. > To view this discussion on the web visit https://groups.google.com/a/ > chromium.org/d/msgid/ct-policy/75df4d95-c923-00bd- > 4eee-0027d7dbfd8b%40comodo.com. > --089e0112be48306c9e0541615c0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding the ability to get a consistency proof between a= ny two arbitrary tree sizes, I agree it's useful for this scenario. Not= e it is not essential for correct operation of the protocol - for correct o= peration of the protocol only consistency proofs between STHs issued by the= log are needed (so, for simplicity of log implementation, the standard doe= s not require logs to provide consistency proofs between arbitrary tree siz= es).

Regarding Rob Stradling's suggested get-sths, t= he consensus at the trans WG meeting yesterday seemed to be that this belon= gs in the monitoring API document rather than 6962-bis.

On Mon, Nov 7, 2016 at 8:= 15 PM, Rob Stradling <rob.stradling@comodo.com> wrote= :
On 07/11/16 10:54, Paul Hadfield wrote:=
<snip>
> Hi Florian,
>
> there's been some recent discussion on [trans] about adding a new = endpoint
> for v2 that permits a client to retrieve historic STHs.=C2=A0 It sound= s like
> what you are interested in is quite similar.
>
> Rob Stradling has taken the proposal for this and created a pull reque= st on
> the RFC repo:
> https://github.com/google/= certificate-transparency-rfcs/pull/200
>
> Perhaps you could comment there?

A few days ago Melinda wrote:
=C2=A0 "6962-bis has completed working group last call.=C2=A0 Minor ed= itorial
=C2=A0 =C2=A0changes are fine, but let's try to avoid major changes tha= t would
=C2=A0 =C2=A0require yet another WGLC."

I don't yet know if the Chairs consider a new endpoint to be a "ma= jor
change".

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

--
You received this message because you are subscribed to the Google Groups &= quot;Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to ct-policy+u= nsubscribe@chromium.org.
To post to this group, send email to ct-policy@chromium.org.
To view this discussion on the web visit https://groups.goog= le.com/a/chromium.org/d/msgid/ct-policy/75df4d95-c923-00bd-4= eee-0027d7dbfd8b%40comodo.com.

--089e0112be48306c9e0541615c0d-- From nobody Tue Nov 15 18:00:38 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395F9129538 for ; Tue, 15 Nov 2016 18:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9PugLTaiyqY for ; Tue, 15 Nov 2016 18:00:34 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F075712954F for ; Tue, 15 Nov 2016 18:00:33 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id g23so207190837wme.1 for ; Tue, 15 Nov 2016 18:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y/bnmAETdG5DorEet/mTPlDj83vajuMqxiArit6NF5I=; b=ESxAnoob1JC0TQwLFQzyg2IKlF92M1vSQPhLHRTg1TiIsiv4CsLgHh8K9RCwo3J/72 ZjeZZR4G81DhOHhXZvXGAkTs+agB0L+mk19m5yErrAoWQwY5XtZfBCJVpFgWSlek+Mt3 x4cZzAiKC2SO1fppqCJ0FeEuh1pA3PKXJcC00A7MDzSFgk9d/1kq2Ocy3TmGlxs94+eN mHS37EWX1HdeS96j9NrCMP9jaKm6v5pnxEg2UhaAEWz15GnWIsu6y6VoDnuDvDFHoQ6h j8uinCOA9sNgiq9cDBdjh8Ahu20WD/dPw0tnzXyfKHP3O1EA13AZX5zbSIsQ65pk5m8O sCKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y/bnmAETdG5DorEet/mTPlDj83vajuMqxiArit6NF5I=; b=CpNKyuvef5P1mvDPDu/oxiaImq67knnFqktwQyMR4I9zC05XIXmzcGjhGZLKt8RtC1 OPeXkY9lV/8jMbWdLY/UZf3S0hXSjW3eFHlnF74zc+W9gGXc5B2I8X3Ik2HaZ2EWp7Ql HeN1+ls257WBSuZnfsVRt7AXyHmHvWpwfb/ZvX6VeVbqKWZHrc2W9xp1uWSms8bYu8yL qURtCGlLJhO9cSkcW5LzkGh1Pw00cJq3vNVZhxhmRjRS07zpdWuKfikX4DQvz0b57Cwy XoRgfGO1WPI2bE+G2o4uRVvAcUUXak6bezcpnG9KOkZMYuKnX60ExDiDs4qhyHtTibRX 3Q+w== X-Gm-Message-State: ABUngvcoDFYhtTa1Cj8DRR7tF6//wRPz1kpdJhcCexisvcGi1sDD9xtidAzhhW7pUudUKqlTSOz6cWoeBGsno+i6 X-Received: by 10.28.37.2 with SMTP id l2mr7187346wml.86.1479261632467; Tue, 15 Nov 2016 18:00:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.21 with HTTP; Tue, 15 Nov 2016 18:00:31 -0800 (PST) In-Reply-To: References: <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> From: Eran Messeri Date: Wed, 16 Nov 2016 11:00:31 +0900 Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=001a114afa2c22769e0541617021 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 02:00:36 -0000 --001a114afa2c22769e0541617021 Content-Type: text/plain; charset=UTF-8 My proposed compromise at the trans workgroup meeting yesterday was to change the MUST in the following paragraph to a SHOULD: "Logs MUST accept certificates and precertificates that are fully valid according to RFC 5280 verification rules and are submitted with such a chain." I believe that this change allows creating logs that can reject valid submissions under some circumstances while complying with 6962-bis. And we wouldn't have to go through WGLC again for such a change. On Sat, Nov 5, 2016 at 12:42 AM, Ben Laurie wrote: > On 4 November 2016 at 14:07, Peter Bowen wrote: > > On Fri, Nov 4, 2016 at 6:33 AM, Ben Laurie wrote: > >> > >> The bit you didn't quote does say they the log has to accept valid > >> certs, tho: "Logs MUST accept certificates and precertificates that > >> are fully valid according to RFC 5280 [RFC5280] verification rules and > >> are submitted with such a chain." > > > > Sorry about that. So the three MUSTs together are: > > > > - Logs MUST verify that each submitted certificate or precertificate > > has a valid signature chain to an accepted trust anchor, using the > > chain of intermediate CA certificates provided by the submitter. > > > > - Logs MUST reject submissions without a valid signature chain to an > > accepted trust anchor. > > > > - Logs MUST accept certificates and precertificates that are fully > > valid according to RFC 5280 verification rules and are submitted with > > such a chain. > > > > When I read these together, I read that Logs must accept _any_ > > certificate that is fully valid according to RFC 5280 verification > > rules and chains to any root the log trusts and logs must _only_ log > > such certificates (and no others). > > > > If this is accurate, we need to account for all types of certificates > > being logged, as a log cannot choose to reject certificates for usages > > other than server authentication and the log cannot reject > > certificates that have personal information (e.g. an server > > authentication certificate that states which human requested the > > certificate in the subject). > > > > This seems like a very strong assertion of policy rather than a > > technical discussion of how the CT protocol works. I would again ask > > the WG to reconsider the requirement levels specified in this section. > > FWIW, I tend to agree. I would also note that operationally, we have > already discussed options for logs that are incompatible with these > requirements, for example: > > * sharded logs (e.g. by hash(cert) mod n). > > * logs that only accept short or long lifetime certificates (this > would allow the working set to be reduced in size for CAs that issue a > lot of short-lived certs). > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a114afa2c22769e0541617021 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My proposed compromise at the trans workgroup meeting yest= erday was to change the MUST in the following paragraph to a SHOULD:
&q= uot;Logs MUST accept certificates and precertificates that are fully valid = according to RFC 5280 verification rules and are submitted with such a chai= n."

I believe that this change allows creatin= g logs that can reject valid submissions under some circumstances while com= plying with 6962-bis. And we wouldn't have to go through WGLC again for= such a change.

On Sat, Nov 5, 2016 at 12:42 AM, Ben Laurie <= ;benl@google.com&g= t; wrote:
On 4 November 2016 at 14:07, Peter Bowen <pzbowen@gmail.com> wrote:
> On Fri, Nov 4, 2016 at 6:33 AM, Ben Laurie <benl@google.com> wrote:
>>
>> The bit you didn't quote does say they the log has to accept v= alid
>> certs, tho: "Logs MUST accept certificates and precertificate= s that
>> are fully valid according to RFC 5280 [RFC5280] verification rules= and
>> are submitted with such a chain."
>
> Sorry about that.=C2=A0 So the three MUSTs together are:
>
> - Logs MUST verify that each submitted certificate or precertificate > has a valid signature chain to an accepted trust anchor, using the
> chain of intermediate CA certificates provided by the submitter.
>
> - Logs MUST reject submissions without a valid signature chain to an > accepted trust anchor.
>
> - Logs MUST accept certificates and precertificates that are fully
> valid according to RFC 5280 verification rules and are submitted with<= br> > such a chain.
>
> When I read these together, I read that Logs must accept _any_
> certificate that is fully valid according to RFC 5280 verification
> rules and chains to any root the log trusts and logs must _only_ log > such certificates (and no others).
>
> If this is accurate, we need to account for all types of certificates<= br> > being logged, as a log cannot choose to reject certificates for usages=
> other than server authentication and the log cannot reject
> certificates that have personal information (e.g. an server
> authentication certificate that states which human requested the
> certificate in the subject).
>
> This seems like a very strong assertion of policy rather than a
> technical discussion of how the CT protocol works.=C2=A0 I would again= ask
> the WG to reconsider the requirement levels specified in this section.=

FWIW, I tend to agree. I would also note that operationally, we= have
already discussed options for logs that are incompatible with these
requirements, for example:

* sharded logs (e.g. by hash(cert) mod n).

* logs that only accept short or long lifetime certificates (this
would allow the working set to be reduced in size for CAs that issue a
lot of short-lived certs).

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

--001a114afa2c22769e0541617021-- From nobody Tue Nov 15 18:17:09 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2571295FC for ; Tue, 15 Nov 2016 18:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h6RsfVoDEHq for ; Tue, 15 Nov 2016 18:17:06 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5C21295D0 for ; Tue, 15 Nov 2016 18:17:06 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id f82so40538479wmf.1 for ; Tue, 15 Nov 2016 18:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XeHMZZ4zPGuvL17Dvd4/NqIyyodVBC5yHYsLNzXcbnk=; b=gyK0eOuWg6d92XUMgH5wSisqMgWVJm7SklfBti5XHmF2Jvk4BeK0KbgY6Wnc0sjsU8 BT/0p5anz6tY8vZiKXnJq3+BS66z/Oc9nrY22Ig9OUdxcvjyUpKQc6H8C1TxP/JVhDhs WO8+RUVQNNQc1viboSVcdQBz6DGvzrtD7DHZcr3fLqb4hS2Q0TUSCLFYuGR4aoXDJj1N PjgsXOk+jw2wO9acbGsF3cUBorxhWtmf81uXXpg635q+JIGGZIbicNpjgDSRbccycV3Y rLLQ6zGNrGsFv2lYPZMWHElX7oU9+nMR1M7u0wsmOnCu2MJklpXNgbLOQ+iO2KFBv6In JZdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XeHMZZ4zPGuvL17Dvd4/NqIyyodVBC5yHYsLNzXcbnk=; b=OQKpEa5E+ZsgzyaRLGYjV8x7wkaqghllg/De5MVhFAVlvnLh37/MFfY/s0O1yfoTOO ZJvhCSzeNUGwd1waFZEIZcnJXiBCiMhggppvBu4tWKYHg/GmY36PpJMWT8U5Lrvoibe4 0HS7g1yUpVPG7QJ1ZNvnkc0n/xn9lRVqKONF3DvHXiiY6EJ7g0lpGbb8oCYs/cBrLHkL SXCkxZYnmEdLNhWk3yEzb4w4ZWa/HvkkVgTTXxvNIDmaBjYpXWfoONzFq6/aWGbGuNxN UBDWpxhW9QTkrxFTN/AxUYgdziGiyohp2UTFMkh4pBoC9hXL+jmOscXHo8aBG9LiR5by 5QWg== X-Gm-Message-State: ABUngvfh1yMn//uS+scewhgvsMWSebgwTy8zws6WBp0kbyaylfzB4yNbKCOs8kEUHGMlGVSWtgKKwc0OW57vTM+Z X-Received: by 10.28.214.84 with SMTP id n81mr6351891wmg.120.1479262624708; Tue, 15 Nov 2016 18:17:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.21 with HTTP; Tue, 15 Nov 2016 18:17:04 -0800 (PST) In-Reply-To: <2775E6CC-A288-4681-A14F-19A775EDFF15@symantec.com> References: <5b357047-d412-70de-4aa6-9499fa8837b5@comodo.com> <5290c544-97b1-7530-eb0c-e9b62d8ebc71@comodo.com> <2775E6CC-A288-4681-A14F-19A775EDFF15@symantec.com> From: Eran Messeri Date: Wed, 16 Nov 2016 11:17:04 +0900 Message-ID: To: Tarah Wheeler Content-Type: multipart/alternative; boundary=001a1147286c46d3e8054161ab61 Archived-At: Cc: Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 02:17:08 -0000 --001a1147286c46d3e8054161ab61 Content-Type: text/plain; charset=UTF-8 Ryan Hurst and Clint Wilson had a discussion on name redaction use-cases (following the trans WG meeting). AIUI Clint intends to post a summary of that discussion to the list. On Fri, Oct 28, 2016 at 10:49 PM, Tarah Wheeler wrote: > I've had one or two :) I'll look forward to your thoughts on them. I'll > have some work for you all to look at soon. > > Tarah Wheeler > Principal Security Advocate > Senior Director of Engineering, Website Security > Symantec > tarah@symantec.com > > > > On Oct 25, 2016, at 5:23 PM, Rob Stradling > wrote: > > > >> On 23/09/16 20:04, Tarah Wheeler wrote: > >> I will co-author the redaction RFC. > > > > Hi Tarah. Have you had any further thoughts on this since the call for > > adoption a month ago? > > > > After the discussion at the CABForum F2F last week, it seems that > > redaction is going to be a hot topic in Seoul. So I'm just wondering if > > there are any updates worth doing to draft-strad-trans-redaction before > > the draft cut-off date (Monday 31st Oct) that might facilitate the > > discussions. > > > > -- > > Rob Stradling > > Senior Research & Development Scientist > > COMODO - Creating Trust Online > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a1147286c46d3e8054161ab61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ryan Hurst and Clint Wilson had a discussion on name redac= tion use-cases (following the trans WG meeting).
AIUI Clint intends to = post a summary of that discussion to the list.

On Fri, Oct 28, 2016 at 10:49 PM, = Tarah Wheeler <Tarah_Wheeler@symantec.com> wrote:
I've had one or two :) I'll look f= orward to your thoughts on them. I'll have some work for you all to loo= k at soon.

Tarah Wheeler
Principal Security Advocate
Senior Director of Engineering, Website Security
Symantec
tarah@symantec.com


> On Oct 25, 2016, at 5:2= 3 PM, Rob Stradling <rob.str= adling@comodo.com> wrote:
>
>> On 23/09/16 20:04, Tarah Wheeler wrote:
>> I will co-author the redaction RFC.
>
> Hi Tarah.=C2=A0 Have you had any further thoughts on this since the ca= ll for
> adoption a month ago?
>
> After the discussion at the CABForum F2F last week, it seems that
> redaction is going to be a hot topic in Seoul.=C2=A0 So I'm just w= ondering if
> there are any updates worth doing to draft-strad-trans-redaction befor= e
> the draft cut-off date (Monday 31st Oct) that might facilitate the
> discussions.
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online

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

--001a1147286c46d3e8054161ab61-- From nobody Tue Nov 15 19:46:55 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62113129566 for ; Tue, 15 Nov 2016 19:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVfyU7daRblB for ; Tue, 15 Nov 2016 19:46:51 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF291294F7 for ; Tue, 15 Nov 2016 19:46:51 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tJVYj5P7lz1HZ; Wed, 16 Nov 2016 04:46:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479268009; bh=rpPH0Fl8zou5e7/htMLEJo3AR5HnZ0nFm01tOT97I2Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=t7vk1+NpLB1IlSJpbIlMI3bAGvmuDTj7/HW2I1T96K6lVPFaIX4mbFVSw3NRIzRoV rPuSZztS8ZsYuAMHQinshg5j/LB5usQ+paRFzaXxTRp7LfdPl0UzMOjrCzUN0fqvcW 4vWWuB629vROOLlNWBnAiLj+IxagYDueb/6D/dQk= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Ypyp5mt4IMja; Wed, 16 Nov 2016 04:46:47 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Nov 2016 04:46:46 +0100 (CET) Received: from [31.133.136.30] (unknown [31.133.136.30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 2B67E35A2B3; Tue, 15 Nov 2016 22:46:45 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 2B67E35A2B3 Content-Type: multipart/alternative; boundary=Apple-Mail-32907B82-44FD-4651-A1BA-F53BA778C67A Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Wed, 16 Nov 2016 12:46:42 +0900 Content-Transfer-Encoding: 7bit Message-Id: <4E665C5B-BC28-428E-9BFB-626D3364E05B@nohats.ca> References: To: Phillip Hallam-Baker Archived-At: Cc: "trans@ietf.org" , Ben Laurie Subject: Re: [Trans] How to redact an entry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 03:46:53 -0000 --Apple-Mail-32907B82-44FD-4651-A1BA-F53BA778C67A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable How can I as log consumer detect the difference between the log removing ill= egal content and the log being compelled by a government to hide a rogue cer= tificate? Sent from my iPhone > On Nov 16, 2016, at 10:01, Phillip Hallam-Baker wro= te: >=20 >=20 >=20 >> On Tue, Nov 15, 2016 at 2:49 PM, Ben Laurie wrote: >> Eran asked me to briefly describe how redaction in a transparency log >> would work. >>=20 >> First, we introduce a new leaf type, "Redacted". The content of this >> leaf is simply the hash of the original leaf, the entry number of the >> redaction reason entry (see below) and a signature over the content by >> the log key. >>=20 >> Rather than hashing this entry, verifiers simply use the enclosed hash >> to calculate the tree hash. >>=20 >> Secondly, we introduce a second new leaf type, "Redaction reason". >> This leaf contains two things: the entry number of the redacted entry >> and a textual explanation of why it was redacted (possibly we need to >> get a little more elaborate here, but perhaps the simplest thing to do >> is to allow it to include URLs to point to any supporting material). >> This leaf type would be hashed in the usual way. >>=20 >> Observers of the log can verify that every redacted entry has a >> corresponding redaction reason entry, and if not, can produce proof it >> does not (this is why the redacted entry has to be signed directly). >>=20 >> Note that the redacted entry could not include the entry number of the >> redaction reason, if preferred, though that would force an observer of >> that entry to download the whole log to verify the reason and also >> would make proof of non-compliance bulky. :-) >=20 > =E2=80=8BI decided I had to do something of this sort in the Mesh notary l= og. It is probably a good idea to do it as a matter of course. >=20 > Lets consider the general case for a moment, what happens if someone puts s= ome child pornography into the log. Obviously you can't publish it or you go= to jail. So you have to take it out which breaks the log. >=20 > So either you have to devise a scheme that you are certain cannot be used t= o publish abusive material or you have to have a way to suppress it either. I= think the second approach is better. >=20 >=20 > Of course putting bad stuff in a Trans log would be a lot more effort than= putting it into the blockchain or the like. But don't think it is impossibl= e. I have a few attacks that are worrying enough not to want to share in pub= lic. The sort of thing that has Special Branch making house calls. >=20 > So I would hash the received data values before enrolling the hash in the n= otary log as a matter of course. > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --Apple-Mail-32907B82-44FD-4651-A1BA-F53BA778C67A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
How can I as log consumer detect the d= ifference between the log removing illegal content and the log being compell= ed by a government to hide a rogue certificate?

Sent from my iPhone

On Nov 16, 2016, at 10:01, Phillip Hallam-Baker <ietf@hallambaker.com> wrote:



On Tue, Nov 15, 2016 at 2:49 PM, Ben Laurie <benl@google.c= om> wrote:
Eran asked me to b= riefly describe how redaction in a transparency log
would work.

First, we introduce a new leaf type, "Redacted". The content of this
leaf is simply the hash of the original leaf, the entry number of the
redaction reason entry (see below) and a signature over the content by
the log key.

Rather than hashing this entry, verifiers simply use the enclosed hash
to calculate the tree hash.

Secondly, we introduce a second new leaf type, "Redaction reason".
This leaf contains two things: the entry number of the redacted entry
and a textual explanation of why it was redacted (possibly we need to
get a little more elaborate here, but perhaps the simplest thing to do
is to allow it to include URLs to point to any supporting material).
This leaf type would be hashed in the usual way.

Observers of the log can verify that every redacted entry has a
corresponding redaction reason entry, and if not, can produce proof it
does not (this is why the redacted entry has to be signed directly).

Note that the redacted entry could not include the entry number of the
redaction reason, if preferred, though that would force an observer of
that entry to download the whole log to verify the reason and also
would make proof of non-compliance bulky. :-)

=E2=80=8BI deci= ded I had to do something of this sort in the Mesh notary log. It is probabl= y a good idea to do it as a matter of course.

Lets consider the general case for a moment, what happens i= f someone puts some child pornography into the log. Obviously you can't publ= ish it or you go to jail. So you have to take it out which breaks the log.

So either you have to devise= a scheme that you are certain cannot be used to publish abusive material or= you have to have a way to suppress it either. I think the second approach i= s better.


Of course putting bad stuff i= n a Trans log would be a lot more effort than putting it into the blockchain= or the like. But don't think it is impossible. I have a few attacks that ar= e worrying enough not to want to share in public. The sort of thing that has= Special Branch making house calls.

So I would hash the received data values before enrolling the h= ash in the notary log as a matter of course.
____________________= ___________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mai= lman/listinfo/trans
= --Apple-Mail-32907B82-44FD-4651-A1BA-F53BA778C67A-- From nobody Tue Nov 15 19:54:22 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6623A12961F for ; Tue, 15 Nov 2016 19:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL0JnlOalPK0 for ; Tue, 15 Nov 2016 19:54:19 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118FB1293FC for ; Tue, 15 Nov 2016 19:54:19 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id t79so43783936wmt.0 for ; Tue, 15 Nov 2016 19:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EIGNfZ3QWnQpeBeSwJj9Rm3P/dCzg9E0vY0tmhz/6cY=; b=fhMPmY/K4/OTEMLVZNCHyIwZMaMxDy2jnZobR8ylP96ojALCrWxwEMFbGqhHRebzg+ oqhJ24GqZOFLZnmiTpA3CQz012ohHR+p+eYtYJvoP2513WcI0TmRDGkx3CYSuHVPuKGI tMlEf8cWar7YkvLrUFkZN0/KqjdCr7WSxUtvi0yUJUDJJqAxAOO6jNnRs638TE4iLxEl MyO52plrMnlBRfTayOBd7Si82X8baxtpwIJZarHGF3HPN5phF9Mzf5Dmvax4dQlbq5TN UPOQeN3pkcGPOThZz9UGLO2FYjZ2tbYVgjI9D8Pi2JI6Qi7JHz2/SItk6oMvuTqxLmQC 7R9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EIGNfZ3QWnQpeBeSwJj9Rm3P/dCzg9E0vY0tmhz/6cY=; b=UELJuKzfmGoe2mdKzNacOie6GxNkgdZzZ4fsF/FhRQKdUWoOc6Rf9wduiKl08Ow9vl wylBZect+2eWkrbhFiRN1lDx8GAE6DBpzkWRBEwte6bc9z5maxS4cpR3ruzYeUo1bNrb JwafYaItZtQhER8o3tfR+AIEOkY7SHozMDeoteSyiB7DhiIdUITfkbREPWYmtq7XAhmn IFdBsvJ+2fAJCsgJoeINqL1j8E9pqMXWGBvbp2FN8n9TQzV657YC20E9yAen90Tf0TmW OeA+a+2BsUATo3Mhe0sGCqjzANiFHfC6BMikEaPbtGGaaZaPq9PX5r9RBBT+Tb9isJqN yDWw== X-Gm-Message-State: ABUngvc2pxJIdRA3VJDuBGrl1Ada/K3+P4JTAr6+T6i+kj8poV6LR2ZSWMZZEMUNGYzp3IsBJewMDd4kgNhaKQ== X-Received: by 10.28.198.67 with SMTP id w64mr7580350wmf.13.1479268457621; Tue, 15 Nov 2016 19:54:17 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.3.41 with HTTP; Tue, 15 Nov 2016 19:54:16 -0800 (PST) In-Reply-To: <4E665C5B-BC28-428E-9BFB-626D3364E05B@nohats.ca> References: <4E665C5B-BC28-428E-9BFB-626D3364E05B@nohats.ca> From: Phillip Hallam-Baker Date: Tue, 15 Nov 2016 22:54:16 -0500 X-Google-Sender-Auth: _spOsDcV9TbelVdISFsLgPSE1as Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=94eb2c193638f1acbc05416306fe Archived-At: Cc: "trans@ietf.org" , Ben Laurie Subject: Re: [Trans] How to redact an entry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 03:54:21 -0000 --94eb2c193638f1acbc05416306fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That particular attack is certainly an issue for some linked notary logs. The point of CT is to prevent insertion attacks, to ensure that only items entered into the log are notarized. What is the harm you see being caused by suppression? Remember that a party that has the actual data can still prove that it was enrolled. On Tue, Nov 15, 2016 at 10:46 PM, Paul Wouters wrote: > How can I as log consumer detect the difference between the log removing > illegal content and the log being compelled by a government to hide a rog= ue > certificate? > > Sent from my iPhone > > On Nov 16, 2016, at 10:01, Phillip Hallam-Baker > wrote: > > > > On Tue, Nov 15, 2016 at 2:49 PM, Ben Laurie wrote: > >> Eran asked me to briefly describe how redaction in a transparency log >> would work. >> >> First, we introduce a new leaf type, "Redacted". The content of this >> leaf is simply the hash of the original leaf, the entry number of the >> redaction reason entry (see below) and a signature over the content by >> the log key. >> >> Rather than hashing this entry, verifiers simply use the enclosed hash >> to calculate the tree hash. >> >> Secondly, we introduce a second new leaf type, "Redaction reason". >> This leaf contains two things: the entry number of the redacted entry >> and a textual explanation of why it was redacted (possibly we need to >> get a little more elaborate here, but perhaps the simplest thing to do >> is to allow it to include URLs to point to any supporting material). >> This leaf type would be hashed in the usual way. >> >> Observers of the log can verify that every redacted entry has a >> corresponding redaction reason entry, and if not, can produce proof it >> does not (this is why the redacted entry has to be signed directly). >> >> Note that the redacted entry could not include the entry number of the >> redaction reason, if preferred, though that would force an observer of >> that entry to download the whole log to verify the reason and also >> would make proof of non-compliance bulky. :-) >> > > =E2=80=8BI decided I had to do something of this sort in the Mesh notary = log. It > is probably a good idea to do it as a matter of course. > > Lets consider the general case for a moment, what happens if someone puts > some child pornography into the log. Obviously you can't publish it or yo= u > go to jail. So you have to take it out which breaks the log. > > So either you have to devise a scheme that you are certain cannot be used > to publish abusive material or you have to have a way to suppress it > either. I think the second approach is better. > > > Of course putting bad stuff in a Trans log would be a lot more effort tha= n > putting it into the blockchain or the like. But don't think it is > impossible. I have a few attacks that are worrying enough not to want to > share in public. The sort of thing that has Special Branch making house > calls. > > So I would hash the received data values before enrolling the hash in the > notary log as a matter of course. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --94eb2c193638f1acbc05416306fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tha= t particular attack is certainly an issue for some linked notary logs. The = point of CT is to prevent insertion attacks, to ensure that only items ente= red into the log are notarized.

What is the harm you see being caused by suppression? Remember that = a party that has the actual data can still prove that it was enrolled.


On Tue, Nov 15, 2016 at 10= :46 PM, Paul Wouters <paul@nohats.ca> wrote:
How can I as log consumer detect the= difference between the log removing illegal content and the log being comp= elled by a government to hide a rogue certificate?

Sent from my iPho= ne

On Nov 16, 2016, at 10:01, Phillip = Hallam-Baker <= ietf@hallambaker.com> wrote:

=


On Tue, Nov 15, 2016 at 2:4= 9 PM, Ben Laurie <benl@google.com> wrote:
Eran asked me to briefly describe how redaction in a transpar= ency log
would work.

First, we introduce a new leaf type, "Redacted". The content of t= his
leaf is simply the hash of the original leaf, the entry number of the
redaction reason entry (see below) and a signature over the content by
the log key.

Rather than hashing this entry, verifiers simply use the enclosed hash
to calculate the tree hash.

Secondly, we introduce a second new leaf type, "Redaction reason"= .
This leaf contains two things: the entry number of the redacted entry
and a textual explanation of why it was redacted (possibly we need to
get a little more elaborate here, but perhaps the simplest thing to do
is to allow it to include URLs to point to any supporting material).
This leaf type would be hashed in the usual way.

Observers of the log can verify that every redacted entry has a
corresponding redaction reason entry, and if not, can produce proof it
does not (this is why the redacted entry has to be signed directly).

Note that the redacted entry could not include the entry number of the
redaction reason, if preferred, though that would force an observer of
that entry to download the whole log to verify the reason and also
would make proof of non-compliance bulky. :-)

=E2=80=8BI decided I had to do someth= ing of this sort in the Mesh notary log. It is probably a good idea to do i= t as a matter of course.

Lets consider the general case for a moment, wha= t happens if someone puts some child pornography into the log. Obviously yo= u can't publish it or you go to jail. So you have to take it out which = breaks the log.

So either you have to devise a scheme that you are certai= n cannot be used to publish abusive material or you have to have a way to s= uppress it either. I think the second approach is better.


Of course putting bad stuff in a Trans log woul= d be a lot more effort than putting it into the blockchain or the like. But= don't think it is impossible. I have a few attacks that are worrying e= nough not to want to share in public. The sort of thing that has Special Br= anch making house calls.

So I would hash the received data values b= efore enrolling the hash in the notary log as a matter of course.
_______= ________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mail= man/listinfo/trans

--94eb2c193638f1acbc05416306fe-- From nobody Tue Nov 15 19:59:11 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88BE129431 for ; Tue, 15 Nov 2016 19:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-HI8FyHjvT7 for ; Tue, 15 Nov 2016 19:59:09 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2531294B4 for ; Tue, 15 Nov 2016 19:59:08 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tJVqt6hfbz1HW; Wed, 16 Nov 2016 04:59:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479268746; bh=YktU0sho4K2NCaqXjcdiud5MJn1dnEenZX749i4Wayw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=INk3nZ0tsQu7nyALPRLRsOlQG4OUX0IC98cIq3v26+qPFdsKhrDjdyHa9Hyg5kLUm L0rh5Obv96yDbMPMjq+CvtkMRX/rdPHJepWv6scuZqPHAZRjPe6XSa6ybkJuF7VuKj iLbIEcIbJhXn5ymPGn9mE3i2P2Pg0xEoIfb2z5sQ= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id RLpN-Adey5HN; Wed, 16 Nov 2016 04:59:05 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Nov 2016 04:59:05 +0100 (CET) Received: from [31.133.136.30] (unknown [31.133.136.30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 4787B35A2B3; Tue, 15 Nov 2016 22:59:03 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 4787B35A2B3 Content-Type: multipart/alternative; boundary=Apple-Mail-DBCC1C9D-9CE1-4727-90BC-168C702E0388 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Wed, 16 Nov 2016 12:59:00 +0900 Content-Transfer-Encoding: 7bit Message-Id: <2AB1A11D-76D5-4849-9F43-36AC039F191A@nohats.ca> References: <4E665C5B-BC28-428E-9BFB-626D3364E05B@nohats.ca> To: Phillip Hallam-Baker Archived-At: Cc: "trans@ietf.org" , Ben Laurie Subject: Re: [Trans] How to redact an entry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 03:59:11 -0000 --Apple-Mail-DBCC1C9D-9CE1-4727-90BC-168C702E0388 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A suppression of a fake gmail.com cert in the logs so google will never know= a rogue cert was issued and used? Sent from my iPhone > On Nov 16, 2016, at 12:54, Phillip Hallam-Baker wro= te: >=20 > That particular attack is certainly an issue for some linked notary logs. T= he point of CT is to prevent insertion attacks, to ensure that only items en= tered into the log are notarized. >=20 > What is the harm you see being caused by suppression? Remember that a part= y that has the actual data can still prove that it was enrolled. >=20 >=20 >> On Tue, Nov 15, 2016 at 10:46 PM, Paul Wouters wrote: >> How can I as log consumer detect the difference between the log removing i= llegal content and the log being compelled by a government to hide a rogue c= ertificate? >>=20 >> Sent from my iPhone >>=20 >>> On Nov 16, 2016, at 10:01, Phillip Hallam-Baker w= rote: >>>=20 >>>=20 >>>=20 >>>> On Tue, Nov 15, 2016 at 2:49 PM, Ben Laurie wrote: >>>> Eran asked me to briefly describe how redaction in a transparency log >>>> would work. >>>>=20 >>>> First, we introduce a new leaf type, "Redacted". The content of this >>>> leaf is simply the hash of the original leaf, the entry number of the >>>> redaction reason entry (see below) and a signature over the content by >>>> the log key. >>>>=20 >>>> Rather than hashing this entry, verifiers simply use the enclosed hash >>>> to calculate the tree hash. >>>>=20 >>>> Secondly, we introduce a second new leaf type, "Redaction reason". >>>> This leaf contains two things: the entry number of the redacted entry >>>> and a textual explanation of why it was redacted (possibly we need to >>>> get a little more elaborate here, but perhaps the simplest thing to do >>>> is to allow it to include URLs to point to any supporting material). >>>> This leaf type would be hashed in the usual way. >>>>=20 >>>> Observers of the log can verify that every redacted entry has a >>>> corresponding redaction reason entry, and if not, can produce proof it >>>> does not (this is why the redacted entry has to be signed directly). >>>>=20 >>>> Note that the redacted entry could not include the entry number of the >>>> redaction reason, if preferred, though that would force an observer of >>>> that entry to download the whole log to verify the reason and also >>>> would make proof of non-compliance bulky. :-) >>>=20 >>> =E2=80=8BI decided I had to do something of this sort in the Mesh notary= log. It is probably a good idea to do it as a matter of course. >>>=20 >>> Lets consider the general case for a moment, what happens if someone put= s some child pornography into the log. Obviously you can't publish it or you= go to jail. So you have to take it out which breaks the log. >>>=20 >>> So either you have to devise a scheme that you are certain cannot be use= d to publish abusive material or you have to have a way to suppress it eithe= r. I think the second approach is better. >>>=20 >>>=20 >>> Of course putting bad stuff in a Trans log would be a lot more effort th= an putting it into the blockchain or the like. But don't think it is impossi= ble. I have a few attacks that are worrying enough not to want to share in p= ublic. The sort of thing that has Special Branch making house calls. >>>=20 >>> So I would hash the received data values before enrolling the hash in th= e notary log as a matter of course. >>> _______________________________________________ >>> Trans mailing list >>> Trans@ietf.org >>> https://www.ietf.org/mailman/listinfo/trans >=20 --Apple-Mail-DBCC1C9D-9CE1-4727-90BC-168C702E0388 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
A suppression of a fake gmail.com cert in the logs so google will never know a ro= gue cert was issued and used?

Sent from my iPhone

On No= v 16, 2016, at 12:54, Phillip Hallam-Baker <ietf@hallambaker.com> wrote:

That particular attack is certainly an issue for some linked nota= ry logs. The point of CT is to prevent insertion attacks, to ensure that onl= y items entered into the log are notarized.

What is the harm you see being caused by suppression? Remem= ber that a party that has the actual data can still prove that it was enroll= ed.


On Tue, Nov 15, 2016= at 10:46 PM, Paul Wouters <paul@nohats.ca> wrote:
How can I as log consumer detect t= he difference between the log removing illegal content and the log being com= pelled by a government to hide a rogue certificate?

Sent from my iPho= ne

On Nov 16, 2016, at 10:01, Phillip H= allam-Baker <ie= tf@hallambaker.com> wrote:



On Tue, Nov 15, 2016 at 2:49 PM, B= en Laurie <benl@google.com> wrote:
Eran asked me to briefly describe how redaction in a transparency log would work.

First, we introduce a new leaf type, "Redacted". The content of this
leaf is simply the hash of the original leaf, the entry number of the
redaction reason entry (see below) and a signature over the content by
the log key.

Rather than hashing this entry, verifiers simply use the enclosed hash
to calculate the tree hash.

Secondly, we introduce a second new leaf type, "Redaction reason".
This leaf contains two things: the entry number of the redacted entry
and a textual explanation of why it was redacted (possibly we need to
get a little more elaborate here, but perhaps the simplest thing to do
is to allow it to include URLs to point to any supporting material).
This leaf type would be hashed in the usual way.

Observers of the log can verify that every redacted entry has a
corresponding redaction reason entry, and if not, can produce proof it
does not (this is why the redacted entry has to be signed directly).

Note that the redacted entry could not include the entry number of the
redaction reason, if preferred, though that would force an observer of
that entry to download the whole log to verify the reason and also
would make proof of non-compliance bulky. :-)

=E2=80=8BI decided I had to do somethin= g of this sort in the Mesh notary log. It is probably a good idea to do it a= s a matter of course.

Lets consider the general case for a moment, what hap= pens if someone puts some child pornography into the log. Obviously you can'= t publish it or you go to jail. So you have to take it out which breaks the l= og.

So either you have to devise a scheme that you are certain cannot be us= ed to publish abusive material or you have to have a way to suppress it eith= er. I think the second approach is better.


Of course putting bad stuff in a Trans log would be a lot more effo= rt than putting it into the blockchain or the like. But don't think it is im= possible. I have a few attacks that are worrying enough not to want to share= in public. The sort of thing that has Special Branch making house calls.

So I would hash the received data values before enrolling the hash in t= he notary log as a matter of course.
________= _______________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/<= wbr>listinfo/trans

= --Apple-Mail-DBCC1C9D-9CE1-4727-90BC-168C702E0388-- From nobody Tue Nov 15 20:10:05 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7F91294F7 for ; Tue, 15 Nov 2016 20:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1CABDxR7zrV for ; Tue, 15 Nov 2016 20:10:01 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F02129532 for ; Tue, 15 Nov 2016 20:09:58 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id f82so44577067wmf.1 for ; Tue, 15 Nov 2016 20:09:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=i0rdkctrsAymjIH4UdfOzILvG12LYBMlG2RD+N38s3o=; b=gOJEMO9OTTCwrK7IhQN7Hg2ALRaWx6riDkYWLspLjZjKXbLAVngRRoM9uiigzpObgb 5k4HOiTGIjEuODvuO97eB8+2y8Zr/hayYhc6lZy7rzssJ6qe+RDeETOpaT/iCX3qoDBe k2T/hDkX5I1fYS9GVtD8muZkQ+FCiEUIzvpRrf470fLFBUqbBKg7zRyo8IMRg2JD0qCJ Dm2kdFxsUlhoQu6obZCEz6/5Ycg8ReEJsurIDbSedOQ8JXBXzqndNs4Mxt74RYVRXM+7 HNy7JoS6qyAhdggGoK19636txFqo+H1akx4s0oFVigAsio4GA4uXyccbktpeYBjNq162 wBbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=i0rdkctrsAymjIH4UdfOzILvG12LYBMlG2RD+N38s3o=; b=J24Qby4DEPQOwtcq2B7k4UY5f7dFwFChKMjbhRPYBXDW8ngfLXEWcuKQT9Heh5mS9l 0Bc21nbjYmDfEcqW8tK+WucM8E0bNXUihCxpVPId5Zi0uocuWOhXVTSUa2x/cZoB41WX NySCk4Sq20pnefxoxVRltEnEs5E96zdhpktFk6l6qyzSgB7OsXLJVeNGyLLQ0ex8ct8T WE3lT2deoh4j9GcABd8oRYS1VwBDq6FQqPX70iC0gc6djMYkUWSPZzil9wvu0UfCbo2p FBe+8a8a+h5uzgTynl5ZwwEbSqaLcI1L9PKhsi2dE+EwxMse5m3J14TmKUs8QAHqKUQm ezag== X-Gm-Message-State: ABUngveQ8vxU7pSF0qCyhYnPtjMDE2D78yb1QWnLmbWV2+KHhRKVY3NKG5EF23Gjz1CKWH8+59GSHSbZaVykCA== X-Received: by 10.28.198.67 with SMTP id w64mr7633615wmf.13.1479269396858; Tue, 15 Nov 2016 20:09:56 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.3.41 with HTTP; Tue, 15 Nov 2016 20:09:56 -0800 (PST) In-Reply-To: <2AB1A11D-76D5-4849-9F43-36AC039F191A@nohats.ca> References: <4E665C5B-BC28-428E-9BFB-626D3364E05B@nohats.ca> <2AB1A11D-76D5-4849-9F43-36AC039F191A@nohats.ca> From: Phillip Hallam-Baker Date: Tue, 15 Nov 2016 23:09:56 -0500 X-Google-Sender-Auth: emD6GIAgUNalRO02EH1Hx4it8DM Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=94eb2c193638ed4e150541633e05 Archived-At: Cc: "trans@ietf.org" , Ben Laurie Subject: Re: [Trans] How to redact an entry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 04:10:04 -0000 --94eb2c193638ed4e150541633e05 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, if you have collusion between the govt making the suppression order and the attacker (or they are the same)... Problem is that otherwise a hostile party can make a DoS attack against the whole system... agh,,, On Tue, Nov 15, 2016 at 10:59 PM, Paul Wouters wrote: > A suppression of a fake gmail.com cert in the logs so google will never > know a rogue cert was issued and used? > > Sent from my iPhone > > On Nov 16, 2016, at 12:54, Phillip Hallam-Baker > wrote: > > That particular attack is certainly an issue for some linked notary logs. > The point of CT is to prevent insertion attacks, to ensure that only item= s > entered into the log are notarized. > > What is the harm you see being caused by suppression? Remember that a > party that has the actual data can still prove that it was enrolled. > > > On Tue, Nov 15, 2016 at 10:46 PM, Paul Wouters wrote: > >> How can I as log consumer detect the difference between the log removing >> illegal content and the log being compelled by a government to hide a ro= gue >> certificate? >> >> Sent from my iPhone >> >> On Nov 16, 2016, at 10:01, Phillip Hallam-Baker >> wrote: >> >> >> >> On Tue, Nov 15, 2016 at 2:49 PM, Ben Laurie wrote: >> >>> Eran asked me to briefly describe how redaction in a transparency log >>> would work. >>> >>> First, we introduce a new leaf type, "Redacted". The content of this >>> leaf is simply the hash of the original leaf, the entry number of the >>> redaction reason entry (see below) and a signature over the content by >>> the log key. >>> >>> Rather than hashing this entry, verifiers simply use the enclosed hash >>> to calculate the tree hash. >>> >>> Secondly, we introduce a second new leaf type, "Redaction reason". >>> This leaf contains two things: the entry number of the redacted entry >>> and a textual explanation of why it was redacted (possibly we need to >>> get a little more elaborate here, but perhaps the simplest thing to do >>> is to allow it to include URLs to point to any supporting material). >>> This leaf type would be hashed in the usual way. >>> >>> Observers of the log can verify that every redacted entry has a >>> corresponding redaction reason entry, and if not, can produce proof it >>> does not (this is why the redacted entry has to be signed directly). >>> >>> Note that the redacted entry could not include the entry number of the >>> redaction reason, if preferred, though that would force an observer of >>> that entry to download the whole log to verify the reason and also >>> would make proof of non-compliance bulky. :-) >>> >> >> =E2=80=8BI decided I had to do something of this sort in the Mesh notary= log. It >> is probably a good idea to do it as a matter of course. >> >> Lets consider the general case for a moment, what happens if someone put= s >> some child pornography into the log. Obviously you can't publish it or y= ou >> go to jail. So you have to take it out which breaks the log. >> >> So either you have to devise a scheme that you are certain cannot be use= d >> to publish abusive material or you have to have a way to suppress it >> either. I think the second approach is better. >> >> >> Of course putting bad stuff in a Trans log would be a lot more effort >> than putting it into the blockchain or the like. But don't think it is >> impossible. I have a few attacks that are worrying enough not to want to >> share in public. The sort of thing that has Special Branch making house >> calls. >> >> So I would hash the received data values before enrolling the hash in th= e >> notary log as a matter of course. >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> >> > --94eb2c193638ed4e150541633e05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yea= h, if you have collusion between the govt making the suppression order and = the attacker (or they are the same)...

Problem is that otherwise a hostile party can make a DoS atta= ck against the whole system...

agh,,,

On = Tue, Nov 15, 2016 at 10:59 PM, Paul Wouters <paul@nohats.ca> = wrote:
A suppressi= on of a fake gmail.com c= ert in the logs so google will never know a rogue cert was issued and used?=

Sent from my iPhone

On Nov 16,= 2016, at 12:54, Phillip Hallam-Baker <ietf@hallambaker.com> wrote:

<= blockquote type=3D"cite">
That particular attack is certainly an issue for= some linked notary logs. The point of CT is to prevent insertion attacks, = to ensure that only items entered into the log are notarized.

What is the harm you see being caused = by suppression? Remember that a party that has the actual data can still pr= ove that it was enrolled.


On Tue, Nov 15, 2016 at 10:46 PM, Paul Wouters <paul@nohats.ca> wrote:
How ca= n I as log consumer detect the difference between the log removing illegal = content and the log being compelled by a government to hide a rogue certifi= cate?

Sent from my iPhone

On Nov 16, 2016, at 10:01, Phillip Hallam-Baker <ietf@hallambaker.com> wrote:


On Tue, Nov 15, 2016 at 2:49 PM, Ben Laurie <benl@goo= gle.com> wrote:
Eran asked = me to briefly describe how redaction in a transparency log
would work.

First, we introduce a new leaf type, "Redacted". The content of t= his
leaf is simply the hash of the original leaf, the entry number of the
redaction reason entry (see below) and a signature over the content by
the log key.

Rather than hashing this entry, verifiers simply use the enclosed hash
to calculate the tree hash.

Secondly, we introduce a second new leaf type, "Redaction reason"= .
This leaf contains two things: the entry number of the redacted entry
and a textual explanation of why it was redacted (possibly we need to
get a little more elaborate here, but perhaps the simplest thing to do
is to allow it to include URLs to point to any supporting material).
This leaf type would be hashed in the usual way.

Observers of the log can verify that every redacted entry has a
corresponding redaction reason entry, and if not, can produce proof it
does not (this is why the redacted entry has to be signed directly).

Note that the redacted entry could not include the entry number of the
redaction reason, if preferred, though that would force an observer of
that entry to download the whole log to verify the reason and also
would make proof of non-compliance bulky. :-)

=E2=80=8BI decided I had to do someth= ing of this sort in the Mesh notary log. It is probably a good idea to do i= t as a matter of course.

Lets consider the general case for a moment, wha= t happens if someone puts some child pornography into the log. Obviously yo= u can't publish it or you go to jail. So you have to take it out which = breaks the log.

So either you have to devise a scheme that you are certai= n cannot be used to publish abusive material or you have to have a way to s= uppress it either. I think the second approach is better.


Of course putting bad stuff in a Trans log woul= d be a lot more effort than putting it into the blockchain or the like. But= don't think it is impossible. I have a few attacks that are worrying e= nough not to want to share in public. The sort of thing that has Special Br= anch making house calls.

So I would hash the received data values b= efore enrolling the hash in the notary log as a matter of course.
_______= ________________________________________
Trans m= ailing list
Trans@ietf.org
https://www.ietf.org/mailman/li= stinfo/trans


--94eb2c193638ed4e150541633e05-- From nobody Wed Nov 16 03:16:53 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF416129400 for ; Wed, 16 Nov 2016 03:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEiVMW4K7mEq for ; Wed, 16 Nov 2016 03:16:49 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88161288B8 for ; Wed, 16 Nov 2016 03:16:49 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id w194so111968840vkw.2 for ; Wed, 16 Nov 2016 03:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kMp/tF0+Nh7cpMK0TYPFT+pil7q5BGKbDUVFuZz1qu8=; b=lkraq5YNqgUB6Z9ipBbd96PL42wplwy7Asr9uysYK3rhzYKFETU0ssOF27lEGZ+k48 Nmi3ESZjwqNSRMvO8awCcQGNlTb1fQoXFyNndkj4LWiZKNgHDx455lpMdN54Mj94cQm7 o/jxnW25v4PtwVeR4p8vYL877TQGvr03lFL36/n0NBLWSt4U8vSNIeD5IQcEuNjey9EJ 56oZEQeyb5/Z3yp7kkKaim4Edk4KuafVXzrmxp8cUyI/f0daTjSJpJaZZ3ae0nF6KDaR DtCYpKq7fgnvTycBRS4i2IKFwR/ykfenANW9GetAIjuVkgDpzpylhVbcVAI/14Nef+ik T5fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kMp/tF0+Nh7cpMK0TYPFT+pil7q5BGKbDUVFuZz1qu8=; b=lnlCsyC7NEF7fW6Y6zlSePFexQAfJJbk3DEkrDkaP1AortfnkSpR6j3qxEz55VYwos pFK2wZmp3ufITJ1IgHQhR26XtAR5Ff2QC0dJCWUUPIX9olvyxWPB0pqxS47rkd486G/L Ht/fnWNuq5RrqZPWMzPqxN+sf+iD3eddveikLXKwrEs9iegt2rTA/MEn8wHz42RRc0Kw xl7BfSnJ6k3fSI6cfSRsCsE9wp5XJEku5TcQyFW+1zDCTANIIHS4MiuEOiLTg1e5RUNP RwQU9CpRIKJRlBBB0JqStMdnHx6W4WkJeDfS6BfobQeIxLaYSJ+qrI8ICH0BFHDtlBYC Zj5w== X-Gm-Message-State: ABUngvduXJgdTlAY0Xfori9HgkFnbwCRFuhNrqqm8ZzOvabJHRbf7c+4zerXE/ureJtEoTSzK5JUjTXQ27M20+kK X-Received: by 10.31.16.36 with SMTP id g36mr901147vki.170.1479295008419; Wed, 16 Nov 2016 03:16:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.162.67 with HTTP; Wed, 16 Nov 2016 03:16:47 -0800 (PST) In-Reply-To: <4E665C5B-BC28-428E-9BFB-626D3364E05B@nohats.ca> References: <4E665C5B-BC28-428E-9BFB-626D3364E05B@nohats.ca> From: Ben Laurie Date: Wed, 16 Nov 2016 11:16:47 +0000 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Phillip Hallam-Baker , "trans@ietf.org" Subject: Re: [Trans] How to redact an entry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 11:16:52 -0000 On 16 November 2016 at 03:46, Paul Wouters wrote: > How can I as log consumer detect the difference between the log removing > illegal content and the log being compelled by a government to hide a rogue > certificate? Court orders are court orders. That issue is not in the log's domain. > > Sent from my iPhone > > On Nov 16, 2016, at 10:01, Phillip Hallam-Baker > wrote: > > > > On Tue, Nov 15, 2016 at 2:49 PM, Ben Laurie wrote: >> >> Eran asked me to briefly describe how redaction in a transparency log >> would work. >> >> First, we introduce a new leaf type, "Redacted". The content of this >> leaf is simply the hash of the original leaf, the entry number of the >> redaction reason entry (see below) and a signature over the content by >> the log key. >> >> Rather than hashing this entry, verifiers simply use the enclosed hash >> to calculate the tree hash. >> >> Secondly, we introduce a second new leaf type, "Redaction reason". >> This leaf contains two things: the entry number of the redacted entry >> and a textual explanation of why it was redacted (possibly we need to >> get a little more elaborate here, but perhaps the simplest thing to do >> is to allow it to include URLs to point to any supporting material). >> This leaf type would be hashed in the usual way. >> >> Observers of the log can verify that every redacted entry has a >> corresponding redaction reason entry, and if not, can produce proof it >> does not (this is why the redacted entry has to be signed directly). >> >> Note that the redacted entry could not include the entry number of the >> redaction reason, if preferred, though that would force an observer of >> that entry to download the whole log to verify the reason and also >> would make proof of non-compliance bulky. :-) > > > I decided I had to do something of this sort in the Mesh notary log. It is > probably a good idea to do it as a matter of course. > > Lets consider the general case for a moment, what happens if someone puts > some child pornography into the log. Obviously you can't publish it or you > go to jail. So you have to take it out which breaks the log. > > So either you have to devise a scheme that you are certain cannot be used to > publish abusive material or you have to have a way to suppress it either. I > think the second approach is better. > > > Of course putting bad stuff in a Trans log would be a lot more effort than > putting it into the blockchain or the like. But don't think it is > impossible. I have a few attacks that are worrying enough not to want to > share in public. The sort of thing that has Special Branch making house > calls. > > So I would hash the received data values before enrolling the hash in the > notary log as a matter of course. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Wed Nov 16 03:23:15 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94D1129421 for ; Wed, 16 Nov 2016 03:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VUUKpxCMBhf for ; Wed, 16 Nov 2016 03:23:07 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB271297C4 for ; Wed, 16 Nov 2016 03:22:50 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id 12so111445361uas.2 for ; Wed, 16 Nov 2016 03:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iaToy1fVkUePNqQmQJvIF4s+eQLYGk8PbiuPzOGpCE4=; b=kv3BcTEYfNb24FOLE2BlF+12WkZHf+eON6eewhCSfdJlOnq0orebBhNACxWC7btrvU tC4OugeP+JlraUOxxB6EvQ84gQW2hAjmkxxhd71pnqbjxtmkCF6DHPQMcK7+0jmw32Vf P0NI243Z/OXIUpklgWyK5kM9sEvvrCVrkok8diF5Fh30I6MqqQaSAIvperMMpvpboc8n u6xstksaAMRuA7b1ZIwWyaQ9H1bKK1vbTPEooFdoozJZ49l565eYZCbY0qcnew+WwRaR RgMdS/JYduq5OPO5V/mUbZXnB3nF8xRQwbDssX/HX8y51mVG0DP2ATEhiu5i1Kw1qwtq 6okQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iaToy1fVkUePNqQmQJvIF4s+eQLYGk8PbiuPzOGpCE4=; b=QwV71WOwe0NwFkmbF8RY04F4LBhoNlfDT8KJzewUJCYIL4YSMbcdJzvSzVHlV9oLGn YpSSMtxFv9d8Yu/poOe2J6vF6o7TCmdxat0jYABiB5u54ZMoKiTNWfdVFPCS8DTKiRQ5 K1QfLD7GcoCjDW+Lyhp2BtfyNnpeM3+BIlX0sl0VOaNFMzvRp6BgEWLKDFfVIQ0pxSyf 2IAlElj15SSqEJNnkjs4TpvC6eymNfaj3288A8Hfw+HRa09pNEm11CzJD2tISsvMLlIy oiEDSQcIVWQ97Eq5VpwB+EZmHjptcbBbNLqoCcE1reers4+3ZbCkigOrHqER+Dbaihi4 f0fA== X-Gm-Message-State: ABUngvcpcD/hfgkMoO8VgP5GograOhntmN+r+k+iq0AicZhZgZDNY1XGsQSbm16T76o4Yt6TeClzqKciWR4WP3ge X-Received: by 10.176.83.211 with SMTP id l19mr1020949uaa.69.1479295368874; Wed, 16 Nov 2016 03:22:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.162.67 with HTTP; Wed, 16 Nov 2016 03:22:48 -0800 (PST) In-Reply-To: References: <4E665C5B-BC28-428E-9BFB-626D3364E05B@nohats.ca> From: Ben Laurie Date: Wed, 16 Nov 2016 11:22:48 +0000 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Phillip Hallam-Baker , "trans@ietf.org" Subject: Re: [Trans] How to redact an entry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 11:23:14 -0000 On 16 November 2016 at 11:16, Ben Laurie wrote: > On 16 November 2016 at 03:46, Paul Wouters wrote: >> How can I as log consumer detect the difference between the log removing >> illegal content and the log being compelled by a government to hide a rogue >> certificate? > > Court orders are court orders. That issue is not in the log's domain. BTW, anyone who sees the actual cert would presumably verify it, find the entry is redacted, and publish the cert (or decide they were also bound by the order cited in the redaction reason and not publish it :-). We could say, for example, that a cert whose entry has been redacted MUST NOT be used further. > >> >> Sent from my iPhone >> >> On Nov 16, 2016, at 10:01, Phillip Hallam-Baker >> wrote: >> >> >> >> On Tue, Nov 15, 2016 at 2:49 PM, Ben Laurie wrote: >>> >>> Eran asked me to briefly describe how redaction in a transparency log >>> would work. >>> >>> First, we introduce a new leaf type, "Redacted". The content of this >>> leaf is simply the hash of the original leaf, the entry number of the >>> redaction reason entry (see below) and a signature over the content by >>> the log key. >>> >>> Rather than hashing this entry, verifiers simply use the enclosed hash >>> to calculate the tree hash. >>> >>> Secondly, we introduce a second new leaf type, "Redaction reason". >>> This leaf contains two things: the entry number of the redacted entry >>> and a textual explanation of why it was redacted (possibly we need to >>> get a little more elaborate here, but perhaps the simplest thing to do >>> is to allow it to include URLs to point to any supporting material). >>> This leaf type would be hashed in the usual way. >>> >>> Observers of the log can verify that every redacted entry has a >>> corresponding redaction reason entry, and if not, can produce proof it >>> does not (this is why the redacted entry has to be signed directly). >>> >>> Note that the redacted entry could not include the entry number of the >>> redaction reason, if preferred, though that would force an observer of >>> that entry to download the whole log to verify the reason and also >>> would make proof of non-compliance bulky. :-) >> >> >> I decided I had to do something of this sort in the Mesh notary log. It is >> probably a good idea to do it as a matter of course. >> >> Lets consider the general case for a moment, what happens if someone puts >> some child pornography into the log. Obviously you can't publish it or you >> go to jail. So you have to take it out which breaks the log. >> >> So either you have to devise a scheme that you are certain cannot be used to >> publish abusive material or you have to have a way to suppress it either. I >> think the second approach is better. >> >> >> Of course putting bad stuff in a Trans log would be a lot more effort than >> putting it into the blockchain or the like. But don't think it is >> impossible. I have a few attacks that are worrying enough not to want to >> share in public. The sort of thing that has Special Branch making house >> calls. >> >> So I would hash the received data values before enrolling the hash in the >> notary log as a matter of course. >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans From nobody Wed Nov 16 03:26:32 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D95129781 for ; Wed, 16 Nov 2016 03:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ7zNZB2rjUG for ; Wed, 16 Nov 2016 03:26:29 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D08D129771 for ; Wed, 16 Nov 2016 03:26:28 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id 137so112351688vkl.0 for ; Wed, 16 Nov 2016 03:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YarAXYAA9nGo54ChegZrUZ29/cH2fP2irHnHtOPc2Jg=; b=Ij1PJGVOggDe7Px4geNHBl/xupOpbGjj1C+Fq4b1L5b6rPwuOPFxMouIF9xg6XoYS3 30P1CxyVye3cS4K1fmEp3GHu6mGntb3IMTtlyGbrpaVbAOs549ZT6I3fQgMxXHqI1C5d Zui+Te89h1fvLMsZpIszQ9/harHu7j3J/Ml+AdAl0g0X086WYl3tsDtTD/C2kzSQqFDq QFJ0IW9/E4Gm9kDNNZaVOiEkVz/10EJBmONHsR/ng25AbJX9sOIDY3U6tW1NiBJdNM/H PSRogZHRBo3ICK0gUaP1ePxPHc3Qx3Uq0WREfsBF7Z7lDkXatcEynnfShxEe1mvQfG3j xVjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YarAXYAA9nGo54ChegZrUZ29/cH2fP2irHnHtOPc2Jg=; b=QrhrkQTWJ2keCp+1uZZXCCmOqlkPxS6j+YBXvUpC9TbNXjzubcQ0n+R1OpxJ3ZaLUk zaXQiFn/eH/PG/Kv7Tq6E8j63dhwz73fGnzctCsPGHFmzgic9ssRM23BJr6HJy6gsO6q whn3sV54pWtXfTtiMXudeybaAI/ITqiDajGt3WcSsb3mYQ+S5GzD5pAUKjDje3nQPPO+ HYFNY+j8BSJnQ4qcCFFwxSU8/fmP6JwvrEWDlWVvtsEUiqAzf4Fa/LCG92RKH1UW33cl bSm6iJw0cmtxCAA4NhsxlCEwGJYMpNaIveg4nwiINcI0FDUSVL3YoCo3tu+hKzyqRwSh xeuA== X-Gm-Message-State: ABUngvceSCkpKZiN4n71HN+djlT8atwyjGGjOEPssTv/enofvb1Pe/5ZIbfPacOdL/ZymGvYlh3V3nXF+q/V2a1D X-Received: by 10.31.174.2 with SMTP id x2mr1127837vke.40.1479295587245; Wed, 16 Nov 2016 03:26:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.162.67 with HTTP; Wed, 16 Nov 2016 03:26:26 -0800 (PST) In-Reply-To: References: <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> From: Ben Laurie Date: Wed, 16 Nov 2016 11:26:26 +0000 Message-ID: To: Eran Messeri Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 11:26:31 -0000 On 16 November 2016 at 02:00, Eran Messeri wrote: > My proposed compromise at the trans workgroup meeting yesterday was to > change the MUST in the following paragraph to a SHOULD: > "Logs MUST accept certificates and precertificates that are fully valid > according to RFC 5280 verification rules and are submitted with such a > chain." > > I believe that this change allows creating logs that can reject valid > submissions under some circumstances while complying with 6962-bis. And we > wouldn't have to go through WGLC again for such a change. This seems like a reasonable plan (mildly surprised such a change can be made without WGLC, tho!). > > On Sat, Nov 5, 2016 at 12:42 AM, Ben Laurie wrote: >> >> On 4 November 2016 at 14:07, Peter Bowen wrote: >> > On Fri, Nov 4, 2016 at 6:33 AM, Ben Laurie wrote: >> >> >> >> The bit you didn't quote does say they the log has to accept valid >> >> certs, tho: "Logs MUST accept certificates and precertificates that >> >> are fully valid according to RFC 5280 [RFC5280] verification rules and >> >> are submitted with such a chain." >> > >> > Sorry about that. So the three MUSTs together are: >> > >> > - Logs MUST verify that each submitted certificate or precertificate >> > has a valid signature chain to an accepted trust anchor, using the >> > chain of intermediate CA certificates provided by the submitter. >> > >> > - Logs MUST reject submissions without a valid signature chain to an >> > accepted trust anchor. >> > >> > - Logs MUST accept certificates and precertificates that are fully >> > valid according to RFC 5280 verification rules and are submitted with >> > such a chain. >> > >> > When I read these together, I read that Logs must accept _any_ >> > certificate that is fully valid according to RFC 5280 verification >> > rules and chains to any root the log trusts and logs must _only_ log >> > such certificates (and no others). >> > >> > If this is accurate, we need to account for all types of certificates >> > being logged, as a log cannot choose to reject certificates for usages >> > other than server authentication and the log cannot reject >> > certificates that have personal information (e.g. an server >> > authentication certificate that states which human requested the >> > certificate in the subject). >> > >> > This seems like a very strong assertion of policy rather than a >> > technical discussion of how the CT protocol works. I would again ask >> > the WG to reconsider the requirement levels specified in this section. >> >> FWIW, I tend to agree. I would also note that operationally, we have >> already discussed options for logs that are incompatible with these >> requirements, for example: >> >> * sharded logs (e.g. by hash(cert) mod n). >> >> * logs that only accept short or long lifetime certificates (this >> would allow the working set to be reduced in size for CAs that issue a >> lot of short-lived certs). >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans > > From nobody Wed Nov 16 03:26:52 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FE0129784; Wed, 16 Nov 2016 03:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJWhEXw6K-7q; Wed, 16 Nov 2016 03:26:45 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38FAD12978C; Wed, 16 Nov 2016 03:26:43 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tJhmK1g64z3Hs; Wed, 16 Nov 2016 12:26:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479295601; bh=o2/1TUeOGluJhZZ6YxupBa0E/OUgh9ATdO39gFE5zcM=; h=Date:From:To:Subject; b=fvtbPHrtEn12I8exXInO1xser6p4fKzaZ8so2aNUP5tB7gb1Bcl76DvtRsisQTr6T sHAc2ptW784g3gmp8DFCXvDRThE6QKatZr2J6QW5Dw2Atlz1Tztbvfjx74BfAOhN/v bL6aRwo0/0nnkKa/uepVdnvwAfpESbymFpoougng= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yoNYU5LXL_X2; Wed, 16 Nov 2016 12:26:40 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Nov 2016 12:26:40 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 636A65C83A; Wed, 16 Nov 2016 06:26:38 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 636A65C83A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5EF1E40B7E88; Wed, 16 Nov 2016 06:26:38 -0500 (EST) Date: Wed, 16 Nov 2016 06:26:38 -0500 (EST) From: Paul Wouters To: saag@ietf.org, Trans Message-ID: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [Trans] Trans report for IETF 97 Seoul X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 11:26:47 -0000 We had a short meeting - Discussed the 6962bis document. * People agreed with section 5.1 MUST -> Should change. Eran will provide text in updated version. * Privacy concerns (personal certificates) out of scope for bis document (provided Section 5.1 is changed from MUST to SHOULD) * Once Section 5.1 is changed, document is ready for IESG. * Historic STH fetching - Agreement it does not affect bis document and can be done in new work for Log Monitoring API - Name Redaction * Some interest and new ideas. Continue discussion on mailing list - Threat document. Chairs asked for Editor on document as current author has been unavailable and updates discussed on the list take too long to get into the document. Eran volunteered (Thanks!) - Some new interest in binaries logging - No update to dnssec or gossip documents - Expect-CT header in TLS: To be discussed thursday at httpbis - Interest in Log monitoring API - to happen on the list. Paul and Melinda From nobody Wed Nov 16 03:39:18 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728BE1294E3 for ; Wed, 16 Nov 2016 03:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhX92xwQY6_I for ; Wed, 16 Nov 2016 03:39:16 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861AA129495 for ; Wed, 16 Nov 2016 03:39:16 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tJj2n5yP6z2m; Wed, 16 Nov 2016 12:39:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479296353; bh=xn1w2wXqoehQKuY+Bcm27udwPXvv00oOuWB5dBfoU2s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=JA3qiHMw+MSKycPNc4gLZpURp/zz3tXM2pqYTYAg+9JuHB4I7HvlX4Omqu0ZPy1bz q8VhuTQgt1XyFM7xHSZVbetWYsWc55z6kEosRuwkNLay06D3g70lmG+Q37sJa8/cZQ evS/a6zH0ssLP5uRPVSKxw+prlzbrToMF01uaFrE= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id H5VoC6bcZ13B; Wed, 16 Nov 2016 12:39:12 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Nov 2016 12:39:12 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0AA5A5C83A; Wed, 16 Nov 2016 06:39:12 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 0AA5A5C83A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0119240DAA4B; Wed, 16 Nov 2016 06:39:11 -0500 (EST) Date: Wed, 16 Nov 2016 06:39:11 -0500 (EST) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: <4E665C5B-BC28-428E-9BFB-626D3364E05B@nohats.ca> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: Phillip Hallam-Baker , "trans@ietf.org" Subject: Re: [Trans] How to redact an entry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 11:39:17 -0000 On Wed, 16 Nov 2016, Ben Laurie wrote: (no hats on) > On 16 November 2016 at 03:46, Paul Wouters wrote: >> How can I as log consumer detect the difference between the log removing >> illegal content and the log being compelled by a government to hide a rogue >> certificate? > > Court orders are court orders. That issue is not in the log's domain. It was an example. the core isuse is, how can a consumer determine the log censored itself with a valid reason, versus an attack, compromise, having been compelled, or for financial gain or any other invalid reason? Using a hash of a removed cert won't allow anyone to verify the reason for removal. And clearly the content cannot remain their either. It's a catch22. Paul From nobody Wed Nov 16 03:48:27 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF09C129793 for ; Wed, 16 Nov 2016 03:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ev-TADq18-mt for ; Wed, 16 Nov 2016 03:48:25 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531BB129494 for ; Wed, 16 Nov 2016 03:48:25 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id 12so111914928uas.2 for ; Wed, 16 Nov 2016 03:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CQnp/TaHzc1NzV5qhWm1aEMzUuKCMWSNYuJIU+FOJuw=; b=RId74NJ/THsSXviVyN+r9K8bETr+rCBSl0Q+yzP8tMbGPpebsVNPfbXvbeQMH9HL4/ NTVPP7uB2qxT0AwX5JLjqSHKXXDXPol/j3f6piRRR+4+HeMtsK7no07+0mXgWQske/M8 ljc23tjMTbvHIZ87WfxP9KXsFvBYWcmJMRGsuyINQboCjpd3GxDjt9lw1c2DAU3smMqv NsWPrSM/4bUwhAV+iFyOhT6nWbmCgHLt24Jvshc9k5CYfIJwKIBPc0hADOY40bPTGF93 RD9f0yeIv2a0W6PNdS306p1hvBM8PutD60it0TtlAUj+0JiVUFUL4Dzf6vGDAMjADrn0 OaJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CQnp/TaHzc1NzV5qhWm1aEMzUuKCMWSNYuJIU+FOJuw=; b=g3DXa2yGL6+6Cs0r14P4lMJ6qVWRrJ3umhfMt1S5osupPnzNe2FtZt8XGK0lVg6eP/ cvGpfRnWIfQuDOqIrM6T6r3kkhempCJTisPMPaOk0D3wvA0XioqLtOfWYxYK6bcgpTLe XS7xlZkVUBHyKJekZUhyVD2jQVf7qGoOO7en1P0VSG4G7RQaXpEZbDM7HLZZ1XuqsudS Bi1/7A4dYA94VifASLH2BVDSXd0hU1HSJixnpX0x7c7Ilmi0phTRUccW8siFSZOLAGRb P2XJswNM7qDfRSoISLWwPbJr3TPfunuY1Ac4tJzItwK7/ITHYhzgZv08AnU6YuF2Pmo2 B2ag== X-Gm-Message-State: ABUngvfKa2XDacNorFHL0uEhvR9BXd9iclCkuz4ObO7I6CxbKN8YP1f2fKNFaxY1BwRI7F45cU/p7UMqYMms6TXc X-Received: by 10.176.84.66 with SMTP id o2mr1387292uaa.148.1479296904303; Wed, 16 Nov 2016 03:48:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.140.82 with HTTP; Wed, 16 Nov 2016 03:48:19 -0800 (PST) In-Reply-To: References: <4E665C5B-BC28-428E-9BFB-626D3364E05B@nohats.ca> From: Ben Laurie Date: Wed, 16 Nov 2016 11:48:19 +0000 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Phillip Hallam-Baker , "trans@ietf.org" Subject: Re: [Trans] How to redact an entry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 11:48:27 -0000 On 16 November 2016 at 11:39, Paul Wouters wrote: > On Wed, 16 Nov 2016, Ben Laurie wrote: > > (no hats on) > >> On 16 November 2016 at 03:46, Paul Wouters wrote: >>> >>> How can I as log consumer detect the difference between the log removing >>> illegal content and the log being compelled by a government to hide a >>> rogue >>> certificate? >> >> >> Court orders are court orders. That issue is not in the log's domain. > > > It was an example. the core isuse is, how can a consumer determine the > log censored itself with a valid reason, versus an attack, compromise, > having been compelled, or for financial gain or any other invalid reason? > > Using a hash of a removed cert won't allow anyone to verify the reason > for removal. And clearly the content cannot remain their either. It's > a catch22. This is why the redaction reason entry exists, so that there _is_ something to reason about. If you (a consumer) are unconvinced by the reason, well, there are public fora where you can voice your concerns. From nobody Wed Nov 16 06:20:14 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95FA129518 for ; Wed, 16 Nov 2016 06:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwX-xQM9o1Mv for ; Wed, 16 Nov 2016 06:20:07 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544E912942F for ; Wed, 16 Nov 2016 06:20:06 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id t79so75851779wmt.0 for ; Wed, 16 Nov 2016 06:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=I57riaFtHyFmh9Evtyck6okh3D3pxeIO57Vfayq/4eo=; b=k/1LaadjuRCpDf3Wzltk/YavBUfpLP46+PkyYwM2jwmg3OfN+H8l2MLpr9ynJk06UW x0E2KKYd+3VCcOIi79uXWVCohdLjPHKxMzfFrD4ah3rDqPolRMI5W6sPPJ4vsmSPDrEi 6WOGoNPm31S+BgKhgZI+BrG7L7+NnYfhDlSPWr+qHwbbbI45BkZIgQ8JG2HXwfRX+XeY p948o0rxWciql9MbCvHRi5HoDvEJOXpUKundAQI5TpruafXISzBkJmTJEV0DiLjSSA+O x/4Rc8jbCeC1qlBYtLLVxJIAIJrhT2awkA60EpXPLLE+y3hZTgl8TaEmrz71v3Spr80W ut7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=I57riaFtHyFmh9Evtyck6okh3D3pxeIO57Vfayq/4eo=; b=jgeoPtkBJWBAbfGAPyEnpjF7DvSyiMhvYu74WTDT6VTbKvvcgbIeuNaodHkVIiK/qp qjeV3pfF7x0l6uXlW/SiSAkRYbTC3sAYeFgGgvVRlijebDwYTJwz90LcynY+27iB14X4 xtkmHOEC2ScVCvTHAF4AC+P0V3bVOamtDH3FQhmiaM348s0x/D0BTp3vUgshAIRF51+q urKl99i0wmm6JCerDysKBPZSnAI0/zK3TOyDAsC19vp9NRDIboYaI7eba9vAem4wMO3b mmBybpQJoCuUZYzaSN98iqKIHFrWK7+ca+JQilZwgMbOqQs9Njp7D1TsTpyd2K8E9Bc3 uUwA== X-Gm-Message-State: ABUngvc0mIKjoxhzCZ8Dyw7NDMVZIWboa7Hp7YCsGPk6T1k27lNdi7vubD9bAUTUDujR8yBC8/CpAsaO2f/kIg== X-Received: by 10.194.14.196 with SMTP id r4mr2584643wjc.54.1479306004813; Wed, 16 Nov 2016 06:20:04 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.3.41 with HTTP; Wed, 16 Nov 2016 06:20:03 -0800 (PST) In-Reply-To: References: <4E665C5B-BC28-428E-9BFB-626D3364E05B@nohats.ca> From: Phillip Hallam-Baker Date: Wed, 16 Nov 2016 09:20:03 -0500 X-Google-Sender-Auth: hdeunzsBC3KYS98I1wY6E0bqKM0 Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=047d7b66fd9dee5cd105416bc4f1 Archived-At: Cc: Paul Wouters , "trans@ietf.org" Subject: Re: [Trans] How to redact an entry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 14:20:13 -0000 --047d7b66fd9dee5cd105416bc4f1 Content-Type: text/plain; charset=UTF-8 Lets break this down. In what way is suppression of a previously enrolled certificate different to not enrolling the certificate at all? The only ones I can see is that it means that 1) the CA is off the hook, they fulfilled their duties and 2) the fact that suppression has occurred is visible. CT relies on there being some feedback mechanism to detect unenrolled certs, the same would apply to suppressed certs. So let us imagine that a government coerces a CA to issue a bogus cert and then coerces a notary to suppress it. What next? Well first off anyone who has a copy of that cert taken from the repository before the suppression is going to hard look at it. So the chance of people being aware of the suppression and working out the reason for it is essentially 99%. A person formerly very senior in NSA told me that the governing paradigm post Snowden was 'NOBUS': Nobody but us. Sure they might want to perform this type of attack if they think they can get away with it but they won't do things that are liable to get caught. On Wed, Nov 16, 2016 at 6:48 AM, Ben Laurie wrote: > On 16 November 2016 at 11:39, Paul Wouters wrote: > > On Wed, 16 Nov 2016, Ben Laurie wrote: > > > > (no hats on) > > > >> On 16 November 2016 at 03:46, Paul Wouters wrote: > >>> > >>> How can I as log consumer detect the difference between the log > removing > >>> illegal content and the log being compelled by a government to hide a > >>> rogue > >>> certificate? > >> > >> > >> Court orders are court orders. That issue is not in the log's domain. > > > > > > It was an example. the core isuse is, how can a consumer determine the > > log censored itself with a valid reason, versus an attack, compromise, > > having been compelled, or for financial gain or any other invalid reason? > > > > Using a hash of a removed cert won't allow anyone to verify the reason > > for removal. And clearly the content cannot remain their either. It's > > a catch22. > > This is why the redaction reason entry exists, so that there _is_ > something to reason about. If you (a consumer) are unconvinced by the > reason, well, there are public fora where you can voice your concerns. > --047d7b66fd9dee5cd105416bc4f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let= s break this down.

In wha= t way is suppression of a previously enrolled certificate different to not = enrolling the certificate at all?

The only ones I can see is that it means that 1) the CA is off t= he hook, they fulfilled their duties and 2) the fact that suppression has o= ccurred is visible.


<= /div>
CT relies on th= ere being some feedback mechanism to detect unenrolled certs, the same woul= d apply to suppressed certs.

So let us imagine that a government coerces a CA to issue a bogus cert = and then coerces a notary to suppress it. What next?

Well first off anyone who has a copy of that ce= rt taken from the repository before the suppression is going to hard look a= t it. So the chance of people being aware of the suppression and working ou= t the reason for it is essentially 99%.


A person formerly very senior in NSA told me that the governing paradi= gm post Snowden was 'NOBUS': Nobody but us. Sure they might want to= perform this type of attack if they think they can get away with it but th= ey won't do things that are liable to get caught.




On Wed, Nov 16, 2016 at 6:48 AM, Ben Laurie <benl@goog= le.com> wrote:
On 16 November 2016 at 11:39, Paul Wouters <paul@nohats.ca> wrote:
> On Wed, 16 Nov 2016, Ben Laurie wrote:
>
> (no hats on)
>
>> On 16 November 2016 at 03:46, Paul Wouters <paul@nohats.ca> wrote:
>>>
>>> How can I as log consumer detect the difference between the lo= g removing
>>> illegal content and the log being compelled by a government to= hide a
>>> rogue
>>> certificate?
>>
>>
>> Court orders are court orders. That issue is not in the log's = domain.
>
>
> It was an example. the core isuse is, how can a consumer determine the=
> log censored itself with a valid reason, versus an attack, compromise,=
> having been compelled, or for financial gain or any other invalid reas= on?
>
> Using a hash of a removed cert won't allow anyone to verify the re= ason
> for removal. And clearly the content cannot remain their either. It= 9;s
> a catch22.

This is why the redaction reason entry exists, so that there _is_ something to reason about. If you (a consumer) are unconvinced by the
reason, well, there are public fora where you can voice your concerns.

--047d7b66fd9dee5cd105416bc4f1-- From nobody Wed Nov 16 16:45:22 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A0F12951B for ; Wed, 16 Nov 2016 16:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFQHkPiGCtnk for ; Wed, 16 Nov 2016 16:45:19 -0800 (PST) Received: from tussmtoutape02.symantec.com (tussmtoutape02.symantec.com [155.64.38.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDCD71294FD for ; Wed, 16 Nov 2016 16:45:18 -0800 (PST) Received: from tussmtmtaapi02.symc.symantec.com (tus3-f5-symc-ext-prd-snat5.net.symantec.com [10.44.130.5]) by tussmtoutape02.symantec.com (Symantec Messaging Gateway) with SMTP id F4.82.43065.E9DFC285; Thu, 17 Nov 2016 00:45:18 +0000 (GMT) X-AuditID: 0a2c7e32-2e5639a00000a839-9a-582cfd9eccc5 Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (tus3-f5-symc-ext-prd-snat4.net.symantec.com [10.44.130.4]) by tussmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 2B.9F.21197.C9DFC285; Thu, 17 Nov 2016 00:45:18 +0000 (GMT) Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 16 Nov 2016 16:45:15 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.128.2) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Wed, 16 Nov 2016 16:45:15 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9DUK/XFlvfmLBzxfN8yRKZ/jIpfMDHtSqnq/h7ezXww=; b=Jp0njWItlUz23K50GN1vY+EVi8v190Nx45KpwlP4vTbcRlu2I98VOj++2xgRiSPpQjKsiy/848wNxcTbk5gKSMBO0AlVQNwY802AWhO7nGOkvPkrkblxjbqTAkfcqmLRWxJFWn7Qk3hK6ooPHP6CUC/AHaXRYZ7/CE8Z2UZ7cn8= Received: from BN3PR16MB0899.namprd16.prod.outlook.com (10.165.81.153) by BN3PR16MB0898.namprd16.prod.outlook.com (10.165.81.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Thu, 17 Nov 2016 00:45:12 +0000 Received: from BN3PR16MB0899.namprd16.prod.outlook.com ([10.165.81.153]) by BN3PR16MB0899.namprd16.prod.outlook.com ([10.165.81.153]) with mapi id 15.01.0721.015; Thu, 17 Nov 2016 00:45:11 +0000 From: Tarah Wheeler To: Eran Messeri Thread-Topic: [Trans] Call for adoption: draft-strad-trans-redaction-00 Thread-Index: AQHSFAtO9b8G7W896UCn2f4/+t5ECqCEQECAgALsJICAMrdUgIAEOEMXgB0a+QCAAPKKgA== Date: Thu, 17 Nov 2016 00:45:11 +0000 Message-ID: References: <5b357047-d412-70de-4aa6-9499fa8837b5@comodo.com> <5290c544-97b1-7530-eb0c-e9b62d8ebc71@comodo.com> <2775E6CC-A288-4681-A14F-19A775EDFF15@symantec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Tarah_Wheeler@symantec.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [155.64.38.28] x-microsoft-exchange-diagnostics: 1; BN3PR16MB0898; 7:humOQD8C4jfgg/HGXx+dqildSENqoVhbrTvbqYlK+wmwZGz2xdW5r+8fltKVPyZfv0kuxH3HxGlulSoGkoxBVGHwt7y6bCu5xpzPaDEoVqq+4LnTo+7yYR0pksgfTeBvXyWsTdA1Ni8QXfAHO7euArTcVc5f9o6jk0/rvTXy328W//qjI0omFeUm84Zqd5nxOSkzQDVgBJZSFfM+Mduz2B53874Tg6hG5DCaRqHn3A7VLC9Z/I33KMGwj3JOhDu3xmCZ9or58uSHfhZZX+UiTmIwFK07oLKsP+NS2lvyVu095KAj3xUt8ZEoDhBeEsxoQLy8QHkf//EcSCvQ+9DYtj8nT38jxlVUB8HBTPjwMbs= x-ms-office365-filtering-correlation-id: 5ba74004-54c5-46c7-cb41-08d40e82fd01 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR16MB0898; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040281)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6061324)(6041223)(6043046); SRVR:BN3PR16MB0898; BCL:0; PCL:0; RULEID:; SRVR:BN3PR16MB0898; x-forefront-prvs: 01294F875B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(149574003)(377454003)(199003)(83506001)(87936001)(7846002)(5660300001)(105586002)(102836003)(81166006)(6116002)(66066001)(229853002)(36756003)(6916009)(122556002)(3846002)(2950100002)(81156014)(93886004)(230783001)(3660700001)(92566002)(8936002)(6506003)(86362001)(606004)(6512003)(7736002)(77096005)(3280700002)(4326007)(189998001)(2900100001)(4001350100001)(8676002)(97736004)(10290500002)(68736007)(2906002)(80792005)(50986999)(99286002)(106356001)(76176999)(54356999)(110136003)(101416001)(106116001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR16MB0898; H:BN3PR16MB0899.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D452271D1DE4tarahwheelersymanteccom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2016 00:45:11.7221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR16MB0898 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHe3bvndfV4mlqHhTKVlLUnCaVfoiSiDIwyA+VTCOX3lKcL2xT VEhMCUswtZaWmmmuGaU1Nd8ykFb5mokapWGGTMsp03TC1Jq27U7wy8PvnP//POc5D4cmBD2U Bx2boGTkCVKZkMsjeaIsyqfcIgrz+9WJA03mZm7gkxtVVGCtfoAMIoIH1aUouKI+OVitXuac IyS8o9GMLDaFkfsei+TFDHWVUUnGoNSJyZdkJtIE5CJnGvAh+JLfgXIRjxbgBQTqrFdO64Kl t8mJFcwIBnO/OlwfEOj/tnLYYArBirGOawtIfJuAxTuPHLYiDuhN1Vw26EBwrybbqtA0F/vB /LDE1sQV74YfOa2EjQkcCuZmg51d8Clo+J1DsZ7ToFoxErZSV3wBpt/vtKVJ7A2FdUXIxnx8 BFSVZRTb6hkJ1Vq1XXC23tnxdIC0McLbwdxTw2F7ucP3icccdlAM6rf9BMtuYNCv2vu6YTEs jpUjtvYSdLfVI9Yjgr5vEw72Am3nXftXAK4goK9hissKZ0G/9BOt83JpLcVyHPzTvHNwCIzP TXMKkG/JhjexHA6Nt7pQiX24bdD9cIJk82IYvq/isnwANJUzBMs+8GBV5/AEw5vPL9BGTwWi nyMvZbJCEa9MTFZKkxg/f7EiLT7Kdkit+xUljkqMr0f2Dcvwb0EL2hAdwjQSbuG7GERhAkqa YnXqENCE0JV/Zcma4kdL09IZeeJlebKMUeiQJ00K3fnZi5vCBPiaVMnEMUwSI19XObSzRyba 08oXhY+GysfKLCPGP047VIVDnvkBN/e57SWLRWeMvqGNqaT6xPFO6lPX1KhmJAZrJ+d3BbSb zBFXr5/c2pYXAR9n1sIF6aZCf0mmSvd6ZvPw0lpb/1xdpCTPkFG9kjBLtx++2JQfVDDbe6us Za4ioc1CVelkw+cjR8a9izlCUhEjPbifkCuk/wHwbr3MXQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFKsWRmVeSWpSXmKPExsXCpdPEojvvr06EQd98FovP37ezWSxqXMxq sfbxRRYHZo9LS2YzeizYVOqxZMlPpgDmKC6blNSczLLUIn27BK6MyyfmsBa8dah48nQdSwPj MvMuRk4OCQETib+nt7F3MXJxCAl8Z5S41HWNEcI5wijx+PdOJgjnBaPEr7cb2UAcFoFOZokv fXOhyqYxSTz+vJwNwjnGKDF5TTNQhoODTcBA4uONKJAlIgLKEnfbdzKD2MwCgRLft78Es4UF 3CQ2P29nhahxl5jy6y0zSKuIQJjEq8PyIGEWAVWJiRunMYLYvAJmElMWzmGFWLWCRWL5hiVg CU6gmceWXmQBsRkFxCS+n1rDBLFLXOLWk/lMEI8KSCzZc54ZwhaVePn4H9heUQE9iS/35jFC 9MZKnNy9iRGiRkfi7PUnULaCxIbjk8BBISGwgFni7OYXbBAJX4nHP+4zwtg/Z69lhbCzJf4s Owhl+0g8fP8KqvkOo8STtfuhLpKR2PnyKuMERp1ZSI6FsKMltnacYJwF9rWgxMmZT1gg4noS N6ZOYYOwtSWWLXzNDGHrSsz4dwiqxkNi17nVjMhqFjByrGJUKCktLs4tyS1JTCzINDDSK67M TQYRicD0layXnJ+7iRGcwpwldzAe+uNziFGAg1GJh7egRCdCiDWxDKjyEKMEB7OSCG/SD6AQ b0piZVVqUX58UWlOavEhRmkOFiVx3g8b/ocLCaQnlqRmp6YWpBbBZJk4OKUaGHX57VVqHklW vM/cnnvK5utid2dB53+e0cFhVbMbmMQs19qWXo9yWsz5OviglP+FjV/3PA2fMVFsn/JqobYf Ov9LZXjE/s9hfbu9sqv2THt2afeF18+Lgt47Zu+yNy+5ttVqc46XYnVJSsA245eijk6fUppz yi0avh2x+ub8+7Gcu8jElWYySizFGYmGWsxFxYkAs2zf0F0DAAA= Archived-At: Cc: Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 00:45:21 -0000 --_000_D452271D1DE4tarahwheelersymanteccom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm glad to hear it, and looking forward to it. I'd like to ask about the two things that seem really necessary to me; some= times a technical RFC lacks within it the rationale for why we do things. I= 've been creating essentially a white paper at the same time as writing com= ments and some prescriptive thoughts on privacy. There's a fundamental disagreement here over why we would want privacy and = transparency on a variable slider, and ultimately, it comes down to the mot= ivations of the entities involved. Some of us want to sell a product that p= rovides privacy, and some of us want to sell a product that is only possibl= e with transparency. Let's not pretend that we're not all faced with differ= ing incentives. I've been on this list for a while, and very quiet because in general, it s= eems like a fool's game to try to argue people out of acting in their best = interests. It wasn't until now that I had a solid idea of what would be use= ful to this process. There are some very smart people in information security. There are those w= ith strong inclinations towards advocating privacy at multiple levels of or= ganizational size from a individual to a YUUUUUUGE company (sorry, couldn't= resist, and we all need to laugh a bit now and then). There are those who = see full transparency as a virtue and I can certainly understand why, both = on an ideological and a financial level. I've watched this situation be cautiously talked around for months now, and= I'd be interested to hear people's thoughts on asking some unassailably co= rporate-neutral experts on both sides of this debate to provide guidance. W= hose opinion are you interested in hearing on whether or not permitting cer= tificate privacy and accepting it as a browser standard is a good idea? I'm= putting myself and Symantec out there in a vulnerable way; I and we might = not always hear what we want to hear, but every one of us wants to make the= internet better in the way we believe will work best. Respectfully, Tarah Wheeler Principal Security Advocate Senior Director of Engineering, Website Security Symantec tarah@symantec.com From: Eran Messeri > Date: Tuesday, November 15, 2016 at 6:17 PM To: Tarah Wheeler > Cc: Rob Stradling >, "trans@ietf.org" > Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 AIUI --_000_D452271D1DE4tarahwheelersymanteccom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <06A411371827094D8B4BC23F5E773F8E@namprd16.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
I’m glad to hear it, and looking forward to it. 

I’d like to ask about the two things that seem really necessary = to me; sometimes a technical RFC lacks within it the rationale for why we d= o things. I’ve been creating essentially a white paper at the same ti= me as writing comments and some prescriptive thoughts on privacy.

There’s a fundamental disagreement here over why we would want p= rivacy and transparency on a variable slider, and ultimately, it comes down= to the motivations of the entities involved. Some of us want to sell a pro= duct that provides privacy, and some of us want to sell a product that is only possible with transparency. LetR= 17;s not pretend that we’re not all faced with differing incentives.<= /div>

I’ve been on this list for a while, and very quiet because in ge= neral, it seems like a fool’s game to try to argue people out of acti= ng in their best interests. It wasn’t until now that I had a solid id= ea of what would be useful to this process. 

There are some very smart = people in information security. There are those with strong inclinations to= wards advocating privacy at multiple levels of organizational size from a i= ndividual to a YUUUUUUGE company (sorry, couldn’t resist, and we all need to laugh a bit now and then). There= are those who see full transparency as a virtue and I can certainly unders= tand why, both on an ideological and a financial level.

I’ve watched this si= tuation be cautiously talked around for months now, and I’d be intere= sted to hear people’s thoughts on asking some unassailably corporate-= neutral experts on both sides of this debate to provide guidance. Whose opinion are you interested in hearing on whether or not pe= rmitting certificate privacy and accepting it as a browser standard is a go= od idea? I’m putting myself and Symantec out there in a vulnerable wa= y; I and we might not always hear what we want to hear, but every one of us wants to make the internet better in = the way we believe will work best.

Respectfully,

Tarah Wheeler
Principal Security Advocate
Senior Director of Engineerin= g, Website Security
Symantec

From: Eran Messeri <eranm@google.com>
Date: Tuesday, November 15, 2016 at= 6:17 PM
To: Tarah Wheeler <tarah_wheeler@symantec.com>
Cc: Rob Stradling <rob.stradling@comodo.com>, "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Call for adopt= ion: draft-strad-trans-redaction-00

AIUI --_000_D452271D1DE4tarahwheelersymanteccom_-- From nobody Thu Nov 17 00:44:44 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10921129731 for ; Thu, 17 Nov 2016 00:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxNeJsgU4-Ay for ; Thu, 17 Nov 2016 00:44:33 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C091D129661 for ; Thu, 17 Nov 2016 00:44:32 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id t79so129581865wmt.0 for ; Thu, 17 Nov 2016 00:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=IR+YzZrorEREKlQQ32/Qe+xISGDYeQGWiDxOjAwwS3k=; b=LXQccghxNuo3+g+q4SKk77wEzMzlEyKV8eV5ofpNW/3wk+WwHSItBB0Gb6l5vwjB+f EQuZB1c2H2IAHZVMsrHfs+TijNgMEhqB/GYzDv0cG5K/kvu6IEmzLlncjVwYVwh22YWs EeWXF+jsJLvre3hsVXDRsrn5MaxLVPR8082MXDnaXPG9Bd8Gr+1IP7WtdlQsNwYQnWX3 0ttHz76r8DeYuWQ19w6b3DZN6O2EAMtOaxknjT8Drkl/kyxfJApXEkQa4KBtZ4DY3Hbu 0d2clRYzgEc8g+Er662+DoWj6XR4viqtzHvCukLvQ9FWPKxMt/HHvUUHTCETvYCVvA7j fEJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IR+YzZrorEREKlQQ32/Qe+xISGDYeQGWiDxOjAwwS3k=; b=Z5zyRP9vEfrcyarw82gYo5Y05QGv2KgLHLV/SatsaLAPppsgnWZx6GV8BqRsdWTqgZ AC6rwGIExmT7x8l42jLI+KW/VaztQxQUfF9PvMkRXwByu0II9ztBOHg83xACFEVOxTh0 9GL+OqZyKcF75m00+ib5OHnffgzKwF4B1fEAlXIUckS2l0iIeY1IKz0G8upesgJfxiwr wK88ZX3eTfyvSvkN+ye31TkfgnQWEFf/65Orf5jrRR3Q89UOWQaSwEJdas+XmLoHEV88 4yBNNUoGjDZXm1ODmWvPAjsRGaGPkAj4Xgn9OXcTfOxNp2F+iqXFg2VD69OZ9O2tTR/x T7JQ== X-Gm-Message-State: ABUngveMRRYBduvNU3TomOwrPZgvsviIaYCnLit02WT4yOzzD8gYq3Cs9xId7FM1kJwrPr9KKRmc3k8gSMhSX79M X-Received: by 10.28.37.2 with SMTP id l2mr1198948wml.86.1479372270949; Thu, 17 Nov 2016 00:44:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.21 with HTTP; Thu, 17 Nov 2016 00:44:30 -0800 (PST) From: Eran Messeri Date: Thu, 17 Nov 2016 17:44:30 +0900 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a114afa2cb3bf2605417b32fe Archived-At: Subject: [Trans] Proposal: Moving optional methods from 6962-bis to monitoring API draft X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:44:36 -0000 --001a114afa2cb3bf2605417b32fe Content-Type: text/plain; charset=UTF-8 I'd like to see if there's any objection to moving two optional methods from 6962-bis to the monitoring API draft: * get-entry-for-sct * get-entry-for-tbscertificate These were added at a late stage by Ben, are not essential to the protocol and would be very suitable for a monitor. It is possible for logs to implement these methods under the same namespace of the log (so in effect it would behave exactly as if they were defined in 6962-bis): - Add an optional parameter for specifying the Log ID requests refers to was added. - Logs that implement these methods would not require the Log ID parameter and would simply reply with data from their tree. - Monitors that implement these methods would require the Log ID parameter and would reply with data from multiple logs (output is keyed by Log ID). The same thing can be applied to the proposed get-sths method which, as decided, would live in a monitoring API document, so the three methods form the base of the monitoring API draft. PR for removing the methods: https://github.com/google/certificate-transparency-rfcs/pull/204 PR adding the monitoring API draft: https://github.com/google/certificate-transparency-rfcs/pull/203 Regards, Eran --001a114afa2cb3bf2605417b32fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd like to see if there's any objection to moving= two optional methods from 6962-bis to the monitoring API draft:
These were added at a late stage by= Ben, are not essential to the protocol and would be very suitable for a mo= nitor.

It is possible for logs to implement these methods under=C2=A0the same namespace of the log (so in effect = it would behave exactly as if they were defined in 6962-bis):
<= div style=3D"font-size:12.8px">
  • Add an op= tional parameter for specifying the Log ID requests refers to was added.
  • Logs that implement these methods woul= d not require the Log ID parameter and would simply reply with data from th= eir tree.
  • Monitors that implement these = methods would require the Log ID parameter and would reply with data from m= ultiple logs (output is keyed by Log ID).
The same thing can be applied to the proposed get-sths method= which, as decided, would live in a monitoring API document, so the three m= ethods form the base of the monitoring API draft.

PR adding the monitoring API draft:= =C2=A0https://github.com/google/certificate-transparency-rfcs/pull/203

--001a114afa2cb3bf2605417b32fe-- From nobody Thu Nov 17 00:56:09 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DEB12960C for ; Thu, 17 Nov 2016 00:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqBUhrXLaWD8 for ; Thu, 17 Nov 2016 00:56:02 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AADC3129680 for ; Thu, 17 Nov 2016 00:56:00 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tKFMt60bxz3K8; Thu, 17 Nov 2016 09:55:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479372954; bh=/V/n/qRtl/YrzSOdoRIwyDSIOqbyzhx6X6mrDoTc9/Q=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cAQMzIMm8enEjiu6mRdPeZvIX1GAb9YvW43dkkl49Gt8olC4dKMDduFlS7/eUS0Gz u4umcDkt5/FRrSHgpZeyo1zr5LQkxqGD2VeNcwMoA8E+fVXQmjoY68wLL+m0iip3f/ bzbtxK29LPWCGLoaoFUTxAXXIOIpWKfQX/ZjlLUU= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BC-6oO6jUdsJ; Thu, 17 Nov 2016 09:55:53 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 17 Nov 2016 09:55:53 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 010BE35A2B2; Thu, 17 Nov 2016 03:55:52 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 010BE35A2B2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EE34840DAA4B; Thu, 17 Nov 2016 03:55:52 -0500 (EST) Date: Thu, 17 Nov 2016 03:55:52 -0500 (EST) From: Paul Wouters To: Eran Messeri In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Proposal: Moving optional methods from 6962-bis to monitoring API draft X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:56:08 -0000 On Thu, 17 Nov 2016, Eran Messeri wrote: > I'd like to see if there's any objection to moving two optional methods from 6962-bis to the monitoring API draft:* get-entry-for-sct > * get-entry-for-tbscertificate > > These were added at a late stage by Ben, are not essential to the protocol and would be very suitable for a monitor. > > It is possible for logs to implement these methods under the same namespace of the log (so in effect it would behave exactly as if they were defined in > 6962-bis): > * Add an optional parameter for specifying the Log ID requests refers to was added. > * Logs that implement these methods would not require the Log ID parameter and would simply reply with data from their tree. > * Monitors that implement these methods would require the Log ID parameter and would reply with data from multiple logs (output is keyed by Log ID). > The same thing can be applied to the proposed get-sths method which, as decided, would live in a monitoring API document, so the three methods form the > base of the monitoring API draft. > > PR for removing the methods: https://github.com/google/certificate-transparency-rfcs/pull/204 > PR adding the monitoring API draft: https://github.com/google/certificate-transparency-rfcs/pull/203 If anyone objects to this change, please let us know ASAP. Paul From nobody Thu Nov 17 04:21:46 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5C812973D for ; Thu, 17 Nov 2016 04:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyWo6TxJGCMM for ; Thu, 17 Nov 2016 04:21:42 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC7E129404 for ; Thu, 17 Nov 2016 04:21:42 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id f82so142396092wmf.1 for ; Thu, 17 Nov 2016 04:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MNpMi4tWcOcRYmEwJYg2WzrTCYiRn9RFOB/LKm2BRzc=; b=SuMihxn31dg54x6y4waw00vuesw943L18xnQJjpHs3gkT1D1OPgj7zPuRTF51VqF6Y YYU2Z5RLDa520oGge0wvUntTygrplTGcm5BhQGPC6tdx+V+m/Udj+vgZNY9lCvbMacRa xtOju1Db9YgvccU9Th31GEtl+QFYobwZQS4SYsPsBhALGyPL3IRNS0RJIajqV7onm4ew 8KoRmYyBAQb7x3EtCHRa7dlLiWAXk5S3kcar8Fc7cvpM72fbISdCigNFO6KMwJvL1PhK b/OZKv1Efli9DwNEw7kkY5HHG7iRQqPNQflCNnqxoJXzB9zuGPnOl7ElGIA19/aCVLq0 h2qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MNpMi4tWcOcRYmEwJYg2WzrTCYiRn9RFOB/LKm2BRzc=; b=i3Q8kI48v3CjMF6wUZA2K2clwYJl0bZaJeUqI/Y5EVqz8+ZPpE2OsgG/NZ9JCH4NxL IMvTT5A7LT2T3EqoYyiBYzh53Wo735FgmaavTZEiCsVgPcn9r9BWhdp6UsJcQf0vESq3 3QHiy+hpdW7z1EE+d23px04qwLP+FovjxA77li2OPi5+5xMIFSngC20/IXaB6a8e128u CVI3SyIhwG45IMWCVgc8Gwd85wQpUmzH4jorWotc0AdQV/fOx0s2vqAjZ4V4ML7teDu0 5AcYo5GFGKUzz+/t7i+FyaNS93u6g1bU9nwM7/rkAxKtoJISTMxpVwYc9dH5h8LkY6wT nPKQ== X-Gm-Message-State: ABUngvdrtP83s3Pgt0v3t8aFhfgsLAklo7+O7P1+zITphvORhf5QDA5EdeQaAny7MYV75Gb9HjVBxgW8ujqDlB2t X-Received: by 10.28.7.130 with SMTP id 124mr3665578wmh.18.1479385300718; Thu, 17 Nov 2016 04:21:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.21 with HTTP; Thu, 17 Nov 2016 04:21:39 -0800 (PST) In-Reply-To: References: <1c7240d7-f38d-2011-ad45-587843e0f1f8@gmail.com> From: Eran Messeri Date: Thu, 17 Nov 2016 21:21:39 +0900 Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=001a1144267a56340005417e3b96 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Relaxing section 5.1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 12:21:44 -0000 --001a1144267a56340005417e3b96 Content-Type: text/plain; charset=UTF-8 FYI this is the change to the draft: https://github.com/google/certificate-transparency-rfcs/commit/bf6603e10affbee97b07e33265494efbd07c833f In addition to the change from MUST to SHOULD, I've added an example as to why the a log may chose to reject valid submissions. Eran On Wed, Nov 16, 2016 at 8:26 PM, Ben Laurie wrote: > On 16 November 2016 at 02:00, Eran Messeri wrote: > > My proposed compromise at the trans workgroup meeting yesterday was to > > change the MUST in the following paragraph to a SHOULD: > > "Logs MUST accept certificates and precertificates that are fully valid > > according to RFC 5280 verification rules and are submitted with such a > > chain." > > > > I believe that this change allows creating logs that can reject valid > > submissions under some circumstances while complying with 6962-bis. And > we > > wouldn't have to go through WGLC again for such a change. > > This seems like a reasonable plan (mildly surprised such a change can > be made without WGLC, tho!). > > > > > On Sat, Nov 5, 2016 at 12:42 AM, Ben Laurie wrote: > >> > >> On 4 November 2016 at 14:07, Peter Bowen wrote: > >> > On Fri, Nov 4, 2016 at 6:33 AM, Ben Laurie wrote: > >> >> > >> >> The bit you didn't quote does say they the log has to accept valid > >> >> certs, tho: "Logs MUST accept certificates and precertificates that > >> >> are fully valid according to RFC 5280 [RFC5280] verification rules > and > >> >> are submitted with such a chain." > >> > > >> > Sorry about that. So the three MUSTs together are: > >> > > >> > - Logs MUST verify that each submitted certificate or precertificate > >> > has a valid signature chain to an accepted trust anchor, using the > >> > chain of intermediate CA certificates provided by the submitter. > >> > > >> > - Logs MUST reject submissions without a valid signature chain to an > >> > accepted trust anchor. > >> > > >> > - Logs MUST accept certificates and precertificates that are fully > >> > valid according to RFC 5280 verification rules and are submitted with > >> > such a chain. > >> > > >> > When I read these together, I read that Logs must accept _any_ > >> > certificate that is fully valid according to RFC 5280 verification > >> > rules and chains to any root the log trusts and logs must _only_ log > >> > such certificates (and no others). > >> > > >> > If this is accurate, we need to account for all types of certificates > >> > being logged, as a log cannot choose to reject certificates for usages > >> > other than server authentication and the log cannot reject > >> > certificates that have personal information (e.g. an server > >> > authentication certificate that states which human requested the > >> > certificate in the subject). > >> > > >> > This seems like a very strong assertion of policy rather than a > >> > technical discussion of how the CT protocol works. I would again ask > >> > the WG to reconsider the requirement levels specified in this section. > >> > >> FWIW, I tend to agree. I would also note that operationally, we have > >> already discussed options for logs that are incompatible with these > >> requirements, for example: > >> > >> * sharded logs (e.g. by hash(cert) mod n). > >> > >> * logs that only accept short or long lifetime certificates (this > >> would allow the working set to be reduced in size for CAs that issue a > >> lot of short-lived certs). > >> > >> _______________________________________________ > >> Trans mailing list > >> Trans@ietf.org > >> https://www.ietf.org/mailman/listinfo/trans > > > > > --001a1144267a56340005417e3b96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI this is the change to the draft:

=
In addition to the change from MUST to SHOULD, I've added an= example as to why the a log may chose to reject valid submissions.

Eran

On Wed, Nov 16, 2016 at 8:26 PM, Ben Laurie <benl@google.co= m> wrote:
= On 16 November 2016 at 02:00, Eran Messeri <eranm@google.com> wrote:
> My proposed compromise at the trans workgroup meeting yesterday was to=
> change the MUST in the following paragraph to a SHOULD:
> "Logs MUST accept certificates and precertificates that are fully= valid
> according to RFC 5280 verification rules and are submitted with such a=
> chain."
>
> I believe that this change allows creating logs that can reject valid<= br> > submissions under some circumstances while complying with 6962-bis. An= d we
> wouldn't have to go through WGLC again for such a change.

This seems like a reasonable plan (mildly surprised such a change ca= n
be made without WGLC, tho!).

>
> On Sat, Nov 5, 2016 at 12:42 AM, Ben Laurie <benl@google.com> wrote:
>>
>> On 4 November 2016 at 14:07, Peter Bowen <pzbowen@gmail.com> wrote:
>> > On Fri, Nov 4, 2016 at 6:33 AM, Ben Laurie <benl@google.com> wrote:
>> >>
>> >> The bit you didn't quote does say they the log has to= accept valid
>> >> certs, tho: "Logs MUST accept certificates and prece= rtificates that
>> >> are fully valid according to RFC 5280 [RFC5280] verificat= ion rules and
>> >> are submitted with such a chain."
>> >
>> > Sorry about that.=C2=A0 So the three MUSTs together are:
>> >
>> > - Logs MUST verify that each submitted certificate or precert= ificate
>> > has a valid signature chain to an accepted trust anchor, usin= g the
>> > chain of intermediate CA certificates provided by the submitt= er.
>> >
>> > - Logs MUST reject submissions without a valid signature chai= n to an
>> > accepted trust anchor.
>> >
>> > - Logs MUST accept certificates and precertificates that are = fully
>> > valid according to RFC 5280 verification rules and are submit= ted with
>> > such a chain.
>> >
>> > When I read these together, I read that Logs must accept _any= _
>> > certificate that is fully valid according to RFC 5280 verific= ation
>> > rules and chains to any root the log trusts and logs must _on= ly_ log
>> > such certificates (and no others).
>> >
>> > If this is accurate, we need to account for all types of cert= ificates
>> > being logged, as a log cannot choose to reject certificates f= or usages
>> > other than server authentication and the log cannot reject >> > certificates that have personal information (e.g. an server >> > authentication certificate that states which human requested = the
>> > certificate in the subject).
>> >
>> > This seems like a very strong assertion of policy rather than= a
>> > technical discussion of how the CT protocol works.=C2=A0 I wo= uld again ask
>> > the WG to reconsider the requirement levels specified in this= section.
>>
>> FWIW, I tend to agree. I would also note that operationally, we ha= ve
>> already discussed options for logs that are incompatible with thes= e
>> requirements, for example:
>>
>> * sharded logs (e.g. by hash(cert) mod n).
>>
>> * logs that only accept short or long lifetime certificates (this<= br> >> would allow the working set to be reduced in size for CAs that iss= ue a
>> lot of short-lived certs).
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans=
>
>

--001a1144267a56340005417e3b96-- From nobody Thu Nov 17 14:25:18 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBD11294F2 for ; Thu, 17 Nov 2016 14:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSK8idA4xZ0Y for ; Thu, 17 Nov 2016 14:25:15 -0800 (PST) Received: from mail.hezmatt.org (erdhenne.tobermorytech.com [178.63.85.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5C77212947E for ; Thu, 17 Nov 2016 14:25:15 -0800 (PST) Received: from mistress.home.hezmatt.org (2001-44b8-510e-8600-6043-6d0c-46f3-1ba2.static.ipv6.internode.on.net [IPv6:2001:44b8:510e:8600:6043:6d0c:46f3:1ba2]) by mail.hezmatt.org (Postfix) with ESMTPSA id 9ED04A466E for ; Thu, 17 Nov 2016 22:25:12 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id A9A519FC3D; Fri, 18 Nov 2016 09:25:06 +1100 (AEDT) Date: Fri, 18 Nov 2016 09:25:06 +1100 From: Matt Palmer To: trans@ietf.org Message-ID: <20161117222506.GM6253@hezmatt.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Proposal: Moving optional methods from 6962-bis to monitoring API draft X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 22:25:17 -0000 On Thu, Nov 17, 2016 at 03:55:52AM -0500, Paul Wouters wrote: > If anyone objects to this change, please let us know ASAP. I object to the introduction from the existing monitor API draft RFC (https://github.com/tobermorytech/ct-monitor-api-rfc/blob/master/draft-palmer-ct-monitor-api.md) being lifted, wholesale, without credit. - Matt From nobody Thu Nov 17 16:46:27 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDA91295CC for ; Thu, 17 Nov 2016 16:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKccunuGMn-G for ; Thu, 17 Nov 2016 16:46:23 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781D0128E18 for ; Thu, 17 Nov 2016 16:46:23 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id f82so6205175wmf.1 for ; Thu, 17 Nov 2016 16:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7klmRPlVWJS312GJIJv44a9beQkRQB1xWuJ6PlL58NA=; b=Jk7xDB+mKmCCq4pIeIRI4go1zS4GSFhKhQgSkuhKol12DKKJY6O7lCVBkZEIsSEN8V pOfZexPd+qlPuJI+5j8Ti/iI/WGeeqCsRIhxcB9OhBYDbo+H4pmL/Z/QCp9s52m6rOhI Vy7nFX5xTq5EnXFZiiPwazxk6KgmNDC3rNiEoUK7G/IX8L0JLq5pK4asUrbX6LlwPOGz mIxnlHgi5Nzl11TfEQEs8iD/jbQ3SXLb6HZ0lm+JEsp6BP0H5LBzD16oWBsX4iYa3cyO xNVoi2Qpw6jRmGyJTYsNqFN1fB0+bqnJjfUHzm80uYsIdxIzfSGcBfObhp91pJwkFej3 5vpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7klmRPlVWJS312GJIJv44a9beQkRQB1xWuJ6PlL58NA=; b=Znw2ZDXVjz6yst0Rdy3o7s3ryvLOprIOUzPWMd4bSeDlV1Gzfc6A4/3usqqS0EP4kJ zIzUqhaWE9JRkh4q4tJRPBIw+mRQrySOY4NpPPltjF40ieluPHKlyo0uxGwv+rbu5YVi 7NditAmTa3bn7YX4UI2gbYvuX+mLrCe2KfV0KwPrVRgRDc3j/0ekxm+HHxNNUJAb/foy 8oxEZReLbMl1f6YC2XiTI2Rj68lC8RreYXuzBKLKBwf1mCzreS+kUtHwtdXUUL/yg7GO 3gN3pj48DMkRhV8BqwIcGXHCPaBks+yFYa1CMX1VlaIO2nL28rXwF8xBLR1SaATU0E/h +PpA== X-Gm-Message-State: ABUngveTyV8I8v9hdMvxVJHsYiC9CCaCj/f14ddYcJVFSuFqzroAqZvcVsj9b+NVCT3YkFc6Shgoa7wQkxDih28o X-Received: by 10.28.96.4 with SMTP id u4mr20922131wmb.86.1479429981975; Thu, 17 Nov 2016 16:46:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.21 with HTTP; Thu, 17 Nov 2016 16:46:21 -0800 (PST) In-Reply-To: <20161117222506.GM6253@hezmatt.org> References: <20161117222506.GM6253@hezmatt.org> From: Eran Messeri Date: Fri, 18 Nov 2016 09:46:21 +0900 Message-ID: To: Matt Palmer Content-Type: multipart/alternative; boundary=001a1148e9988c0699054188a2a3 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Proposal: Moving optional methods from 6962-bis to monitoring API draft X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 00:46:25 -0000 --001a1148e9988c0699054188a2a3 Content-Type: text/plain; charset=UTF-8 Sincere apologies - this text (and some other leftovers) weren't intended to be in this pull request. I've removed it - hopefully it could be re-introduced later with proper credits and permission, once these are sorted. Eran On Fri, Nov 18, 2016 at 7:25 AM, Matt Palmer wrote: > On Thu, Nov 17, 2016 at 03:55:52AM -0500, Paul Wouters wrote: > > If anyone objects to this change, please let us know ASAP. > > I object to the introduction from the existing monitor API draft RFC > (https://github.com/tobermorytech/ct-monitor-api- > rfc/blob/master/draft-palmer-ct-monitor-api.md) > being lifted, wholesale, without credit. > > - Matt > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a1148e9988c0699054188a2a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sincere apologies - this text (and some other leftovers) w= eren't intended to be in this pull request.
I've removed it - h= opefully it could be re-introduced later with proper credits and permission= , once these are sorted.

Eran

On Fri, Nov 18, 2016 at 7:= 25 AM, Matt Palmer <mpalmer@hezmatt.org> wrote:
On Thu, Nov 17, 2016 at 03:55:52AM= -0500, Paul Wouters wrote:
> If anyone objects to this change, please let us know ASAP.

I object to the introduction from the existing monitor API draft RFC=
(https= ://github.com/tobermorytech/ct-monitor-api-rfc/blob/master/draft-= palmer-ct-monitor-api.md)
being lifted, wholesale, without credit.

- Matt

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

--001a1148e9988c0699054188a2a3-- From nobody Fri Nov 18 07:53:51 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F411294AF for ; Fri, 18 Nov 2016 07:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J46FarWfFOg8 for ; Fri, 18 Nov 2016 07:53:48 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36E61295CA for ; Fri, 18 Nov 2016 07:53:47 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id y23so38239401itc.0 for ; Fri, 18 Nov 2016 07:53:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XF2YHJzDkp0OKtTO19iM5bPPDhCRwi7UrCs7ryyAwkM=; b=fDVZT2fpifdi0DCrzjki5Ig3/e1ghCmZ6Ldo86VDSK25OJylOl5SsHk9DAEel/lAMJ MkONbBY3XVY41QmlfAkiX9Q9szWd9Pe38Wvjq6vlfj1YEc4bxTgO6i33rTsxkwg63uof Dm82+YlmSqwUZ0JgGvfEcSjFubK0iHtvza2iKqC2eVPJfdmV8zWbpvjkINHrn+Pg57lw dA28jbq/3jMpMna9FJ83GYyTFGppGasEoh/EPRChOPZR7YPADLN8yucYne/QCBPAIS36 l9u9Pma/uxzb+LOEGynYkBYkmT6cKVmJYK+Pzc6i2tgqdBvq29WzsVAlStK9gn4Ny4Dv 7eTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XF2YHJzDkp0OKtTO19iM5bPPDhCRwi7UrCs7ryyAwkM=; b=I8sxzxeC/TjgcntpDd/o8VDO1b+ZCrq6olPVe54i39HOpp7ghChWJw1eEmVK7q+fNn UN4cCQwQD401FMPI8+ViqNm8zOyYZbr82nHlPdNi2UgDUIcsOtLwx9ihlVw4iufc8UYZ UINoKnipwPsVq5yXTsozMjwxccD0dtpnrALQXwjZj5DbZrfoqu0gmg8jd3Jm1a3CIpoL dcCVU20jLxgqDibFtvOlp+oOHsFrP7O/RHiSpV/vDAhsPFEAIHMNEXN3xJoZAZCifG8/ q+fON0DZAxdZR/WyuwhT6RhNQr+1B67EwbejkXmyKMUxAhm5PH0TGHoSzRY+sZNm6qTY PbAA== X-Gm-Message-State: AKaTC00POD2QtRRMEfgkUhFVsRfQK6/akZu1f7wHijxAtiJIn00jxbT2JDQTsDZ90Dvg/h8OfJMkFRn/kgOmRg== X-Received: by 10.107.141.211 with SMTP id p202mr338047iod.47.1479484427281; Fri, 18 Nov 2016 07:53:47 -0800 (PST) MIME-Version: 1.0 References: <5b357047-d412-70de-4aa6-9499fa8837b5@comodo.com> <5290c544-97b1-7530-eb0c-e9b62d8ebc71@comodo.com> <2775E6CC-A288-4681-A14F-19A775EDFF15@symantec.com> In-Reply-To: From: Clint Wilson Date: Fri, 18 Nov 2016 15:53:35 +0000 Message-ID: To: Tarah Wheeler , Eran Messeri Content-Type: multipart/alternative; boundary=94eb2c062c9ebd29ed0541954f9b Archived-At: Cc: Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 15:53:50 -0000 --94eb2c062c9ebd29ed0541954f9b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I=E2=80=99d like to propose that the redaction I-D allow for redacting labe= ls above the 2nd level domain, as determined by the public suffix used, of SAN:dNSName values. For example, redaction of =E2=80=9Csecret.example.com= =E2=80=9D would result in =E2=80=9C{redacted}.example.com=E2=80=9D while =E2=80=9Csecret.ex= ample.co.uk=E2=80=9D would result in =E2=80=9C{redacted}.example.co.uk=E2=80=9D. The I-D should also a= llow for redaction of some subject DN values, especially commonName (the unfortunate reality is this field is still used=E2=80=A6 frequently). To (hopefully) address some of the concerns redaction has encountered in the past, we=E2=80=99d like to propose the addition of a =E2=80=9Credaction= signal=E2=80=9D. This is essentially the domain owner publicly signaling that they have opted-in to redaction of their certificates. While this does not solve the issue of a client being unable to authoritatively determine that the host name being observed during certificate verification is the one intended in the redacted precertificate, it does introduce a mechanism for the entity that CT is intended to protect to assert their acceptance of this tradeoff. We haven=E2=80=99t identified the precise mechanism via which this redactio= n signal would be communicated, but two options we want to throw out are CAA records and HTTP header (such as the proposed Expect-CT header). We also have not identified who/what should verify the redaction signal and when. A CA should check for the presence of the redaction signal before submitting a redacted precert, but if that were the only entity checking, we would need to determine a way to publicly audit this check. A Log Operator might check for the presence of a redaction signal before accepting a redacted precert, but this introduces a new requirement for logs to make some form of connection to the domain(s) in the precert. A relying party might check for the presence of the redaction signal when verifying the SCTs, but the lack of a redaction signal at the time of connection does not necessarily represent the state of redaction signal at the time of precert submission. A log monitor might check for a redaction signal when a precert is discovered for a domain of interest, in order to help determine whether a discovered precert might represent misissuance. Cheers! On Wed, Nov 16, 2016 at 5:45 PM Tarah Wheeler wrote: I=E2=80=99m glad to hear it, and looking forward to it. I=E2=80=99d like to ask about the two things that seem really necessary to = me; sometimes a technical RFC lacks within it the rationale for why we do things. I=E2=80=99ve been creating essentially a white paper at the same ti= me as writing comments and some prescriptive thoughts on privacy. There=E2=80=99s a fundamental disagreement here over why we would want priv= acy and transparency on a variable slider, and ultimately, it comes down to the motivations of the entities involved. Some of us want to sell a product that provides privacy, and some of us want to sell a product that is only possible with transparency. Let=E2=80=99s not pretend that we=E2=80=99re no= t all faced with differing incentives. I=E2=80=99ve been on this list for a while, and very quiet because in gener= al, it seems like a fool=E2=80=99s game to try to argue people out of acting in th= eir best interests. It wasn=E2=80=99t until now that I had a solid idea of what woul= d be useful to this process. There are some very smart people in information security. There are those with strong inclinations towards advocating privacy at multiple levels of organizational size from a individual to a YUUUUUUGE company (sorry, couldn=E2=80=99t resist, and we all need to laugh a bit now and then). Ther= e are those who see full transparency as a virtue and I can certainly understand why, both on an ideological and a financial level. I=E2=80=99ve watched this situation be cautiously talked around for months = now, and I=E2=80=99d be interested to hear people=E2=80=99s thoughts on asking some = unassailably corporate-neutral experts on both sides of this debate to provide guidance. Whose opinion are you interested in hearing on whether or not permitting certificate privacy and accepting it as a browser standard is a good idea? I=E2=80=99m putting myself and Symantec out there in a vulnerable way; I an= d we might not always hear what we want to hear, but every one of us wants to make the internet better in the way we believe will work best. Respectfully, Tarah Wheeler Principal Security Advocate Senior Director of Engineering, Website Security Symantec tarah@symantec.com From: Eran Messeri Date: Tuesday, November 15, 2016 at 6:17 PM To: Tarah Wheeler Cc: Rob Stradling , "trans@ietf.org" < trans@ietf.org> Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 AIUI _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans --94eb2c062c9ebd29ed0541954f9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi all,=C2=A0

I=E2=80=99d li= ke to propose that the redaction I-D allow for redacting labels above the 2nd level domain, as determined by the public su= ffix used, of SAN:dNSName values. For example, redaction of =E2=80=9Csecret.exa= mple.com=E2=80=9D would result in =E2=80=9C{redacted}.example.com=E2=80=9D while =E2=80=9Cse= cret.example.co.uk=E2=80=9D would result in =E2=80=9C{redacted}.example.co.uk=E2=80=9D. The I-D should also allow fo= r redaction of some subject DN values, especially commonName (the unfortunate reality is this f= ield is still used=E2=80=A6 frequently).=C2=A0

To (ho= pefully) address some of the concerns redaction has encountered in the past, we=E2=80=99d like to propose the addition of a =E2= =80=9Credaction signal=E2=80=9D. This is essentially the domain owner publicly signaling th= at they have opted-in to redaction of their certificates. While this does not solve the issue of a client being unable to authoritatively determine that the host n= ame being observed during certificate verification is the one intended in the redacted precertificate, it does introduce a mechanism for the entity that = CT is intended to protect to assert their acceptance of this tradeoff.=C2=A0

We hav= en=E2=80=99t identified the precise mechanism via which this redaction signal would be communicated, but two options we want to thr= ow out are CAA records and HTTP header (such as the proposed Expect-CT header)= .=C2=A0

We als= o have not identified who/what should verify the redaction signal and when. A CA should check for the presence of the redact= ion signal before submitting a redacted precert, but if that were the only enti= ty checking, we would need to determine a way to publicly audit this check. A = Log Operator might check for the presence of a redaction signal before acceptin= g a redacted precert, but this introduces a new requirement for logs to make so= me form of connection to the domain(s) in the precert. A relying party might c= heck for the presence of the redaction signal when verifying the SCTs, but the l= ack of a redaction signal at the time of connection does not necessarily repres= ent the state of redaction signal at the time of precert submission. A log moni= tor might check for a redaction signal when a precert is discovered for a domai= n of interest, in order to help determine whether a discovered precert might represent misissuance.

Cheers!

On Wed, Nov= 16, 2016 at 5:45 PM Tarah Wheeler <Tarah_Wheeler@symantec.com<= /a>> wrote:
I=E2=80=99m glad to hear it, and looking forward t= o it.=C2=A0

I=E2=80=99d like to ask about the two things that = seem really necessary to me; sometimes a technical RFC lacks within it the = rationale for why we do things. I=E2=80=99ve been creating essentially a wh= ite paper at the same time as writing comments and some prescriptive thoughts on privacy.

There=E2=80=99s a fundamental disagreement here ov= er why we would want privacy and transparency on a variable slider, and ult= imately, it comes down to the motivations of the entities involved. Some of= us want to sell a product that provides privacy, and some of us want to sell a product that is only possible with transparency. Let=E2= =80=99s not pretend that we=E2=80=99re not all faced with differing incenti= ves.

I=E2=80=99ve been on this list for a while, and ve= ry quiet because in general, it seems like a fool=E2=80=99s game to try to = argue people out of acting in their best interests. It wasn=E2=80=99t until= now that I had a solid idea of what would be useful to this process.=C2=A0=

There are= some very smart people in information security. There are those with stron= g inclinations towards advocating privacy at multiple levels of organizatio= nal size from a individual to a YUUUUUUGE company (sorry, couldn=E2=80=99t resist, and we all need to laugh a bit now and then). The= re are those who see full transparency as a virtue and I can certainly unde= rstand why, both on an ideological and a financial level.

I=E2=80= =99ve watched this situation be cautiously talked around for months now, an= d I=E2=80=99d be interested to hear people=E2=80=99s thoughts on asking som= e unassailably corporate-neutral experts on both sides of this debate to pr= ovide guidance. Whose opinion are you interested in hearing on whether or not pe= rmitting certificate privacy and accepting it as a browser standard is a go= od idea? I=E2=80=99m putting myself and Symantec out there in a vulnerable = way; I and we might not always hear what we want to hear, but every one of us wants to make the internet better in = the way we believe will work best.

Respectfully,

Tarah Wheel= er
Principal S= ecurity Advocate
Senior Dire= ctor of Engineering, Website Security
Symantec
tarah@syma= ntec.com

From: Eran Mess= eri <eranm@google.com>
Date: Tuesday, = November 15, 2016 at 6:17 PM
To: Tarah Wheel= er <tarah_wheeler@symantec.com>
Cc: Rob Stradli= ng <rob.stradling@comodo.com>, "trans@ietf.org"= <trans@ietf.org>
Subject: Re: [T= rans] Call for adoption: draft-strad-trans-redaction-00

AIUI
_______________________________________________
Trans mailing list
Tra= ns@ietf.org
https://www.ietf.org/mailman/listinfo= /trans
--94eb2c062c9ebd29ed0541954f9b-- From nobody Fri Nov 18 22:39:44 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D90A129446 for ; Fri, 18 Nov 2016 22:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AXB_X_FF_SEZ_S=2.248, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4LUe5U-eEMc for ; Fri, 18 Nov 2016 22:39:40 -0800 (PST) Received: from asbsmtoutape01.symantec.com (asbsmtoutape01.symantec.com [155.64.138.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88461293FB for ; Fri, 18 Nov 2016 22:39:39 -0800 (PST) Received: from asbsmtmtaapi01.symc.symantec.com (asb1-f5-symc-ext-prd-snat6.net.symantec.com [10.90.75.6]) by asbsmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id A0.69.11706.AA3FF285; Sat, 19 Nov 2016 06:39:38 +0000 (GMT) X-AuditID: 0a5af819-3cabb9a000002dba-12-582ff3aaf995 Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat8.net.symantec.com [10.90.75.8]) by asbsmtmtaapi01.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 58.B9.23679.9A3FF285; Sat, 19 Nov 2016 06:39:38 +0000 (GMT) Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 18 Nov 2016 22:39:36 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.128.6) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Fri, 18 Nov 2016 22:39:35 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rzKosSSMvm71Bww4/7uhCEH4KzqSe9bVBxbJ1X0pTxE=; b=Yo5EERMvbIA9gdh+JN9CaltPH9s2zSZhaLHO/NqljYi3Mxv9L+7SQ31t936oRzaeWYtiOciSLum3ZU9RqUMxCrHExSpsVTwIi6bC6qieG3E/CXKDrknzFKyreOk/ZWlgv6Ut0aPZM7VQZghnVntwJV6XZaZbXMV1ZwNGJkTVrq4= Received: from BN3PR16MB0899.namprd16.prod.outlook.com (10.165.81.153) by BN3PR16MB0898.namprd16.prod.outlook.com (10.165.81.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Sat, 19 Nov 2016 06:39:30 +0000 Received: from BN3PR16MB0899.namprd16.prod.outlook.com ([10.165.81.153]) by BN3PR16MB0899.namprd16.prod.outlook.com ([10.165.81.153]) with mapi id 15.01.0721.017; Sat, 19 Nov 2016 06:39:30 +0000 From: Tarah Wheeler To: Clint Wilson , Eran Messeri Thread-Topic: [Trans] Call for adoption: draft-strad-trans-redaction-00 Thread-Index: AQHSFAtO9b8G7W896UCn2f4/+t5ECqCEQECAgALsJICAMrdUgIAEOEMXgB0a+QCAAPKKgIADFkKAgABxawA= Date: Sat, 19 Nov 2016 06:39:30 +0000 Message-ID: References: <5b357047-d412-70de-4aa6-9499fa8837b5@comodo.com> <5290c544-97b1-7530-eb0c-e9b62d8ebc71@comodo.com> <2775E6CC-A288-4681-A14F-19A775EDFF15@symantec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Tarah_Wheeler@symantec.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [155.64.38.25] x-microsoft-exchange-diagnostics: 1; BN3PR16MB0898; 7:H6QrWtLv83jPZCw0ruPpb+O+FVyuUgfl1gl2Cl7nXvYWq2+pIlEP4wLEE9maXV1MY2IcAtdXgOYG+I5Hzv2jaJYO+lu65mbEAhodq0vfZ8s8e30yp0UkteexXwUXf1APO0HYjSa8uN57K0X+MN1OGIgQDNVy1fivsp8/6/z1dwABCEiEH0xjutc0/Wx1C3ix9fnU9j6MyclR4LrAvFVz2Ksa8eukIyXrd78tbUMNkpzTQLED7XbVzzMKnokliPhuL+F/aI4RDV4ER2sEEFUH9Lb8A69Rtg7Oho9L+oRSv/UUStpXKLS6uA27KSeNzNuiIoy7+MO71rruH7B0a3qqCo3Otzwjd3FQYBysWBB2kRM= x-ms-office365-filtering-correlation-id: a26eda1a-8507-4df8-66a0-08d41046d105 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR16MB0898; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040307)(6060326)(6045199)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(6061324)(2016111802025)(6043046); SRVR:BN3PR16MB0898; BCL:0; PCL:0; RULEID:; SRVR:BN3PR16MB0898; x-forefront-prvs: 0131D22242 x-forefront-antispam-report: SFV:SPM; SFS:(10009020)(7916002)(24454002)(53754006)(76104003)(377454003)(199003)(149574003)(189002)(93886004)(2906002)(92566002)(101416001)(229853002)(230783001)(606004)(77096005)(6506003)(81166006)(66066001)(4001350100001)(4326007)(54356999)(7736002)(5660300001)(76176999)(81156014)(36756003)(97736004)(5001770100001)(6512003)(50986999)(80792005)(2900100001)(7846002)(7906003)(189998001)(3660700001)(2950100002)(3280700002)(8676002)(106356001)(106116001)(8936002)(99286002)(105586002)(122556002)(10290500002)(83506001)(86362001)(6116002)(38730400001)(16601075003)(68736007)(87936001)(3846002)(102836003)(19611415001); DIR:OUT; SFP:1501; SCL:5; SRVR:BN3PR16MB0898; H:BN3PR16MB0899.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:22 Content-Type: multipart/alternative; boundary="_000_D455336B1FD1tarahwheelersymanteccom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2016 06:39:30.2986 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR16MB0898 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSbUhTURjHO9vddl0tTnPmk32Rodmbc4KkgUifapJSEciaRV31kqJua5ui fbAJSaVUQlI4R05bCyS1JuJLZWgqTjLNDEWwnFq+lfOtnMusbXdCfTn8zvP/n+d/nsMh2cKP nCAyQ6mjNUoqS8zlE3zFSW54zUqEXNpqCIgxDd3jxqysNXFjqgsfcWJqJ98TxwjZoLkCyVoM YzyZyZojM5vXWacJBT82jc7KyKU1EXGX+OltG0NI/bkc5fWUGJEe1RWhYuRHAo6C+tUBohjx SSFeQlDt/M7eEvqvO3zCTwSW8j4Ws+lEMDBWxPK4hHgGwbcBf49A4FtsKBo3cRnhPgvmXfHM iW4Ev5eM7l4kycVSWBpReDwinABvnfOEh9n4DKw1zXqj/fFxaJi+wWE8J6DMxVxJhFPAPlPK 8zCBQ+H2cLG3LsBHwLW4ymOyjBxwLfzwCn7uprM9Rm8AwrthrfcpiwkLhNGpShYzJwbzy37f zAEwO7npDQ7AElj99BAxZy+A7YXV92CHoW94ysfB8KqlwfssgE1s0Nv+EIyQCL8sVt4Wr1fU chjOhLplhy8sAeyOOVYpkhj+uRPDyeB4MsEzeIfbBbbyKYKpS8HxrpLN8CGwVM37OAKer/Yh hmVgv/nmP48JkTUomNKmaLN1qhwdpaalkRJtfnaqZ6HcXy1VkqrKtiLvZ3PuaUadPQkdCJNI vENgGIuQCzlUrtvZgYBki0WC5gV3SZBG5V+lNaqLmpwsWtuB9pKEOFCQe0oiF+LLlI7OpGk1 rdlSWaRfkB4ZTb2t41farSmj1hlR+5eG6ETc/czSERW3b7xR31810dW4nPFYfa6W3zUC8Ul3 70Qu2i2tYW3+fh86N2JDcJx5e1EZZW8/W38tL+qr0jmnUutfr1ElD7YdDVvZDE9LKqAL91sL RuSKrFBnWX10cvT0YPDObSmSvPMUxxaiPCAmtOlU5EG2Rkv9BbnaQ9ZoAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0iTURjHOXvfbe9mq9O8PWliLKRQ05klCySEoBZZpASJJfWqb7W8spll H8yikS0Eo4jUoauGpqXh+pBhlmiYRl4aVmZZLQd5KZe3ptO0bWdBfTn8zvP/P8//nMNhKOkb fgCjys7j1NlspkwgpsXJe5hNddORSfK307TC0H9NoJi2PxIobp+/w1fUD7+m42il2ViBlI/L h4RKg+mU0mic5+2nk8Wx6VymKp9TR24/Kj7xdLEf5X4uQ2c6r+hREWrQIh0SMYC3QO9FG61D YkaKfyGoLuvmkc1zBH1DWp7LJcUjCL73ebsEGl+mQPvFICDCDR6MO3aTjg4Evyf1zlkMI8By mBxIdnl8cDy8mhunXUzhBLA/GqVc7I13wsNvl/jEswuuO35QhFPBMlIqdDGNQ6Dknc5dl+AY cPycEZIsPR8cE7NuQeQcOtqpdwcg7Af2l/d5JMwfBq1VPHJPDMYnvRRhXxgdXnIH++IImPlU iUhvCnQ1mzzvEg7d76weXgctjx+6nwWwgYKirmWaCHthodok/MvzFfV8whnQMGXzhMWDxTbm aZ5BMHjzgYAIa6Hyag9VisLK/zks4UNgq/kqLHffejV0lVlpUpeDraeKIhwG1bfGPRwJjTPd iLASLMXt/3kMiKlD61hNqiYrLyuPZXNV8qgITUFWmmthnV8tLSItJ8uE3J9twa8JtS7GtyHM INkKCTMSmSTls/lOZxsChpL5SJomnCVJOltwllPnHFGfyuQ0bSiQoWX+Eu/G5YNSfJzN4zI4 LpdT/1V5jCigCDW9DUks8tItR4empH+Mwa23UGHp7AMuaKWjQhtksioGWmm7viViq2/uadQo FxnWfzhmrtq35kDzUup47b3JVQkJZgsbvmNMZQmuLRnuTnvhO7XhcEdOe9jrzYmxxTkb7wa/ 31JXKNJK57adjIv2Dr1QzFFM2LkArz3PalINgWYZrTnBRoVSag37B9o3smpoAwAA Archived-At: Cc: Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 06:39:42 -0000 --_000_D455336B1FD1tarahwheelersymanteccom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Some of the methods of implementing these suggestions seem complex, but the= re=92s a lot of good ideas here. Clint, what do you think of my suggestion = on asking some outside SMEs to chime in? Respectfully, Tarah Wheeler Principal Security Advocate Senior Director of Engineering, Website Security Symantec tarah@symantec.com From: Clint Wilson > Date: Friday, November 18, 2016 at 7:53 AM To: Tarah Wheeler >, Eran Messeri > Cc: Rob Stradling >, "trans@ietf.org" > Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 Hi all, I=92d like to propose that the redaction I-D allow for redacting labels abo= ve the 2nd level domain, as determined by the public suffix used, of SAN:dN= SName values. For example, redaction of =93secret.example.com=94 would result in =93{redacted}.example.com=94 while =93secret.example.co.uk=94 would = result in =93{redacted}.example.co.uk=94. The I-D sho= uld also allow for redaction of some subject DN values, especially commonNa= me (the unfortunate reality is this field is still used=85 frequently). To (hopefully) address some of the concerns redaction has encountered in th= e past, we=92d like to propose the addition of a =93redaction signal=94. Th= is is essentially the domain owner publicly signaling that they have opted-= in to redaction of their certificates. While this does not solve the issue = of a client being unable to authoritatively determine that the host name be= ing observed during certificate verification is the one intended in the red= acted precertificate, it does introduce a mechanism for the entity that CT = is intended to protect to assert their acceptance of this tradeoff. We haven=92t identified the precise mechanism via which this redaction sign= al would be communicated, but two options we want to throw out are CAA reco= rds and HTTP header (such as the proposed Expect-CT header). We also have not identified who/what should verify the redaction signal and= when. A CA should check for the presence of the redaction signal before su= bmitting a redacted precert, but if that were the only entity checking, we = would need to determine a way to publicly audit this check. A Log Operator = might check for the presence of a redaction signal before accepting a redac= ted precert, but this introduces a new requirement for logs to make some fo= rm of connection to the domain(s) in the precert. A relying party might che= ck for the presence of the redaction signal when verifying the SCTs, but th= e lack of a redaction signal at the time of connection does not necessarily= represent the state of redaction signal at the time of precert submission.= A log monitor might check for a redaction signal when a precert is discove= red for a domain of interest, in order to help determine whether a discover= ed precert might represent misissuance. Cheers! On Wed, Nov 16, 2016 at 5:45 PM Tarah Wheeler > wrote: I=92m glad to hear it, and looking forward to it. I=92d like to ask about the two things that seem really necessary to me; so= metimes a technical RFC lacks within it the rationale for why we do things.= I=92ve been creating essentially a white paper at the same time as writing= comments and some prescriptive thoughts on privacy. There=92s a fundamental disagreement here over why we would want privacy an= d transparency on a variable slider, and ultimately, it comes down to the m= otivations of the entities involved. Some of us want to sell a product that= provides privacy, and some of us want to sell a product that is only possi= ble with transparency. Let=92s not pretend that we=92re not all faced with = differing incentives. I=92ve been on this list for a while, and very quiet because in general, it= seems like a fool=92s game to try to argue people out of acting in their b= est interests. It wasn=92t until now that I had a solid idea of what would = be useful to this process. There are some very smart people in information security. There are those w= ith strong inclinations towards advocating privacy at multiple levels of or= ganizational size from a individual to a YUUUUUUGE company (sorry, couldn= =92t resist, and we all need to laugh a bit now and then). There are those = who see full transparency as a virtue and I can certainly understand why, b= oth on an ideological and a financial level. I=92ve watched this situation be cautiously talked around for months now, a= nd I=92d be interested to hear people=92s thoughts on asking some unassaila= bly corporate-neutral experts on both sides of this debate to provide guida= nce. Whose opinion are you interested in hearing on whether or not permitti= ng certificate privacy and accepting it as a browser standard is a good ide= a? I=92m putting myself and Symantec out there in a vulnerable way; I and w= e might not always hear what we want to hear, but every one of us wants to = make the internet better in the way we believe will work best. Respectfully, Tarah Wheeler Principal Security Advocate Senior Director of Engineering, Website Security Symantec tarah@symantec.com From: Eran Messeri > Date: Tuesday, November 15, 2016 at 6:17 PM To: Tarah Wheeler > Cc: Rob Stradling >, "trans@ietf.org" > Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 AIUI _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans --_000_D455336B1FD1tarahwheelersymanteccom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Some of the methods of implementing these suggestions seem complex, bu= t there=92s a lot of good ideas here. Clint, what do you think of my sugges= tion on asking some outside SMEs to chime in?

Respectfully,

Tarah Wheeler
Principal Security Advocate
Senior Director of Engineerin= g, Website Security
Symantec

From: Clint Wilson <clint.t.wilson@gmail.com>
Date: Friday, November 18, 2016 at = 7:53 AM
To: Tarah Wheeler <tarah_wheeler@symantec.com>, Eran M= esseri <eranm@google.com>
Cc: Rob Stradling <rob.stradling@comodo.com>, "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Call for adopt= ion: draft-strad-trans-redaction-00

Hi all= , 

I=92d = like to propose that the redaction I-D allow for redacting labels above the= 2nd level domain, as determined by the public suffix used, of SAN:dNSName = values. For example, redaction of =93secret.example.com=94 would result in =93{redacted}.example.com=94 while =93secret.example.co.u= k=94 would result in =93{redacted}.example.co.uk=94. The I-D should also allow for redaction of some subject DN values, especia= lly commonName (the unfortunate reality is this field is still used=85 freq= uently). 

To (ho= pefully) address some of the concerns redaction has encountered in the past= , we=92d like to propose the addition of a =93redaction signal=94. This is = essentially the domain owner publicly signaling that they have opted-in to redaction of their certificates. While this doe= s not solve the issue of a client being unable to authoritatively determine= that the host name being observed during certificate verification is the o= ne intended in the redacted precertificate, it does introduce a mechanism for the entity that CT is intended to protec= t to assert their acceptance of this tradeoff. 

We hav= en=92t identified the precise mechanism via which this redaction signal wou= ld be communicated, but two options we want to throw out are CAA records an= d HTTP header (such as the proposed Expect-CT header). 

We als= o have not identified who/what should verify the redaction signal and when.= A CA should check for the presence of the redaction signal before submitti= ng a redacted precert, but if that were the only entity checking, we would need to determine a way to publicl= y audit this check. A Log Operator might check for the presence of a redact= ion signal before accepting a redacted precert, but this introduces a new r= equirement for logs to make some form of connection to the domain(s) in the precert. A relying party might = check for the presence of the redaction signal when verifying the SCTs, but= the lack of a redaction signal at the time of connection does not necessar= ily represent the state of redaction signal at the time of precert submission. A log monitor might check for a = redaction signal when a precert is discovered for a domain of interest, in = order to help determine whether a discovered precert might represent misiss= uance.

Cheers!

On Wed, Nov 16, 2016 at 5:45 PM Tarah = Wheeler <Tarah_Wheeler@symantec.com> wrote:
I=92m glad to hear it, and looking forward to it.&= nbsp;

I=92d like to ask about the two things that seem r= eally necessary to me; sometimes a technical RFC lacks within it the ration= ale for why we do things. I=92ve been creating essentially a white paper at= the same time as writing comments and some prescriptive thoughts on privacy.

There=92s a fundamental disagreement here over why= we would want privacy and transparency on a variable slider, and ultimatel= y, it comes down to the motivations of the entities involved. Some of us wa= nt to sell a product that provides privacy, and some of us want to sell a product that is only possible with transpare= ncy. Let=92s not pretend that we=92re not all faced with differing incentiv= es.

I=92ve been on this list for a while, and very qui= et because in general, it seems like a fool=92s game to try to argue people= out of acting in their best interests. It wasn=92t until now that I had a = solid idea of what would be useful to this process. 

There are= some very smart people in information security. There are those with stron= g inclinations towards advocating privacy at multiple levels of organizatio= nal size from a individual to a YUUUUUUGE company (sorry, couldn=92t resist, and we all need to laugh a bit now and = then). There are those who see full transparency as a virtue and I can cert= ainly understand why, both on an ideological and a financial level.

I=92ve wa= tched this situation be cautiously talked around for months now, and I=92d = be interested to hear people=92s thoughts on asking some unassailably corpo= rate-neutral experts on both sides of this debate to provide guidance. Whose opinion are you interested in hearing on= whether or not permitting certificate privacy and accepting it as a browse= r standard is a good idea? I=92m putting myself and Symantec out there in a= vulnerable way; I and we might not always hear what we want to hear, but every one of us wants to make the in= ternet better in the way we believe will work best.

Respectfully,

Tarah Wheel= er
Principal S= ecurity Advocate
Senior Dire= ctor of Engineering, Website Security
Symantec
tarah@syma= ntec.com

From: Eran Mess= eri <eranm@google.com>
Date: Tuesday, = November 15, 2016 at 6:17 PM
To: Tarah Wheel= er <tarah_wheeler@symantec.com>
Cc: Rob Stradli= ng <rob.stradling@comodo.com>, "trans@ietf.org" <trans@ietf.org>
Subject: Re: [T= rans] Call for adoption: draft-strad-trans-redaction-00

AIUI
_______________________________________________
Trans mailing list
Tra= ns@ietf.org
https://www.ietf.org/mailman/listinfo= /trans
 --_000_D455336B1FD1tarahwheelersymanteccom_-- From nobody Sat Nov 19 21:45:59 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BCB129516 for ; Sat, 19 Nov 2016 21:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX8AbHPnuYCp for ; Sat, 19 Nov 2016 21:45:56 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9FE12950C for ; Sat, 19 Nov 2016 21:45:56 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 52B9520051C22 for ; Sat, 19 Nov 2016 21:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=sleevi.com; bh=yMgbp+ S+Pnd74gPmlTuaU+mj0Pw=; b=Vdl+heMziTKTxlWIFgYAKUG+n9cQcM2NKDFGtU izd8zVDDu047Vf0j6bb7OMc4CRWVYURkimw6xYrgTr6wItlL1vd2WEzK5ncdP2Ke amPJW+NmgimSnTP5H9Z3AbYVAdsYvnb+pmFZms0W2mRPfvoHPW9yycGsvTfkXoP5 h9vMs= Received: from mail-it0-f46.google.com (mail-it0-f46.google.com [209.85.214.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 40B5120051C20 for ; Sat, 19 Nov 2016 21:45:56 -0800 (PST) Received: by mail-it0-f46.google.com with SMTP id j191so80263037ita.1 for ; Sat, 19 Nov 2016 21:45:56 -0800 (PST) X-Gm-Message-State: AKaTC02hnQCtAa2gRnLrKRRgi2aZElgjee3aZnxSPyPOIlKYwbEvB7uYEr68JE60BQnQE3fx9D854/EUmMPB5g== X-Received: by 10.36.67.8 with SMTP id s8mr4764125itb.50.1479620755668; Sat, 19 Nov 2016 21:45:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.34.97 with HTTP; Sat, 19 Nov 2016 21:45:54 -0800 (PST) In-Reply-To: References: <5b357047-d412-70de-4aa6-9499fa8837b5@comodo.com> <5290c544-97b1-7530-eb0c-e9b62d8ebc71@comodo.com> <2775E6CC-A288-4681-A14F-19A775EDFF15@symantec.com> From: Ryan Sleevi Date: Sat, 19 Nov 2016 21:45:54 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Tarah Wheeler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Eran Messeri , "trans@ietf.org" , Rob Stradling , Clint Wilson Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 05:45:58 -0000 Tarah, It seems like it might be more useful to understand the "Why"s of Clint's proposals, before digging too much into the "How". Do you see external SMEs being useful there? Though I have some trouble with Clint's proposals, I think if we can figure out the "Why" for some of the suggestions, we might be able to explore the technical space to see if there's momentum for a draft (or, perhaps more aptly, pull requests to the redaction draft). However, unless we know why, it seems difficult to judge the complexity cost (compared to alternatives) or if the implementation cost is justified. For example, redacting the commonName, as proposed by Clint, might simply be addressed by requiring that redacted domain labels respect the deprecation notice from RFC2818 and furthered by RFC6125 - namely, don't use commonName for DNS names, use the subjectAltName. If systems that need redaction can't support it, perhaps the cost should be born by updating these systems to reflect the past 18 years of deprecation notices of commonName (see https://tools.ietf.org/html/draft-ietf-tls-https-00#section-3.1 , which became 2818) This is where understanding "Why" can help make more informed decisions and help focus the activity on the drafts. On Fri, Nov 18, 2016 at 10:39 PM, Tarah Wheeler wrote: > Some of the methods of implementing these suggestions seem complex, but > there=E2=80=99s a lot of good ideas here. Clint, what do you think of my = suggestion > on asking some outside SMEs to chime in? > > Respectfully, > > Tarah Wheeler > Principal Security Advocate > Senior Director of Engineering, Website Security > Symantec > tarah@symantec.com > > From: Clint Wilson > Date: Friday, November 18, 2016 at 7:53 AM > To: Tarah Wheeler , Eran Messeri > > > Cc: Rob Stradling , "trans@ietf.org" > > Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 > > Hi all, > > I=E2=80=99d like to propose that the redaction I-D allow for redacting la= bels above > the 2nd level domain, as determined by the public suffix used, of > SAN:dNSName values. For example, redaction of =E2=80=9Csecret.example.com= =E2=80=9D would > result in =E2=80=9C{redacted}.example.com=E2=80=9D while =E2=80=9Csecret.= example.co.uk=E2=80=9D would result > in =E2=80=9C{redacted}.example.co.uk=E2=80=9D. The I-D should also allow = for redaction of > some subject DN values, especially commonName (the unfortunate reality is > this field is still used=E2=80=A6 frequently). > > To (hopefully) address some of the concerns redaction has encountered in = the > past, we=E2=80=99d like to propose the addition of a =E2=80=9Credaction s= ignal=E2=80=9D. This is > essentially the domain owner publicly signaling that they have opted-in t= o > redaction of their certificates. While this does not solve the issue of a > client being unable to authoritatively determine that the host name being > observed during certificate verification is the one intended in the redac= ted > precertificate, it does introduce a mechanism for the entity that CT is > intended to protect to assert their acceptance of this tradeoff. > > We haven=E2=80=99t identified the precise mechanism via which this redact= ion signal > would be communicated, but two options we want to throw out are CAA recor= ds > and HTTP header (such as the proposed Expect-CT header). > > We also have not identified who/what should verify the redaction signal a= nd > when. A CA should check for the presence of the redaction signal before > submitting a redacted precert, but if that were the only entity checking,= we > would need to determine a way to publicly audit this check. A Log Operato= r > might check for the presence of a redaction signal before accepting a > redacted precert, but this introduces a new requirement for logs to make > some form of connection to the domain(s) in the precert. A relying party > might check for the presence of the redaction signal when verifying the > SCTs, but the lack of a redaction signal at the time of connection does n= ot > necessarily represent the state of redaction signal at the time of precer= t > submission. A log monitor might check for a redaction signal when a prece= rt > is discovered for a domain of interest, in order to help determine whethe= r a > discovered precert might represent misissuance. > > Cheers! > > On Wed, Nov 16, 2016 at 5:45 PM Tarah Wheeler > wrote: >> >> I=E2=80=99m glad to hear it, and looking forward to it. >> >> I=E2=80=99d like to ask about the two things that seem really necessary = to me; >> sometimes a technical RFC lacks within it the rationale for why we do >> things. I=E2=80=99ve been creating essentially a white paper at the same= time as >> writing comments and some prescriptive thoughts on privacy. >> >> There=E2=80=99s a fundamental disagreement here over why we would want p= rivacy and >> transparency on a variable slider, and ultimately, it comes down to the >> motivations of the entities involved. Some of us want to sell a product = that >> provides privacy, and some of us want to sell a product that is only >> possible with transparency. Let=E2=80=99s not pretend that we=E2=80=99re= not all faced with >> differing incentives. >> >> I=E2=80=99ve been on this list for a while, and very quiet because in ge= neral, it >> seems like a fool=E2=80=99s game to try to argue people out of acting in= their best >> interests. It wasn=E2=80=99t until now that I had a solid idea of what w= ould be >> useful to this process. >> >> There are some very smart people in information security. There are thos= e >> with strong inclinations towards advocating privacy at multiple levels o= f >> organizational size from a individual to a YUUUUUUGE company (sorry, >> couldn=E2=80=99t resist, and we all need to laugh a bit now and then). T= here are >> those who see full transparency as a virtue and I can certainly understa= nd >> why, both on an ideological and a financial level. >> >> I=E2=80=99ve watched this situation be cautiously talked around for mont= hs now, >> and I=E2=80=99d be interested to hear people=E2=80=99s thoughts on askin= g some unassailably >> corporate-neutral experts on both sides of this debate to provide guidan= ce. >> Whose opinion are you interested in hearing on whether or not permitting >> certificate privacy and accepting it as a browser standard is a good ide= a? >> I=E2=80=99m putting myself and Symantec out there in a vulnerable way; I= and we >> might not always hear what we want to hear, but every one of us wants to >> make the internet better in the way we believe will work best. >> >> Respectfully, >> >> Tarah Wheeler >> Principal Security Advocate >> Senior Director of Engineering, Website Security >> Symantec >> tarah@symantec.com >> >> From: Eran Messeri >> Date: Tuesday, November 15, 2016 at 6:17 PM >> To: Tarah Wheeler >> Cc: Rob Stradling , "trans@ietf.org" >> >> Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 >> >> AIUI >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Sat Nov 19 22:02:25 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7920C12950C for ; Sat, 19 Nov 2016 22:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrRBrZ6xzp7e for ; Sat, 19 Nov 2016 22:02:23 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0973D1294D8 for ; Sat, 19 Nov 2016 22:02:23 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id v84so130245876oie.3 for ; Sat, 19 Nov 2016 22:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pPxUdxigBaQcwH1gAKRr8idy9oyL8d2kZB2KSs8iarM=; b=xZc2QSRIiSiqxTdBWZfuAUsUr3685zFmcFRl5b32vdIqkX7RzefZ58U+Rfn9+Fiy62 ekx3azZsVjJ+cgJnrGKgSXzXwf7tExLakLw/+M0yQ9n9/bkO/y+pV6F084DBBzfj1meH MUKhHiK3jXg3My839ixDyT6/tpl9jyYXVB5rBTWYAXiMuVgWzA4QJUBCWbvEKA+ckFhU hNzALE4Z0YKJwOPWVfuwTrObydlPn0Z9BU1v8h17YC6FWnqrcQeSzQttqNpKAQYHVmsI /uidEhQUZjJOxilTeCtxPg7WDT8gqjK7QY7/dKKp6yOQp6lLnoXUkzb8zNlZd8awH6NP 3cWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pPxUdxigBaQcwH1gAKRr8idy9oyL8d2kZB2KSs8iarM=; b=WkIKohrIAKWHrdAdAm18FL6hDVyvpXTPZcaWD9N/SqIx2RBHgCJfSyUFL+CxNmXIYT ugTbvlVVg/vjzbOJfM6npOFzKl2ElvawobNheQRxj6YQ3QSMISygo3GM5vizV96sXt6A rySVpsEviLqmKGIR22kTakqlyyU4ujKE1Pb9g1q+cETaBDZUT6YlorMWWpXx+Q1l0oyW U5wqn6eQM8yFRPjgLbezHV75elaxaMJtRpG3iDL2XmcQooWxOWqzvIsrbhDabjg4IE3W 65ZghpYviB98KEzkgZHZMbHUeDt3DBQCnnjrcTLis/WEgTf6HbH2rwoWnb0uWdY0gB8I oUBw== X-Gm-Message-State: AKaTC02tNKZkf9Re1gSTwzzme9Ko5CNl3AZaf1asa/SlNZ92bNIzBDcRC1O3v6/ChZ64E+NYmCgkuK0yDRyFvA== X-Received: by 10.202.79.203 with SMTP id d194mr4330966oib.46.1479621742357; Sat, 19 Nov 2016 22:02:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.76.14 with HTTP; Sat, 19 Nov 2016 22:02:21 -0800 (PST) In-Reply-To: References: <5b357047-d412-70de-4aa6-9499fa8837b5@comodo.com> <5290c544-97b1-7530-eb0c-e9b62d8ebc71@comodo.com> <2775E6CC-A288-4681-A14F-19A775EDFF15@symantec.com> From: Peter Bowen Date: Sat, 19 Nov 2016 22:02:21 -0800 Message-ID: To: Tarah Wheeler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Eran Messeri , "trans@ietf.org" , Rob Stradling Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 06:02:24 -0000 On Wed, Nov 16, 2016 at 4:45 PM, Tarah Wheeler wrote: > > I=E2=80=99ve watched this situation be cautiously talked around for month= s now, and > I=E2=80=99d be interested to hear people=E2=80=99s thoughts on asking som= e unassailably > corporate-neutral experts on both sides of this debate to provide guidanc= e. > Whose opinion are you interested in hearing on whether or not permitting > certificate privacy and accepting it as a browser standard is a good idea= ? > I=E2=80=99m putting myself and Symantec out there in a vulnerable way; I = and we > might not always hear what we want to hear, but every one of us wants to > make the internet better in the way we believe will work best. Tarah, There have been multiple requests for use cases to be brought to the group. I have brought some use cases from a group discussion outside the IETF and others have contributed well. We also know that the IETF has addressed DNS privacy in several WGs, including the DNSEXT WG, which developed DNSSEC Hashed Authenticated Denial of Existence (aka NSEC3), and the DPRIVE WG which published DNS Privacy Considerations (RFC 7626). What guidance are you hoping the WG will get by asking for "corporate-neutral experts"? How does that align with the rough consensus model used in WGs? Thanks, Peter From nobody Sun Nov 20 05:14:02 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C275D129653 for ; Sun, 20 Nov 2016 05:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPENosYHesDX for ; Sun, 20 Nov 2016 05:13:57 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BE512962A for ; Sun, 20 Nov 2016 05:13:57 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id j191so84113215ita.1 for ; Sun, 20 Nov 2016 05:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mqI+CmZ+wtJWDfncENDBW9ZYDQFcv6bTyjawmeenByQ=; b=GsEtUrLZb2ZnCsTyd4a7huLsOVvKOwCk3zFoEDBbFgGX9bUWxef3qe9/29JRRxzMuF HnddIr4Oj9ecRNqgptZp4BIeBzo8fvLlGdxYcR7HTJKr3Cd0Fqq9nx5hkFO+4lUoRiu3 KNliZUitZlLdC0mY38qQ9UxiMIZlk8Fi+jhZHgS0cZrWYuUq1WW40O4ymMWJQVGjFgMk xYm6Ss0FYOapIHD6Pklo4yWBHmaNVGfNn1QNiXfgk5Fn2Uiq7w3j8gnEz58vOgCmAWdS v1rbBbrtAdKQiuL3gZaSIzYdMtgY2ImQRhmog0SoK7Nl3uI9S4M9L09+w+0EJFpWTwo5 hw2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mqI+CmZ+wtJWDfncENDBW9ZYDQFcv6bTyjawmeenByQ=; b=S1V3v/LWYkdaYB/YxzOj+i149TunjQuxL/dmjy1WXoKellaBgicC703rpK5j4A8FA1 3Ud52O3Nd1CBh8kdzffN6CjcMuZXtga28yBHt8YOoX8CKqcIpGQku6q6ivtpMfM6kdpx sbTSdSgeZQK6obBqB6e4fjNH/LtQEU0vkm6ZzVJ2mjbDY1mzOf1Ix/BTdzDtpFmtQaWt q95YOlQlvw/YLANFMtxX17s4kbQmEaawnsVi2gm3VmNnaegAwArtyT9fiznJ5Mi08W0W lT+P4FMxSsla6LrjMLqE6W3Jov7XqkyQrO9eUr0DW5uLxfdplC0ftfSlstYf7+iN6cF1 p7xw== X-Gm-Message-State: AKaTC01x0NjlwYN+oU0hqXSLVJmQ2oHeou9WUY28TvO0J0boWhlh0C2NhvIAB94XdsgN0BYDkrvZi7imiGRErg== X-Received: by 10.36.19.9 with SMTP id 9mr5354708itz.32.1479647636808; Sun, 20 Nov 2016 05:13:56 -0800 (PST) MIME-Version: 1.0 References: <5b357047-d412-70de-4aa6-9499fa8837b5@comodo.com> <5290c544-97b1-7530-eb0c-e9b62d8ebc71@comodo.com> <2775E6CC-A288-4681-A14F-19A775EDFF15@symantec.com> In-Reply-To: From: Clint Wilson Date: Sun, 20 Nov 2016 13:13:45 +0000 Message-ID: To: Tarah Wheeler , Eran Messeri Content-Type: multipart/alternative; boundary=001a1144da40c8ecb50541bb4f24 Archived-At: Cc: Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 13:14:01 -0000 --001a1144da40c8ecb50541bb4f24 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The more input we can get, the better, in my opinion. I'm personally not sure how to effectively lobby for more expert opinion than has already been shared here, but I'm supportive of the idea if you've got a plan to do so. On Fri, Nov 18, 2016 at 11:39 PM Tarah Wheeler wrote: > Some of the methods of implementing these suggestions seem complex, but > there=E2=80=99s a lot of good ideas here. Clint, what do you think of my = suggestion > on asking some outside SMEs to chime in? > > Respectfully, > > Tarah Wheeler > Principal Security Advocate > Senior Director of Engineering, Website Security > Symantec > tarah@symantec.com > > From: Clint Wilson > Date: Friday, November 18, 2016 at 7:53 AM > To: Tarah Wheeler , Eran Messeri < > eranm@google.com> > > Cc: Rob Stradling , "trans@ietf.org" < > trans@ietf.org> > Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 > > Hi all, > > I=E2=80=99d like to propose that the redaction I-D allow for redacting la= bels > above the 2nd level domain, as determined by the public suffix used, of > SAN:dNSName values. For example, redaction of =E2=80=9Csecret.example.com= =E2=80=9D would > result in =E2=80=9C{redacted}.example.com=E2=80=9D while =E2=80=9Csecret.= example.co.uk=E2=80=9D would > result in =E2=80=9C{redacted}.example.co.uk=E2=80=9D. The I-D should also= allow for > redaction of some subject DN values, especially commonName (the unfortuna= te > reality is this field is still used=E2=80=A6 frequently). > > To (hopefully) address some of the concerns redaction has encountered in > the past, we=E2=80=99d like to propose the addition of a =E2=80=9Credacti= on signal=E2=80=9D. This > is essentially the domain owner publicly signaling that they have opted-i= n > to redaction of their certificates. While this does not solve the issue o= f > a client being unable to authoritatively determine that the host name bei= ng > observed during certificate verification is the one intended in the > redacted precertificate, it does introduce a mechanism for the entity tha= t > CT is intended to protect to assert their acceptance of this tradeoff. > > We haven=E2=80=99t identified the precise mechanism via which this redact= ion > signal would be communicated, but two options we want to throw out are CA= A > records and HTTP header (such as the proposed Expect-CT header). > > We also have not identified who/what should verify the redaction signal > and when. A CA should check for the presence of the redaction signal befo= re > submitting a redacted precert, but if that were the only entity checking, > we would need to determine a way to publicly audit this check. A Log > Operator might check for the presence of a redaction signal before > accepting a redacted precert, but this introduces a new requirement for > logs to make some form of connection to the domain(s) in the precert. A > relying party might check for the presence of the redaction signal when > verifying the SCTs, but the lack of a redaction signal at the time of > connection does not necessarily represent the state of redaction signal a= t > the time of precert submission. A log monitor might check for a redaction > signal when a precert is discovered for a domain of interest, in order to > help determine whether a discovered precert might represent misissuance. > Cheers! > > On Wed, Nov 16, 2016 at 5:45 PM Tarah Wheeler > wrote: > > I=E2=80=99m glad to hear it, and looking forward to it. > > I=E2=80=99d like to ask about the two things that seem really necessary t= o me; > sometimes a technical RFC lacks within it the rationale for why we do > things. I=E2=80=99ve been creating essentially a white paper at the same = time as > writing comments and some prescriptive thoughts on privacy. > > There=E2=80=99s a fundamental disagreement here over why we would want pr= ivacy and > transparency on a variable slider, and ultimately, it comes down to the > motivations of the entities involved. Some of us want to sell a product > that provides privacy, and some of us want to sell a product that is only > possible with transparency. Let=E2=80=99s not pretend that we=E2=80=99re = not all faced with > differing incentives. > > I=E2=80=99ve been on this list for a while, and very quiet because in gen= eral, it > seems like a fool=E2=80=99s game to try to argue people out of acting in = their best > interests. It wasn=E2=80=99t until now that I had a solid idea of what wo= uld be > useful to this process. > > There are some very smart people in information security. There are those > with strong inclinations towards advocating privacy at multiple levels of > organizational size from a individual to a YUUUUUUGE company (sorry, > couldn=E2=80=99t resist, and we all need to laugh a bit now and then). Th= ere are > those who see full transparency as a virtue and I can certainly understan= d > why, both on an ideological and a financial level. > > I=E2=80=99ve watched this situation be cautiously talked around for month= s now, > and I=E2=80=99d be interested to hear people=E2=80=99s thoughts on asking= some unassailably > corporate-neutral experts on both sides of this debate to provide guidanc= e. > Whose opinion are you interested in hearing on whether or not permitting > certificate privacy and accepting it as a browser standard is a good idea= ? > I=E2=80=99m putting myself and Symantec out there in a vulnerable way; I = and we > might not always hear what we want to hear, but every one of us wants to > make the internet better in the way we believe will work best. > > Respectfully, > > Tarah Wheeler > Principal Security Advocate > Senior Director of Engineering, Website Security > Symantec > tarah@symantec.com > > From: Eran Messeri > Date: Tuesday, November 15, 2016 at 6:17 PM > To: Tarah Wheeler > Cc: Rob Stradling , "trans@ietf.org" < > trans@ietf.org> > Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 > > AIUI > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --001a1144da40c8ecb50541bb4f24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The more input we can get, the better, in my opinion. I= 9;m personally not sure how to effectively lobby for more expert opinion th= an has already been shared here, but I'm supportive of the idea if you&= #39;ve got a plan to do so.


On Fri, Nov 18, 2016 at 11:39 PM Tarah Wheeler <Tarah_Wheeler@symantec.com> wrote:
Some of the methods of implementing these suggesti= ons seem complex, but there=E2=80=99s a lot of good ideas here. Clint, what= do you think of my suggestion on asking some outside SMEs to chime in?

Respectfull= y,

Tarah Wheel= er
Principal S= ecurity Advocate
Senior Dire= ctor of Engineering, Website Security
Symantec
tarah@syma= ntec.com

From: Clint Wil= son <clint.t.wilson@gmail.com>
Date: Friday, N= ovember 18, 2016 at 7:53 AM
To: Tarah Wheel= er <tarah_wheeler@symantec.com>, Eran Messeri <eranm@g= oogle.com>

Cc: Rob Stradli= ng <rob.stradling@comodo.com>, "trans@ietf.org"= <trans@ietf.org>
Subject: Re: [T= rans] Call for adoption: draft-strad-trans-redaction-00

Hi all,=C2=A0

I=E2=80=99d like to propose that the redaction I-D allow fo= r redacting labels above the 2nd level domain, as determined by the public = suffix used, of SAN:dNSName values. For example, redaction of =E2=80=9Csec= ret.example.com=E2=80=9D would result in =E2=80=9C{redacted}.example.com=E2=80=9D while =E2=80=9Csecret.example.co.uk=E2=80=9D would result in =E2=80=9C{redacted}.example.= co.uk=E2=80=9D. The I-D should also allow for redaction of some subject DN values, especia= lly commonName (the unfortunate reality is this field is still used=E2=80= =A6 frequently).=C2=A0

To (hopefully) address some of the concerns redaction has e= ncountered in the past, we=E2=80=99d like to propose the addition of a =E2= =80=9Credaction signal=E2=80=9D. This is essentially the domain owner publi= cly signaling that they have opted-in to redaction of their certificates. While this doe= s not solve the issue of a client being unable to authoritatively determine= that the host name being observed during certificate verification is the o= ne intended in the redacted precertificate, it does introduce a mechanism for the entity that CT is intended to protec= t to assert their acceptance of this tradeoff.=C2=A0

We haven=E2=80=99t identified the precise mechanism via whi= ch this redaction signal would be communicated, but two options we want to = throw out are CAA records and HTTP header (such as the proposed Expect-CT header).=C2=A0

We also have not identified who/what should verify the reda= ction signal and when. A CA should check for the presence of the redaction = signal before submitting a redacted precert, but if that were the only entity checking, we would need to determine a way to publicl= y audit this check. A Log Operator might check for the presence of a redact= ion signal before accepting a redacted precert, but this introduces a new r= equirement for logs to make some form of connection to the domain(s) in the precert. A relying party might = check for the presence of the redaction signal when verifying the SCTs, but= the lack of a redaction signal at the time of connection does not necessar= ily represent the state of redaction signal at the time of precert submission. A log monitor might check for a = redaction signal when a precert is discovered for a domain of interest, in = order to help determine whether a discovered precert might represent misiss= uance.

Cheers!

On Wed, Nov 16, 2016 at 5:45 PM Tarah = Wheeler <Tarah_Wheeler@symantec.com> wrote:
I=E2=80=99m glad to hear it, and looking forward t= o it.=C2=A0

I=E2=80=99d like to ask about the two things that = seem really necessary to me; sometimes a technical RFC lacks within it the = rationale for why we do things. I=E2=80=99ve been creating essentially a wh= ite paper at the same time as writing comments and some prescriptive thoughts on privacy.

There=E2=80=99s a fundamental disagreement here ov= er why we would want privacy and transparency on a variable slider, and ult= imately, it comes down to the motivations of the entities involved. Some of= us want to sell a product that provides privacy, and some of us want to sell a product that is only possible with transpare= ncy. Let=E2=80=99s not pretend that we=E2=80=99re not all faced with differ= ing incentives.

I=E2=80=99ve been on this list for a while, and ve= ry quiet because in general, it seems like a fool=E2=80=99s game to try to = argue people out of acting in their best interests. It wasn=E2=80=99t until= now that I had a solid idea of what would be useful to this process.=C2=A0

There are= some very smart people in information security. There are those with stron= g inclinations towards advocating privacy at multiple levels of organizatio= nal size from a individual to a YUUUUUUGE company (sorry, couldn=E2=80=99t resist, and we all need to laugh a bit no= w and then). There are those who see full transparency as a virtue and I ca= n certainly understand why, both on an ideological and a financial level.

I=E2=80= =99ve watched this situation be cautiously talked around for months now, an= d I=E2=80=99d be interested to hear people=E2=80=99s thoughts on asking som= e unassailably corporate-neutral experts on both sides of this debate to provide guidance. Whose opinion are you interested in hearing on= whether or not permitting certificate privacy and accepting it as a browse= r standard is a good idea? I=E2=80=99m putting myself and Symantec out ther= e in a vulnerable way; I and we might not always hear what we want to hear, but every one of us wants to make the in= ternet better in the way we believe will work best.

Respectfully,

Tarah Wheel= er
Principal S= ecurity Advocate
Senior Dire= ctor of Engineering, Website Security
Symantec
tarah@syma= ntec.com

From: Eran Mess= eri <eranm@google.com>
Date: Tuesday, = November 15, 2016 at 6:17 PM
To: Tarah Wheel= er <tarah_wheeler@symantec.com>
Cc: Rob Stradli= ng <rob.stradling@comodo.com>, "trans@ietf.org" <trans@ietf.org>
Subject: Re: [T= rans] Call for adoption: draft-strad-trans-redaction-00

AIUI
_______________________________________________
Trans mailing list
Tra= ns@ietf.org
https://www.ietf.org/mailman/listinfo= /trans
--001a1144da40c8ecb50541bb4f24-- From nobody Sun Nov 20 05:35:24 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EC0129666 for ; Sun, 20 Nov 2016 05:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1AwjhrX9cjH for ; Sun, 20 Nov 2016 05:35:19 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681AB129661 for ; Sun, 20 Nov 2016 05:35:19 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id l8so71093277iti.1 for ; Sun, 20 Nov 2016 05:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9dNhvUiyBYMTJg3eEtMNyCrqJdoimbUMvap2XZu9rg0=; b=R5YZyYOfP3TkaxDev+F5ux1AVTwCaOryo/BVASXyRqR3m0ayETtXDh0SzTPj68WRD9 R7SlPw/dOH/YJdikXLV+4lqvG2KiSNGxHG9tP/HYliIr8CHoD0TRRIUY5sgchxverryR +JI4kEGAKYCFcOdONTzFqGohS1wFYRTXGokPgMqwSb/e6bB9NF8k0At9knPwCxAlXa2Z BG5+qbv4kjKAKJ0+93tEq/bfxe6YNq+zsYVRAVyrelZbRkUVXm5XEzZR7QuiAbeM/RG1 989KmaetFQcVLMtJDMwIGhxIm0hmzaxaQ7j4OTzqRG0sMl9/QLDGF2NKIgrSc5jT5p/m Fjzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9dNhvUiyBYMTJg3eEtMNyCrqJdoimbUMvap2XZu9rg0=; b=CY6j+xN9JJzJ+FIY0voGz/0nXTSZZapSBSmR1hdG1aNzRum7ZhKl/yQS39rP9RJ83I e0siFPAXGENn4VUyfPGpHfezKzFYy5FIqZonFqg31PQokckcCmdOIW5lMDl8EIOGAUcW yNlXFmB8ZHQGcuTrDqYz5gmtKUogvsYZIV7yGNlWTd8G5Xd3IWnWkMOOLCFAyl2Hu9P2 7OIoFNPpUbxm/dqOWkvBjvZmpSr1MQRGDqIk6zrkTaX64YnBJkiuQMso9z+7E1sWTMA3 xlcliiPFrEB2SPWJGYcTxfo8kFqfZHpmkHM6KK3BCOuLZyUjQAvGNV6u79UHOmcpbTE9 sOHw== X-Gm-Message-State: AKaTC021FRi777mnMEuaFXP9cWioAK+pY9NSVkzqSFQl5hIerSng6WL4YpxuiolVMWEpBXDpVCd8elk5442IHg== X-Received: by 10.36.82.85 with SMTP id d82mr5760974itb.95.1479648918644; Sun, 20 Nov 2016 05:35:18 -0800 (PST) MIME-Version: 1.0 References: <5b357047-d412-70de-4aa6-9499fa8837b5@comodo.com> <5290c544-97b1-7530-eb0c-e9b62d8ebc71@comodo.com> <2775E6CC-A288-4681-A14F-19A775EDFF15@symantec.com> In-Reply-To: From: Clint Wilson Date: Sun, 20 Nov 2016 13:35:07 +0000 Message-ID: To: Ryan Sleevi , Tarah Wheeler Content-Type: multipart/alternative; boundary=001a1142f376302d9f0541bb9c6d Archived-At: Cc: Eran Messeri , "trans@ietf.org" , Rob Stradling Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 13:35:23 -0000 --001a1142f376302d9f0541bb9c6d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for bringing this up. Understanding the "Why"s is vital to moving forward on this draft. To that end, the primary, specific use-case for this need to be able to redact some parts of an FQDN in a precert is split-horizon DNS. When effectively used, an external DNS query will not see the same responses as one received internally to a corporate network. Because of this, a corporate entity might have DNS naming structures which should not be made widely known and could not be easily discovered by external parties. The primary need is for subjectAltName:dNSName values to be redactable, as that is the primary way FQDNs are included in a certificate. The "Why" for commonName values is simply that this field is (unfortunately) still used quite widely as part of DNS name/certificate validation. It's end-user (in this case, TLS administrators at companies deploying split-horizon DNS and wanting to maintain secrecy of some parts of their internal DNS structure) expectation that all fields housing an FQDN be redactable in the same or similar ways. I would like to see a solution that allows for redacting commonName values, but ultimately I can understand and agree with keeping the scope more narrowly focused on subjectAltName values; not only because commonName is deprecated, but also because subjectAltName:dNSName is much more well-defined and, I think, easier to define a redaction spec for. On Sat, Nov 19, 2016 at 10:45 PM Ryan Sleevi wrote: > Tarah, > > It seems like it might be more useful to understand the "Why"s of > Clint's proposals, before digging too much into the "How". Do you see > external SMEs being useful there? > > Though I have some trouble with Clint's proposals, I think if we can > figure out the "Why" for some of the suggestions, we might be able to > explore the technical space to see if there's momentum for a draft > (or, perhaps more aptly, pull requests to the redaction draft). > However, unless we know why, it seems difficult to judge the > complexity cost (compared to alternatives) or if the implementation > cost is justified. > > For example, redacting the commonName, as proposed by Clint, might > simply be addressed by requiring that redacted domain labels respect > the deprecation notice from RFC2818 and furthered by RFC6125 - namely, > don't use commonName for DNS names, use the subjectAltName. If systems > that need redaction can't support it, perhaps the cost should be born > by updating these systems to reflect the past 18 years of deprecation > notices of commonName (see > https://tools.ietf.org/html/draft-ietf-tls-https-00#section-3.1 , > which became 2818) > > This is where understanding "Why" can help make more informed > decisions and help focus the activity on the drafts. > > On Fri, Nov 18, 2016 at 10:39 PM, Tarah Wheeler > wrote: > > Some of the methods of implementing these suggestions seem complex, but > > there=E2=80=99s a lot of good ideas here. Clint, what do you think of m= y > suggestion > > on asking some outside SMEs to chime in? > > > > Respectfully, > > > > Tarah Wheeler > > Principal Security Advocate > > Senior Director of Engineering, Website Security > > Symantec > > tarah@symantec.com > > > > From: Clint Wilson > > Date: Friday, November 18, 2016 at 7:53 AM > > To: Tarah Wheeler , Eran Messeri > > > > > > Cc: Rob Stradling , "trans@ietf.org" > > > > Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 > > > > Hi all, > > > > I=E2=80=99d like to propose that the redaction I-D allow for redacting = labels > above > > the 2nd level domain, as determined by the public suffix used, of > > SAN:dNSName values. For example, redaction of =E2=80=9Csecret.example.c= om=E2=80=9D would > > result in =E2=80=9C{redacted}.example.com=E2=80=9D while =E2=80=9Csecre= t.example.co.uk=E2=80=9D would > result > > in =E2=80=9C{redacted}.example.co.uk=E2=80=9D. The I-D should also allo= w for redaction > of > > some subject DN values, especially commonName (the unfortunate reality = is > > this field is still used=E2=80=A6 frequently). > > > > To (hopefully) address some of the concerns redaction has encountered i= n > the > > past, we=E2=80=99d like to propose the addition of a =E2=80=9Credaction= signal=E2=80=9D. This is > > essentially the domain owner publicly signaling that they have opted-in > to > > redaction of their certificates. While this does not solve the issue of= a > > client being unable to authoritatively determine that the host name bei= ng > > observed during certificate verification is the one intended in the > redacted > > precertificate, it does introduce a mechanism for the entity that CT is > > intended to protect to assert their acceptance of this tradeoff. > > > > We haven=E2=80=99t identified the precise mechanism via which this reda= ction > signal > > would be communicated, but two options we want to throw out are CAA > records > > and HTTP header (such as the proposed Expect-CT header). > > > > We also have not identified who/what should verify the redaction signal > and > > when. A CA should check for the presence of the redaction signal before > > submitting a redacted precert, but if that were the only entity > checking, we > > would need to determine a way to publicly audit this check. A Log > Operator > > might check for the presence of a redaction signal before accepting a > > redacted precert, but this introduces a new requirement for logs to mak= e > > some form of connection to the domain(s) in the precert. A relying part= y > > might check for the presence of the redaction signal when verifying the > > SCTs, but the lack of a redaction signal at the time of connection does > not > > necessarily represent the state of redaction signal at the time of > precert > > submission. A log monitor might check for a redaction signal when a > precert > > is discovered for a domain of interest, in order to help determine > whether a > > discovered precert might represent misissuance. > > > > Cheers! > > > > On Wed, Nov 16, 2016 at 5:45 PM Tarah Wheeler < > Tarah_Wheeler@symantec.com> > > wrote: > >> > >> I=E2=80=99m glad to hear it, and looking forward to it. > >> > >> I=E2=80=99d like to ask about the two things that seem really necessar= y to me; > >> sometimes a technical RFC lacks within it the rationale for why we do > >> things. I=E2=80=99ve been creating essentially a white paper at the sa= me time as > >> writing comments and some prescriptive thoughts on privacy. > >> > >> There=E2=80=99s a fundamental disagreement here over why we would want= privacy > and > >> transparency on a variable slider, and ultimately, it comes down to th= e > >> motivations of the entities involved. Some of us want to sell a produc= t > that > >> provides privacy, and some of us want to sell a product that is only > >> possible with transparency. Let=E2=80=99s not pretend that we=E2=80=99= re not all faced > with > >> differing incentives. > >> > >> I=E2=80=99ve been on this list for a while, and very quiet because in = general, > it > >> seems like a fool=E2=80=99s game to try to argue people out of acting = in their > best > >> interests. It wasn=E2=80=99t until now that I had a solid idea of what= would be > >> useful to this process. > >> > >> There are some very smart people in information security. There are > those > >> with strong inclinations towards advocating privacy at multiple levels > of > >> organizational size from a individual to a YUUUUUUGE company (sorry, > >> couldn=E2=80=99t resist, and we all need to laugh a bit now and then).= There are > >> those who see full transparency as a virtue and I can certainly > understand > >> why, both on an ideological and a financial level. > >> > >> I=E2=80=99ve watched this situation be cautiously talked around for mo= nths now, > >> and I=E2=80=99d be interested to hear people=E2=80=99s thoughts on ask= ing some > unassailably > >> corporate-neutral experts on both sides of this debate to provide > guidance. > >> Whose opinion are you interested in hearing on whether or not permitti= ng > >> certificate privacy and accepting it as a browser standard is a good > idea? > >> I=E2=80=99m putting myself and Symantec out there in a vulnerable way;= I and we > >> might not always hear what we want to hear, but every one of us wants = to > >> make the internet better in the way we believe will work best. > >> > >> Respectfully, > >> > >> Tarah Wheeler > >> Principal Security Advocate > >> Senior Director of Engineering, Website Security > >> Symantec > >> tarah@symantec.com > >> > >> From: Eran Messeri > >> Date: Tuesday, November 15, 2016 at 6:17 PM > >> To: Tarah Wheeler > >> Cc: Rob Stradling , "trans@ietf.org" > >> > >> Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 > >> > >> AIUI > >> _______________________________________________ > >> Trans mailing list > >> Trans@ietf.org > >> https://www.ietf.org/mailman/listinfo/trans > > > > > > _______________________________________________ > > Trans mailing list > > Trans@ietf.org > > https://www.ietf.org/mailman/listinfo/trans > > > --001a1142f376302d9f0541bb9c6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for bringing this up. Understanding the "Why&q= uot;s is vital to moving forward on this draft. To that end, the primary, s= pecific use-case for this need to be able to redact some parts of an FQDN i= n a precert is split-horizon DNS. When effectively used, an external DNS qu= ery will not see the same responses as one received internally to a corpora= te network. Because of this, a corporate entity might have DNS naming struc= tures which should not be made widely known and could not be easily discove= red by external parties.

The primary need is for subject= AltName:dNSName values to be redactable, as that is the primary way FQDNs a= re included in a certificate. The "Why" for commonName values is = simply that this field is (unfortunately) still used quite widely as part o= f DNS name/certificate validation. It's end-user (in this case, TLS adm= inistrators at companies deploying split-horizon DNS and wanting to maintai= n secrecy of some parts of their internal DNS structure) expectation that a= ll fields housing an FQDN be redactable in the same or similar ways.
<= div>=C2=A0
I would like to see a solution that allows for redacti= ng commonName values, but ultimately I can understand and agree with keepin= g the scope more narrowly focused on subjectAltName values; not only becaus= e commonName is deprecated, but also because subjectAltName:dNSName is much= more well-defined and, I think, easier to define a redaction spec for.
=
On Sat, Nov 19, 2016 at 10:= 45 PM Ryan Sleevi <ryan-ietf@sle= evi.com> wrote:
Tarah,

It seems like it might be more useful to understand the "Why"s of=
Clint's proposals, before digging too much into the "How". Do= you see
external SMEs being useful there?

Though I have some trouble with Clint's proposals, I think if we can figure out the "Why" for some of the suggestions, we might be abl= e to
explore the technical space to see if there's momentum for a draft
(or, perhaps more aptly, pull requests to the redaction draft).
However, unless we know why, it seems difficult to judge the
complexity cost (compared to alternatives) or if the implementation
cost is justified.

For example, redacting the commonName, as proposed by Clint, might
simply be addressed by requiring that redacted domain labels respect
the deprecation notice from RFC2818 and furthered by RFC6125 - namely,
don't use commonName for DNS names, use the subjectAltName. If systems<= br class=3D"gmail_msg"> that need redaction can't support it, perhaps the cost should be born by updating these systems to reflect the past 18 years of deprecation
notices of commonName (see
https://tools.iet= f.org/html/draft-ietf-tls-https-00#section-3.1 ,
which became 2818)

This is where understanding "Why" can help make more informed
decisions and help focus the activity on the drafts.

On Fri, Nov 18, 2016 at 10:39 PM, Tarah Wheeler
<Tarah_Wheeler@symantec.com> wrote:
> Some of the methods of implementing these suggestions seem complex, bu= t
> there=E2=80=99s a lot of good ideas here. Clint, what do you think of = my suggestion
> on asking some outside SMEs to chime in?
>
> Respectfully,
>
> Tarah Wheeler
> Principal Security Advocate
> Senior Director of Engineering, Website Security
> Symantec
> tarah@symantec.com
>
> From: Clint Wilson <clint.t.wilson@gmail.com>
> Date: Friday, November 18, 2016 at 7:53 AM
> To: Tarah Wheeler <tarah_wheeler@symantec.com>, Era= n Messeri
> <eranm@google.com>
>
> Cc: Rob Stradling <rob.stradling@comodo.com>, "<= a href=3D"mailto:trans@ietf.org" class=3D"gmail_msg" target=3D"_blank">tran= s@ietf.org"
> <trans@ietf.org>
> Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00=
>
> Hi all,
>
> I=E2=80=99d like to propose that the redaction I-D allow for redacting= labels above
> the 2nd level domain, as determined by the public suffix used, of
> SAN:dNSName values. For example, redaction of =E2=80=9Csecret.example.com=E2=80=9D would
> result in =E2=80=9C{redacted}.example.com=E2=80=9D wh= ile =E2=80=9Csecret.example.co.uk=E2=80=9D would = result
> in =E2=80=9C{redacted}.example.co.uk=E2=80=9D. The = I-D should also allow for redaction of
> some subject DN values, especially commonName (the unfortunate reality= is
> this field is still used=E2=80=A6 frequently).
>
> To (hopefully) address some of the concerns redaction has encountered = in the
> past, we=E2=80=99d like to propose the addition of a =E2=80=9Credactio= n signal=E2=80=9D. This is
> essentially the domain owner publicly signaling that they have opted-i= n to
> redaction of their certificates. While this does not solve the issue o= f a
> client being unable to authoritatively determine that the host name be= ing
> observed during certificate verification is the one intended in the re= dacted
> precertificate, it does introduce a mechanism for the entity that CT i= s
> intended to protect to assert their acceptance of this tradeoff.
>
> We haven=E2=80=99t identified the precise mechanism via which this red= action signal
> would be communicated, but two options we want to throw out are CAA re= cords
> and HTTP header (such as the proposed Expect-CT header).
>
> We also have not identified who/what should verify the redaction signa= l and
> when. A CA should check for the presence of the redaction signal befor= e
> submitting a redacted precert, but if that were the only entity checki= ng, we
> would need to determine a way to publicly audit this check. A Log Oper= ator
> might check for the presence of a redaction signal before accepting a<= br class=3D"gmail_msg"> > redacted precert, but this introduces a new requirement for logs to ma= ke
> some form of connection to the domain(s) in the precert. A relying par= ty
> might check for the presence of the redaction signal when verifying th= e
> SCTs, but the lack of a redaction signal at the time of connection doe= s not
> necessarily represent the state of redaction signal at the time of pre= cert
> submission. A log monitor might check for a redaction signal when a pr= ecert
> is discovered for a domain of interest, in order to help determine whe= ther a
> discovered precert might represent misissuance.
>
> Cheers!
>
> On Wed, Nov 16, 2016 at 5:45 PM Tarah Wheeler <Tarah_Wheel= er@symantec.com>
> wrote:
>>
>> I=E2=80=99m glad to hear it, and looking forward to it.
>>
>> I=E2=80=99d like to ask about the two things that seem really nece= ssary to me;
>> sometimes a technical RFC lacks within it the rationale for why we= do
>> things. I=E2=80=99ve been creating essentially a white paper at th= e same time as
>> writing comments and some prescriptive thoughts on privacy.
>>
>> There=E2=80=99s a fundamental disagreement here over why we would = want privacy and
>> transparency on a variable slider, and ultimately, it comes down t= o the
>> motivations of the entities involved. Some of us want to sell a pr= oduct that
>> provides privacy, and some of us want to sell a product that is on= ly
>> possible with transparency. Let=E2=80=99s not pretend that we=E2= =80=99re not all faced with
>> differing incentives.
>>
>> I=E2=80=99ve been on this list for a while, and very quiet because= in general, it
>> seems like a fool=E2=80=99s game to try to argue people out of act= ing in their best
>> interests. It wasn=E2=80=99t until now that I had a solid idea of = what would be
>> useful to this process.
>>
>> There are some very smart people in information security. There ar= e those
>> with strong inclinations towards advocating privacy at multiple le= vels of
>> organizational size from a individual to a YUUUUUUGE company (sorr= y,
>> couldn=E2=80=99t resist, and we all need to laugh a bit now and th= en). There are
>> those who see full transparency as a virtue and I can certainly un= derstand
>> why, both on an ideological and a financial level.
>>
>> I=E2=80=99ve watched this situation be cautiously talked around fo= r months now,
>> and I=E2=80=99d be interested to hear people=E2=80=99s thoughts on= asking some unassailably
>> corporate-neutral experts on both sides of this debate to provide = guidance.
>> Whose opinion are you interested in hearing on whether or not perm= itting
>> certificate privacy and accepting it as a browser standard is a go= od idea?
>> I=E2=80=99m putting myself and Symantec out there in a vulnerable = way; I and we
>> might not always hear what we want to hear, but every one of us wa= nts to
>> make the internet better in the way we believe will work best.
>>
>> Respectfully,
>>
>> Tarah Wheeler
>> Principal Security Advocate
>> Senior Director of Engineering, Website Security
>> Symantec
>> tarah@symantec.com
>>
>> From: Eran Messeri <eranm@google.com>
>> Date: Tuesday, November 15, 2016 at 6:17 PM
>> To: Tarah Wheeler <tarah_wheeler@symantec.com><= br class=3D"gmail_msg"> >> Cc: Rob Stradling <rob.stradling@comodo.com>, &qu= ot;= trans@ietf.org"
>> <trans@ietf.org>
>> Subject: Re: [Trans] Call for adoption: draft-strad-trans-redactio= n-00
>>
>> AIUI
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman= /listinfo/trans
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/trans
>
--001a1142f376302d9f0541bb9c6d-- From nobody Sun Nov 20 07:31:57 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4171912960F for ; Sun, 20 Nov 2016 07:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKuMiu9szCJ5 for ; Sun, 20 Nov 2016 07:31:54 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 55AB51295A3 for ; Sun, 20 Nov 2016 07:31:54 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A7DE5433401; Sun, 20 Nov 2016 15:31:53 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 915CF433403; Sun, 20 Nov 2016 15:31:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479655913; bh=uPMXeqU3qQr1Iq98XdMChRb/zXR07UiQm8dzm/cGLcc=; l=268; h=From:To:CC:Date:References:In-Reply-To:From; b=yHSj91HIVhTQXm7dzGWHbk8Fx6OG6pY4Q4PfVANe6gE77BMDNxt4Xh16GQDitbuRa 8Cw2w2zC8zFB31/eBwKGso4u9m7GtjnhBM/0UOC6HGsKm5XPAOAjGCQoGy5isKPiLG o2uwkSileYYCeHbBIfQB9olPAbokAh7reUTbNJ8I= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 8C6CF1FC86; Sun, 20 Nov 2016 15:31:53 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 20 Nov 2016 07:31:53 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 20 Nov 2016 10:31:52 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Sun, 20 Nov 2016 10:31:53 -0500 From: "Salz, Rich" To: Clint Wilson , Tarah Wheeler , Eran Messeri Thread-Topic: [Trans] Call for adoption: draft-strad-trans-redaction-00 Thread-Index: AQHSCthRYWhhMMTMIk2V0jdnbRn0D6B7Q5CAgAEB0ACAAJTWAIAHacQAgABRuoCAAzJqAIAycQ6AgAQ4QwCAHSu9AIABeKmAgAKQIoCAAPeGAIACAHyA///SYMA= Date: Sun, 20 Nov 2016 15:31:53 +0000 Message-ID: <99ea8206c346463abcb820dd043660b4@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5b357047-d412-70de-4aa6-9499fa8837b5@comodo.com> <5290c544-97b1-7530-eb0c-e9b62d8ebc71@comodo.com> <2775E6CC-A288-4681-A14F-19A775EDFF15@symantec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.78] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 15:31:55 -0000 DQo+IFRoZSBtb3JlIGlucHV0IHdlIGNhbiBnZXQsIHRoZSBiZXR0ZXIsIGluIG15IG9waW5pb24u DQoNCkFueWJvZHkgY2FuIGpvaW4gdGhlIGVtYWlsIGxpc3QuICBBbnlvbmUgY2FuIGhhdmUgaW5w dXQgZm9yd2FyZGVkLCBidXQgd2l0aG91dCBkaXJlY3QgcGFydGljaXBhdGlvbiwgdGhlaXIgb3Bp bmlvbiBpcyBsZXNzIHZhbHVlZC4NCg== From nobody Sun Nov 20 21:42:19 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B34B129568 for ; Sun, 20 Nov 2016 21:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLR_d4urPrdD for ; Sun, 20 Nov 2016 21:42:17 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D66129515 for ; Sun, 20 Nov 2016 21:42:16 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tMctY41T3z3HC; Mon, 21 Nov 2016 06:42:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479706933; bh=QM8PhkHhB+J48h1EZ7rP7PRzBeto1fzWT1G91muwtco=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=QU4XyzVesUZwWyQh6JONdMxc7Dd03VWqplc3VTzOumitq8a2Cc1G8WS8gChXDdVeT cFSg9fPBJV0EJOmpmfVmKdsXnDzOUpOcM54eOqs7sVMjHlIrlkTpK+nkRzRIHSudaX E8ViNRErwuMIAPBI0myhUc9GVoVTe38OPlFZXrQU= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LycpgbX1v6gE; Mon, 21 Nov 2016 06:42:12 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 21 Nov 2016 06:42:11 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 008A93797CE; Mon, 21 Nov 2016 00:42:10 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 008A93797CE Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DBD2B40D3581; Mon, 21 Nov 2016 00:42:10 -0500 (EST) Date: Mon, 21 Nov 2016 00:42:10 -0500 (EST) From: Paul Wouters To: Tarah Wheeler In-Reply-To: Message-ID: References: <5b357047-d412-70de-4aa6-9499fa8837b5@comodo.com> <5290c544-97b1-7530-eb0c-e9b62d8ebc71@comodo.com> <2775E6CC-A288-4681-A14F-19A775EDFF15@symantec.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: Eran Messeri , "trans@ietf.org" , Rob Stradling , Clint Wilson Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 05:42:18 -0000 On Sat, 19 Nov 2016, Tarah Wheeler wrote: [ chair hat on ] > Some of the methods of implementing these suggestions seem complex, but there’s a lot of good ideas > here. Clint, what do you think of my suggestion on asking some outside SMEs to chime in? There are no "insiders" or "outsiders" at IETF. Everyone is welcome to join any Working Group or mailing list or any discussion or meeting the IETF holds. We strongly encourage everyone who is interested to participate. Participation is done as individuals only. For more information, please see: https://www.ietf.org/tao.html https://www.ietf.org/newcomers.html Paul From nobody Mon Nov 21 01:41:12 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E4C129967 for ; Mon, 21 Nov 2016 01:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zN3w1Jsr0ldw for ; Mon, 21 Nov 2016 01:41:08 -0800 (PST) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1681298C1 for ; Mon, 21 Nov 2016 01:41:07 -0800 (PST) Received: (qmail 14683 invoked by uid 1004); 21 Nov 2016 09:41:05 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 21 Nov 2016 09:41:05 +0000 Received: (qmail 24876 invoked by uid 1000); 21 Nov 2016 09:41:05 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 21 Nov 2016 09:41:05 +0000 To: Ryan Sleevi , Tarah Wheeler References: <5b357047-d412-70de-4aa6-9499fa8837b5@comodo.com> <5290c544-97b1-7530-eb0c-e9b62d8ebc71@comodo.com> <2775E6CC-A288-4681-A14F-19A775EDFF15@symantec.com> From: Rob Stradling Message-ID: <89991c3f-1799-6594-d512-5302654064b8@comodo.com> Date: Mon, 21 Nov 2016 09:41:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Eran Messeri , "trans@ietf.org" , Clint Wilson Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 09:41:11 -0000 On 20/11/16 05:45, Ryan Sleevi wrote: > For example, redacting the commonName, as proposed by Clint, might > simply be addressed by requiring that redacted domain labels respect > the deprecation notice from RFC2818 and furthered by RFC6125 - namely, > don't use commonName for DNS names, use the subjectAltName. If systems > that need redaction can't support it, perhaps the cost should be born > by updating these systems to reflect the past 18 years of deprecation > notices of commonName (see > https://tools.ietf.org/html/draft-ietf-tls-https-00#section-3.1 , > which became 2818) We've flip-flopped several times on this topic during the last several years' worth of discussions on redaction. See here, for example: https://trac.ietf.org/trac/trans/ticket/17 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Nov 22 16:03:01 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725E81294B1 for ; Tue, 22 Nov 2016 16:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1bxtW3Dc48l for ; Tue, 22 Nov 2016 16:02:58 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2212F129440 for ; Tue, 22 Nov 2016 16:02:58 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id f188so12583660pgc.3 for ; Tue, 22 Nov 2016 16:02:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version; bh=Rj9Y80vZGHDO9aVMRqGg0pmYV01+jZ7lmgPKsK4sk1A=; b=i4LJyew589J2SaS1L621+eLmpShSLd1wyglIBQf42UirA4vU8AwL/TBSnuw3U4O/n3 uLYJxcw31IVRS6g85mTofWXqPdF0Rly5ZxWPRgwb1KEpmj6axOJ9gPmxjgUSSemHqGoV OYfvVHtdGlHTT8he3Udf79IWb/aE0YmlIBg7NRAGAGbze/t0SwTxqxERxDJlva1yKiVL WIcp/U5SHdZub8qWx8ugT12Yy8BptFBVFA6cG9nDP0xp9PeXIpBA1s6o+ozFNeDJFoiI aEOcFf13RXDXQtW/V1luwMZw/Tyo9Ul9Lea8HI+XL5uBOw5KAhZtUxVjBFOt9CPysc4Q aYkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=Rj9Y80vZGHDO9aVMRqGg0pmYV01+jZ7lmgPKsK4sk1A=; b=kDvZjTiJWMvVfP+/flLFuvqV/PPKFF8mId63/ZN5YMorHub2oqD1PeUTvkKeW8nhl4 aKV0jrNfuUTunPaZ/K5Jq9ppQiTGczMRYW71I7rVuwli+Y6FHaW1Yi6t4g+xcWxsYpAc QK5eMus6nqhSwPJRLP09wjqajSfXPad3QVUYFgEC42yJ5HVCXDK4mqON//wilE7kY5du IBnVnKCuEIGhXjahg6WILzE9C3AUBQs236cDwL+ld/q7IeWyAXImw597yvBlOjSxgPDJ +FRDNcrOtvQ3kb4jLpqITz6CsexIDkiVsjTIa0zKIb7IAbm/99dFf/HUM3bTghexAyHv abfg== X-Gm-Message-State: AKaTC03i1S3/HieYnMfcaGA37djipsBx9en16d8WHjXS+v8G6sTItE0kMKq4IFT6NcubRg== X-Received: by 10.84.157.74 with SMTP id u10mr583730plu.153.1479859377287; Tue, 22 Nov 2016 16:02:57 -0800 (PST) Received: from Melindas-MacBook-Pro.local (216-67-10-94-radius.dynamic.acsalaska.net. [216.67.10.94]) by smtp.googlemail.com with ESMTPSA id b64sm47624061pfc.74.2016.11.22.16.02.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2016 16:02:56 -0800 (PST) To: "trans@ietf.org" From: Melinda Shore Message-ID: Date: Tue, 22 Nov 2016 15:02:53 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="A27AfIjAxe5HHVhJHV2aJKqC4mttRHxVh" Archived-At: Subject: [Trans] IETF 97 minutes X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 00:03:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A27AfIjAxe5HHVhJHV2aJKqC4mttRHxVh Content-Type: multipart/mixed; boundary="Rp3JORXJBi4AUCQnt2FCWn6qdENmCrPSF"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: Subject: IETF 97 minutes --Rp3JORXJBi4AUCQnt2FCWn6qdENmCrPSF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I've uploaded a first draft of the minutes from last week's session to https://www.ietf.org/proceedings/97/minutes/minutes-97-trans-0= 0. Please let us know about corrections or additions. Many thanks to Allison for her very detailed notes! Melinda --Rp3JORXJBi4AUCQnt2FCWn6qdENmCrPSF-- --A27AfIjAxe5HHVhJHV2aJKqC4mttRHxVh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYNNyuAAoJELiGRpM6HoEuC+MQAKYugwNim1U9Bt6/J7N7rVmk NDluHaOaqyqEXnnbL9vX1aDporYGpsdyvPiO2bQXbKi7tWishBt/zQr1GxchuxGz ssF+lOpxf8bKMg5q1QE3dRz5Y6ag1ODQccaOSLkPcea+oD6w4SmulwZrW5K9u7Lz +gl6j9PAa13P9OYCinYyREIvOylQ+fX7TsaADUnUZwIA7x3wl+/5Y0GcA871SdZp v3jV7499mXy9TgIDY3YcWBlJI3UnUfzXAomzC1kMaBskwjLmNRu/4OZ9XsVx43Jj jEFesg17LMxjurmCRPnFtIuuJpKM1RIMbVfc/IO7+IDXnJxYoUnRqvyW0xF2qy1U 6PXWPLEfwDyWzx+UDZV/Vj+NCR7Xb8SWlEN76HYkaoer+DvcXW54qqvf3tpvB3YS k4xJu18iQMFWy9zl9bF5eAt8tPtXxKvp8EuHR2ipFy9iJu5i90Sdngh7YoOJVLgm /S1S2FM38mcbEIablzGQyMydrpBGrRlAzJCMhdY1T17ZeXSjjpxF4f1IH0Eua1pc Py/vCDs04MFRU/wMbfDPgDI3QSu5/I6yMtiK+WF4ZgzJlS7q8B2oyiSUw/PtbpWG E4HAAEyExZ33pLdVrxPjWCjkwxpa62QuSdIZgn3iEjoYI5EszUCZqnCZCkSFhUq4 YQjjPMBu2s37QqkIZ5Ke =b11j -----END PGP SIGNATURE----- --A27AfIjAxe5HHVhJHV2aJKqC4mttRHxVh-- From nobody Thu Nov 24 04:34:02 2016 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F2B129532; Thu, 24 Nov 2016 04:33:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147999083781.2554.8110233591871811354.idtracker@ietfa.amsl.com> Date: Thu, 24 Nov 2016 04:33:57 -0800 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-21.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 12:33:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency of the IETF. Title : Certificate Transparency Authors : Ben Laurie Adam Langley Emilia Kasper Eran Messeri Rob Stradling Filename : draft-ietf-trans-rfc6962-bis-21.txt Pages : 50 Date : 2016-11-24 Abstract: This document describes a protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 24 04:46:48 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E4F12953C for ; Thu, 24 Nov 2016 04:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UkyoQeKmll3 for ; Thu, 24 Nov 2016 04:46:44 -0800 (PST) Received: from mail-wj0-x22b.google.com (mail-wj0-x22b.google.com [IPv6:2a00:1450:400c:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104FB129538 for ; Thu, 24 Nov 2016 04:46:43 -0800 (PST) Received: by mail-wj0-x22b.google.com with SMTP id v7so32705332wjy.2 for ; Thu, 24 Nov 2016 04:46:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=5gH/4PrYLOzeLRir1stkdmB8+YtWiFjfXTqEr46kzrw=; b=KuQ8Vv20ZAsDRKASXX1ce102pDZZiBrp63v5cEUlt6YHmKnT72vktgC8pEtoGm8Qk8 aVj17RBqHGtJe2hFEtEZg5IAanXo8xu6HGA9Q1Izi9BGHdqTMqlIWx/jXH+F2kZceKtu tfrNMmimKK2vMwzt1X8s6rxN1IIbjdMMHy5C7vWZhMIN4YhD+/g1u6YQ8m1ZOtyknHH2 N7qczbjHnKkk2Hvp48XiKlC3NQKdaIbXpzfaWccSYJkitYEGpKXgFE6AwDVDqyb/TJ0y TNTyq4f771ACTIM1dpr8wPPo9lPsXUFIpMC9kEEBJfXE19KQLQKrXdpVoaPbtoKpArfN IMeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=5gH/4PrYLOzeLRir1stkdmB8+YtWiFjfXTqEr46kzrw=; b=MA8zuo8ecACnwWoPXITdzueuckPDdXwaz8KdQCEjp/lc0yrkk8JU47RrWPl2/ad5ct mUaA6DF0q9waYjKiObSZpKaBM7AvTs8ayXoGgrQpcU5Au804Pr8wi2SjBAz5TARYOQOC xIObufOsiSHQi+7/AUp2kOC6bWHJghHLOVaCjy8LhpLEww9c5ttbAY1drdrTVkUTtPAG X0gOBfQzGC5pA1ci4QNQlh9BwF2OvQSZoqesDSDSXuHltrj/Fg1wqE/8LNEe+0iAmMB4 2A/bnhNQ2m4jdpQnqfWiJhudcwFnmCEvmYYpdzGOTbOu4QMvJ14tUv175hwFit5SrE+A yfcg== X-Gm-Message-State: AKaTC00Zc9+IqXclTxGL2TYmZzyzh7ikKurC3ipil4qJkY6inbVHRFOZU7u+nppVPrvG+pyVHtn6FHO7a1G/XmW4 X-Received: by 10.194.149.143 with SMTP id ua15mr2540317wjb.48.1479991602145; Thu, 24 Nov 2016 04:46:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.21 with HTTP; Thu, 24 Nov 2016 04:46:11 -0800 (PST) In-Reply-To: <147999083781.2554.8110233591871811354.idtracker@ietfa.amsl.com> References: <147999083781.2554.8110233591871811354.idtracker@ietfa.amsl.com> From: Eran Messeri Date: Thu, 24 Nov 2016 12:46:11 +0000 Message-ID: To: "trans@ietf.org" Content-Type: multipart/mixed; boundary=089e0122897cb872ed05420b6500 Archived-At: Subject: Re: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-21.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 12:46:46 -0000 --089e0122897cb872ed05420b6500 Content-Type: multipart/alternative; boundary=089e0122897cb872e705420b65fe --089e0122897cb872e705420b65fe Content-Type: text/plain; charset=UTF-8 The changes from draft 20: * Relaxation of MUST to SHOULD in section 5.1. * Removal of the optional APIs. Diff file attached. On Thu, Nov 24, 2016 at 12:33 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Public Notary Transparency of the IETF. > > Title : Certificate Transparency > Authors : Ben Laurie > Adam Langley > Emilia Kasper > Eran Messeri > Rob Stradling > Filename : draft-ietf-trans-rfc6962-bis-21.txt > Pages : 50 > Date : 2016-11-24 > > Abstract: > This document describes a protocol for publicly logging the existence > of Transport Layer Security (TLS) server certificates as they are > issued or observed, in a manner that allows anyone to audit > certification authority (CA) activity and notice the issuance of > suspect certificates as well as to audit the certificate logs > themselves. The intent is that eventually clients would refuse to > honor certificates that do not appear in a log, effectively forcing > CAs to add all issued certificates to the logs. > > Logs are network services that implement the protocol operations for > submissions and queries that are defined in this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-21 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-21 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --089e0122897cb872e705420b65fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The changes from draft 20:
* Relaxation of MUST to SHO= ULD in section 5.1.
* Removal of the optional APIs.
Diff file attached.

<= div class=3D"gmail_quote">On Thu, Nov 24, 2016 at 12:33 PM, <inter= net-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Public Notary Transparency=C2=A0 of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Certificate Transparency
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Ben = Laurie
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Adam Langley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Emilia Kasper
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Eran Messeri
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Rob Stradling
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-trans-rfc6962-bis-21.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 50
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-11-24

Abstract:
=C2=A0 =C2=A0This document describes a protocol for publicly logging the ex= istence
=C2=A0 =C2=A0of Transport Layer Security (TLS) server certificates as they = are
=C2=A0 =C2=A0issued or observed, in a manner that allows anyone to audit =C2=A0 =C2=A0certification authority (CA) activity and notice the issuance = of
=C2=A0 =C2=A0suspect certificates as well as to audit the certificate logs<= br> =C2=A0 =C2=A0themselves.=C2=A0 The intent is that eventually clients would = refuse to
=C2=A0 =C2=A0honor certificates that do not appear in a log, effectively fo= rcing
=C2=A0 =C2=A0CAs to add all issued certificates to the logs.

=C2=A0 =C2=A0Logs are network services that implement the protocol operatio= ns for
=C2=A0 =C2=A0submissions and queries that are defined in this document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-trans-rfc6962-bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ie= tf-trans-rfc6962-bis-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trans-rfc6962-bis-21


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--089e0122897cb872e705420b65fe-- --089e0122897cb872ed05420b6500 Content-Type: text/plain; charset=US-ASCII; name="draft_20_21_diff.txt" Content-Disposition: attachment; filename="draft_20_21_diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ivwcrc4n0 ZGlmZiAtLWdpdCBhL2RyYWZ0LWlldGYtdHJhbnMtcmZjNjk2Mi1iaXMubWQgYi9kcmFmdC1pZXRm LXRyYW5zLXJmYzY5NjItYmlzLm1kCmluZGV4IDEzYzg5YTAuLjU3MGQ3YzYgMTAwNjQ0Ci0tLSBh L2RyYWZ0LWlldGYtdHJhbnMtcmZjNjk2Mi1iaXMubWQKKysrIGIvZHJhZnQtaWV0Zi10cmFucy1y ZmM2OTYyLWJpcy5tZApAQCAtMSw2ICsxLDYgQEAKIC0tLQogdGl0bGU6ICJDZXJ0aWZpY2F0ZSBU cmFuc3BhcmVuY3kiCi1kb2NuYW1lOiBkcmFmdC1pZXRmLXRyYW5zLXJmYzY5NjItYmlzLTIwCitk b2NuYW1lOiBkcmFmdC1pZXRmLXRyYW5zLXJmYzY5NjItYmlzLTIxCiBjYXRlZ29yeTogInN0ZCIK IAogaXByOiAidHJ1c3QyMDA5MDIiCkBAIC01ODAsMTIgKzU4MCwxNiBAQCB0aGUgbG9nLgogCiBM b2dzIE1VU1QgdmVyaWZ5IHRoYXQgZWFjaCBzdWJtaXR0ZWQgY2VydGlmaWNhdGUgb3IgcHJlY2Vy dGlmaWNhdGUgaGFzIGEgdmFsaWQKIHNpZ25hdHVyZSBjaGFpbiB0byBhbiBhY2NlcHRlZCB0cnVz dCBhbmNob3IsIHVzaW5nIHRoZSBjaGFpbiBvZiBpbnRlcm1lZGlhdGUgQ0EKLWNlcnRpZmljYXRl cyBwcm92aWRlZCBieSB0aGUgc3VibWl0dGVyLiBMb2dzIE1VU1QgYWNjZXB0IGNlcnRpZmljYXRl cyBhbmQKK2NlcnRpZmljYXRlcyBwcm92aWRlZCBieSB0aGUgc3VibWl0dGVyLiBMb2dzIFNIT1VM RCBhY2NlcHQgY2VydGlmaWNhdGVzIGFuZAogcHJlY2VydGlmaWNhdGVzIHRoYXQgYXJlIGZ1bGx5 IHZhbGlkIGFjY29yZGluZyB0byBSRkMgNTI4MCBbUkZDNTI4MF0KLXZlcmlmaWNhdGlvbiBydWxl cyBhbmQgYXJlIHN1Ym1pdHRlZCB3aXRoIHN1Y2ggYSBjaGFpbi4gTG9ncyBNQVkgYWNjZXB0Ci1j ZXJ0aWZpY2F0ZXMgYW5kIHByZWNlcnRpZmljYXRlcyB0aGF0IGhhdmUgZXhwaXJlZCwgYXJlIG5v dCB5ZXQgdmFsaWQsIGhhdmUgYmVlbgotcmV2b2tlZCwgb3IgYXJlIG90aGVyd2lzZSBub3QgZnVs bHkgdmFsaWQgYWNjb3JkaW5nIHRvIFJGQyA1MjgwIHZlcmlmaWNhdGlvbgotcnVsZXMgaW4gb3Jk ZXIgdG8gYWNjb21tb2RhdGUgcXVpcmtzIG9mIENBIGNlcnRpZmljYXRlLWlzc3Vpbmcgc29mdHdh cmUuCit2ZXJpZmljYXRpb24gcnVsZXMgYW5kIGFyZSBzdWJtaXR0ZWQgd2l0aCBzdWNoIGEgY2hh aW4gKEEgbG9nIG1heSBkZWNpZGUsIGZvcgorZXhhbXBsZSwgdG8gdGVtcG9yYXJpbHkgcmVqZWN0 IHZhbGlkIHN1Ym1pc3Npb25zIHRvIHByb3RlY3QgaXRzZWxmIGFnYWluc3QKK2RlbmlhbC1vZi1z ZXJ2aWNlIGF0dGFja3MpLgorCitMb2dzIE1BWSBhY2NlcHQgY2VydGlmaWNhdGVzIGFuZCBwcmVj ZXJ0aWZpY2F0ZXMgdGhhdCBoYXZlIGV4cGlyZWQsIGFyZSBub3QgeWV0Cit2YWxpZCwgaGF2ZSBi ZWVuIHJldm9rZWQsIG9yIGFyZSBvdGhlcndpc2Ugbm90IGZ1bGx5IHZhbGlkIGFjY29yZGluZyB0 byBSRkMKKzUyODAgdmVyaWZpY2F0aW9uIHJ1bGVzIGluIG9yZGVyIHRvIGFjY29tbW9kYXRlIHF1 aXJrcyBvZiBDQQorY2VydGlmaWNhdGUtaXNzdWluZyBzb2Z0d2FyZS4KIEhvd2V2ZXIsIGxvZ3Mg TVVTVCByZWplY3Qgc3VibWlzc2lvbnMgd2l0aG91dCBhIHZhbGlkIHNpZ25hdHVyZSBjaGFpbiB0 byBhbgogYWNjZXB0ZWQgdHJ1c3QgYW5jaG9yLiBMb2dzIE1VU1QgYWxzbyByZWplY3QgcHJlY2Vy dGlmaWNhdGVzIHRoYXQgZG8gbm90IGNvbmZvcm0KIHRvIHRoZSByZXF1aXJlbWVudHMgaW4ge3tw cmVjZXJ0aWZpY2F0ZXN9fS4KQEAgLTEzMzksNjkgKzEzNDMsNiBAQCBPdXRwdXRzOgogICAgIHRo ZSBtYXhpbXVtIG51bWJlciBvZiBjZXJ0aWZpY2F0ZXMgaW4gdGhlIGNoYWluLCBpbiBkZWNpbWFs LiBJZiB0aGVyZSBpcyBubwogICAgIGxpbWl0LCB0aGlzIGlzIG9taXR0ZWQuCiAKLSMgT3B0aW9u YWwgQ2xpZW50IE1lc3NhZ2VzCi0KLUxvZ3MgTUFZIGltcGxlbWVudCB0aGVzZSBtZXNzYWdlcy4g VGhleSBhcmUgbm90IHJlcXVpcmVkIGZvciBjb3JyZWN0IG9wZXJhdGlvbgotb2YgbG9ncyBvciB0 aGVpciBjbGllbnRzLCBidXQgbWF5IGJlIGNvbnZlbmllbnQgaW4gc29tZSBjaXJjdW1zdGFuY2Vz LgotCi0jIyBHZXQgRW50cnkgTnVtYmVyIGZvciBTQ1QKLQotR0VUIGh0dHBzOi8vXDxsb2cgc2Vy dmVyPi9jdC92Mi9nZXQtZW50cnktZm9yLXNjdAotCi1JbnB1dHM6Ci0KLTogc2N0OgotICA6IEEg YmFzZTY0IGVuY29kZWQgYFRyYW5zSXRlbWAgb2YgdHlwZSBgeDUwOV9zY3RfdjJgIG9yIGBwcmVj ZXJ0X3NjdF92MmAKLSAgICBzaWduZWQgYnkgdGhpcyBsb2cuCi0KLU91dHB1dHM6Ci0KLTogZW50 cnk6Ci0gIDogMC1iYXNlZCBpbmRleCBvZiB0aGUgbG9nIGVudHJ5IGNvcnJlc3BvbmRpbmcgdG8g dGhlIHN1cHBsaWVkIFNDVC4KLQotRXJyb3IgY29kZXM6Ci0KLXwtLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS18Ci18IEVycm9yIENvZGUgICAgfCBNZWFuaW5nICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAotfC0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLXwKLXwgYmFkIHNpZ25hdHVyZSB8IGBzY3RgIGlzIG5vdCBzaWduZWQgYnkg dGhpcyBsb2cuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Ci18IG5vdCBmb3Vu ZCAgICAgfCBgc2N0YCBkb2VzIG5vdCBjb3JyZXNwb25kIHRvIGFuIGVudHJ5IHRoYXQgaXMgY3Vy cmVudGx5IGF2YWlsYWJsZS4gfAotfC0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKLQotTm90 ZSB0aGF0IGFueSBTQ1Qgc2lnbmVkIGJ5IGEgbG9nIE1VU1QgaGF2ZSBhIGNvcnJlc3BvbmRpbmcg ZW50cnkgaW4gdGhlIGxvZywKLWJ1dCBpdCBtYXkgbm90IGJlIHJldHJpZXZhYmxlIHVudGlsIHRo ZSBNTUQgaGFzIHBhc3NlZCBzaW5jZSB0aGUgU0NUIHdhcyBpc3N1ZWQuCi0KLSMjIEdldCBFbnRy eSBOdW1iZXJzIGZvciBUQlNDZXJ0aWZpY2F0ZQotCi1HRVQgaHR0cHM6Ly9cPGxvZyBzZXJ2ZXI+ L2N0L3YyL2dldC1lbnRyeS1mb3ItdGJzY2VydGlmaWNhdGUKLQotSW5wdXRzOgotCi06IGhhc2g6 Ci0gIDogQSBiYXNlNjQgZW5jb2RlZCBIQVNIIG9mIGEgYFRCU0NlcnRpZmljYXRlYCBmb3Igd2hp Y2ggdGhlIGxvZyBoYXMgcHJldmlvdXNseQotICAgIGlzc3VlZCBhbiBTQ1QuIChOb3RlIHRoYXQg YSBwcmVjZXJ0aWZpY2F0ZSdzIFRCU0NlcnRpZmljYXRlIGlzIHJlY29uc3RydWN0ZWQKLSAgICBm cm9tIHRoZSBjb3JyZXNwb25kaW5nIGNlcnRpZmljYXRlIGFzIGRlc2NyaWJlZCBpbgotICAgIHt7 cmVjb25zdHJ1Y3RpbmdfdGJzY2VydGlmaWNhdGV9fSkuCi0KLU91dHB1dHM6Ci0KLTogZW50cmll czoKLSAgOiBBbiBhcnJheSBvZiAwLWJhc2VkIGluZGljZXMgb2YgbG9nIGVudHJpZXMgY29ycmVz cG9uZGluZyB0byB0aGUgc3VwcGxpZWQKLSAgICBIQVNILgotCi1FcnJvciBjb2RlczoKLQotfC0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKLXwgRXJyb3IgQ29kZSB8IE1lYW5pbmcgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Ci18LS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tfAotfCBiYWQgaGFzaCAgIHwgYGhhc2hgIGlzIG5vdCB0aGUg cmlnaHQgc2l6ZSBvciBmb3JtYXQuICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKLXwgbm90 IGZvdW5kICB8IGBzY3RgIGRvZXMgbm90IGNvcnJlc3BvbmQgdG8gYW4gZW50cnkgdGhhdCBpcyBj dXJyZW50bHkgYXZhaWxhYmxlLiB8Ci18LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAotCi1Ob3Rl IHRoYXQgaXQgaXMgcG9zc2libGUgZm9yIGEgY2VydGlmaWNhdGUgdG8gYmUgbG9nZ2VkIG1vcmUg dGhhbiBvbmNlLiBJZiB0aGF0Ci1pcyB0aGUgY2FzZSwgdGhlIGxvZyBNQVkgcmV0dXJuIG1vcmUg dGhhbiBvbmUgZW50cnkgaW5kZXguIElmIHRoZSBjZXJ0aWZpY2F0ZSBpcwotcHJlc2VudCBpbiB0 aGUgbG9nLCB0aGVuIHRoZSBsb2cgTVVTVCByZXR1cm4gYXQgbGVhc3Qgb25lIGVudHJ5IGluZGV4 LgotCiAjIFRMUyBTZXJ2ZXJzICAgIHsjdGxzX3NlcnZlcnN9CiAKIFRMUyBzZXJ2ZXJzIE1VU1Qg dXNlIGF0IGxlYXN0IG9uZSBvZiB0aGUgdGhyZWUgbWVjaGFuaXNtcyBsaXN0ZWQgYmVsb3cgdG8K --089e0122897cb872ed05420b6500-- From nobody Thu Nov 24 11:54:32 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F35129B2D for ; Thu, 24 Nov 2016 11:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqs4jMG047wH for ; Thu, 24 Nov 2016 11:54:29 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B28129AFB for ; Thu, 24 Nov 2016 11:54:29 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tPqfV6whFzCWR; Thu, 24 Nov 2016 20:54:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1480017266; bh=hdw+j6h8Vb7FpGwT8iesgR1IM3sL0lX+MD1M6fRgRSc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=tDe/ytO1oNsZq+wK0YGOHuHyXjaGTaKa34KX6UwFGlLyRL6L3jiSndUaRXo9yBtnu oCaDNfR2vAnhGRCP3Of2E9llJBqyXnpUocD800kNON1hi3aSQL30n1vzmQEY5I7yrJ 2gx1u98XkRwaKdUiHIeyZDjd5pz419JaXRXyZlcE= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id bZOoWJA43kk9; Thu, 24 Nov 2016 20:54:25 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 24 Nov 2016 20:54:25 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D17E312EAE1; Thu, 24 Nov 2016 14:54:23 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D17E312EAE1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BD68340D3586; Thu, 24 Nov 2016 14:54:23 -0500 (EST) Date: Thu, 24 Nov 2016 14:54:23 -0500 (EST) From: Paul Wouters To: Eran Messeri In-Reply-To: Message-ID: References: <147999083781.2554.8110233591871811354.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-21.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 19:54:30 -0000 On Thu, 24 Nov 2016, Eran Messeri wrote: > The changes from draft 20:* Relaxation of MUST to SHOULD in section 5.1. > * Removal of the optional APIs. Thanks Eran! > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-21 This looks good to me and seems to match what people thought the text should be during our meeting at IETF#97. If anyone thinks the new text in Section 5.1 is incorrect or incomplete, please let us know as soon as possible. Since the diff looks large due to the section renumbering, the actual MUST -> SHOULD change is: - Logs MUST accept certificates and precertificates that are fully + Logs SHOULD accept certificates and precertificates that are fully valid according to RFC 5280 [RFC5280] verification rules and are submitted with such a chain. + (A log may decide, for example, to temporarily reject valid + submissions to protect itself against denial-of-service attacks). Thanks, Paul From nobody Thu Nov 24 14:30:11 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099E6129DD7 for ; Thu, 24 Nov 2016 14:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmYXHb6BCaa0 for ; Thu, 24 Nov 2016 14:30:08 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDDC129DDA for ; Thu, 24 Nov 2016 14:30:07 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id v84so63715571oie.3 for ; Thu, 24 Nov 2016 14:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=YiR7QH/JOsK4Q9g49oAIdRyqT7DQFmV0qI1c5bWoEGI=; b=SF1m0oI8nEsm3QjU0lbggCOGWpalhl7e4zbl1ZT0uP5KTZKq2RAU/PPsbxW5aP8wkO HTYLKnnKo6mYoUAC3qMeUYlJVcoF7sbN+io0JjZXz1prMir9z+YKMEC61aXBl/ZryOmk amMamX/jYUEgTq2oatTFNTA6cQm2EThxOghUA1BLNMqXA2lWgzgjkaVQEE9WopLhneeU TgP65aEQlkcxLPG72wBQemKw5JM9uIkA41nVs1HaRq+VpC1HLOsajahfs9byDfYFMiAm zlCwuikZNceWusL7nMk1wbAAvmcesRyyX2CNM/q8DZX31ZLY3R9raJ/IKK++5Aa0UWK8 OFoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YiR7QH/JOsK4Q9g49oAIdRyqT7DQFmV0qI1c5bWoEGI=; b=gpT9svyHQQYRSnE/p/KV0tjJiCalw29ToQvBan5jDfhTQ6+FGzrJp6+zkc9F0Aa8wW X92AGxgmFlQDmFEUMXLVFEiEKYbTZoNB4Q/hFGl/Htf0uz2mAT7HZp1aSjNPR7eKikkv 512hyiTc9/cnBWt04eCjZUQ0ZRCHgNpnnRyjFA7AmNpe5xFCvZooKpFOX6PXq0wnjRe+ s4LPqdBrHfJjsqAQIo6YtAEiY3mlVy1IutI5HWcCc2esYg4pvmXF/frR4GB2aeYPws9u YV0D8OeIZFmyQO2aG3+K1s5zVNhXLRrLYBf4+X4vSZ83tEpgeMKdL3jix+sAnXABMXCP /MYg== X-Gm-Message-State: AKaTC00H3tGgNWs72efl4NVVdJSY56kqDKK8OgVBa6geUsNyzaGkvdYW/rZ05T6pgNDxU1XLHfWhZkGFyS7pUQ== X-Received: by 10.202.79.203 with SMTP id d194mr2493927oib.46.1480026607001; Thu, 24 Nov 2016 14:30:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.76.87 with HTTP; Thu, 24 Nov 2016 14:30:06 -0800 (PST) From: Peter Bowen Date: Thu, 24 Nov 2016 14:30:06 -0800 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Trans] Adoption of draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 22:30:10 -0000 I've been thinking more about [draft-strad-trans-redaction-00](https://tools.ietf.org/html/draft-strad-trans-redaction-00) and I am now leaning against adoption by the WG. This working group is about transparency not translucency. The goals stated in [What is Certificate Transparency?](http://www.certificate-transparency.org/what-is-ct) have not changed since first published in 2013 (according to the WayBackMachine). They are: * Make it impossible (or at least very difficult) for a CA to issue a SSL certificate for a domain without the certificate being visible to the owner of that domain. * Provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued. * Protect users (as much as possible) from being duped by certificates that were mistakenly or maliciously issued. I believe that a log inclusion proof should provide assurance that these goals are met. It should mean that the certificate was included in the log intact and that it is available from the log for review. This is important when looking at things like NSRequiresCertificateTransparency in Apple App Transport Security and the [Expect-CT draft](https://tools.ietf.org/html/draft-stark-expect-ct). These allow a server or application owner to specify that CT is required for connections. One can also imagine a future draft to update the [TLSA RFC](https://tools.ietf.org/html/rfc6698) to add CT as a flag in certificate usage so that a site could declare via DNS to only trust a certificate that has an inclusion proof (or SCT). Adding some "translucent" option means that these become far less valuable policy directives. I think the primary driver for the redaction draft has been the fact that one major web browser vendor has suggested that they may set a policy to require CT by default. The IETF has been very successful by avoiding policy and focusing on technical protocols. For example, the DNS RFCs discuss how DNS works not how it is deployed. Even within the ICANN/PTI rooted DNS, there are policy differences. The dk TLD requires that all DNS servers for registered domains under dk be publicly accessible and meet certain technical requirements while the xyz domain accepts name servers that have IP addresses in address blocks that are not global (as defined in [RFC 6890](https://tools.ietf.org/html/rfc6890), e.g. 10.0.0.0/8). It is also possible to use the DNS protocol on standalone networks not interconnected to other networks. The same should be true for CT -- the protocol and expectations should be well defined and usable in a variety of ways and policy should be separate from the RFCs. To be clear, I do not believe that lack of support for adoption of the redaction draft should imply support for a policy of requiring CT by default. That is a different discussion for a different list. The question at hand is watering down CT and that is something I do not think should happen. Thanks, Peter From nobody Fri Nov 25 08:11:55 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCE1127A91 for ; Fri, 25 Nov 2016 08:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2hwbsjkskv3 for ; Fri, 25 Nov 2016 08:11:52 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA12127077 for ; Fri, 25 Nov 2016 08:11:51 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tQLg93HgZz9dJ; Fri, 25 Nov 2016 17:11:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1480090309; bh=NtUitW6fJDAbm32ykc8TFDbXZhA2xwy1Ah0sl9QNm64=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=YgcscaZqLI0o/fwLrS31s2QTucFui0HID3lQ39/7JkwFBvyRmwQoCwORK269LsYxl CauNBe9xCdCZDMioQheaYMqFI31b5B8CZbCGOaT3YiKpWK8dp1HbQbqoq7ZcSLHcke 87oa05gCMM38uYhRsVftOEVtO+lrO5PR5g17R17c= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yzxSBaWvk40h; Fri, 25 Nov 2016 17:11:48 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 25 Nov 2016 17:11:47 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 03FF9934; Fri, 25 Nov 2016 11:11:45 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 03FF9934 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D840540E06BA; Fri, 25 Nov 2016 11:11:45 -0500 (EST) Date: Fri, 25 Nov 2016 11:11:45 -0500 (EST) From: Paul Wouters To: Peter Bowen In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Adoption of draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 16:11:53 -0000 On Thu, 24 Nov 2016, Peter Bowen wrote: [ chair hat on ] > I've been thinking more about > [draft-strad-trans-redaction-00](https://tools.ietf.org/html/draft-strad-trans-redaction-00) > and I am now leaning against adoption by the WG. This working group > is about transparency not translucency. The goals stated in [What is > Certificate Transparency?](http://www.certificate-transparency.org/what-is-ct) > have not changed since first published in 2013 (according to the > WayBackMachine). They are: Note that the website you quote is the Google transparency project page. It is not the IETF Trans WG charter, which you can find at: https://datatracker.ietf.org/wg/trans/charter/ It includes: While the privacy issues related to use of RFC6962 for public web sites are minimal, the working group will consider privacy as it might impact on uses of CT e.g. within enterprises or for other uses of logs If redaction support is something that can influence whether or not CT gets deployed, it is definitly within the charter (or a charter update) to work on redaction. > I think the primary driver for the redaction draft has been the fact > that one major web browser vendor has suggested that they may set a > policy to require CT by default. The IETF has been very successful by > avoiding policy and focusing on technical protocols. I would argue that facilitating certain properties like redaction in the standard would be the way to guarantee different logs can apply different local privacy policies to their log operation. With redaction support logs can choose to support redaction or not. With no redaction in the specification, logs cannot make that choice. > The question at hand is watering down CT and that is something I do not > think should happen. That's certainly in scope to discuss on this list during the adoption call. Paul From nobody Fri Nov 25 08:27:51 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997AC1294EE for ; Fri, 25 Nov 2016 08:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9DDF8EJ1rzY for ; Fri, 25 Nov 2016 08:27:48 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6D32E1294E4 for ; Fri, 25 Nov 2016 08:27:48 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9D22D43340F; Fri, 25 Nov 2016 16:27:47 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 86F4B433404; Fri, 25 Nov 2016 16:27:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480091267; bh=tEM2eHgNfxtVwITyG6IQXa1TlvhbuyUyHmc9HNppxDI=; l=202; h=From:To:CC:Date:References:In-Reply-To:From; b=rbTiMuNvxzs64XfEVWw2uRDTN+WHKtsncQgGxK7rc6g0VbJe8QcK5zP9pOdL4ejFV +p1z5D3bGHEKil3naoidUqu8sUOrfFTQJ9MG3k3MLCJbSy7sq5NZCmIo2lfZmca+Cf ay+kD2O5nytWi+0Vvtg2/CtOuQRoPlqpnKenU90E= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 780D21FC8D; Fri, 25 Nov 2016 16:27:47 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 25 Nov 2016 11:27:46 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 25 Nov 2016 11:27:47 -0500 From: "Salz, Rich" To: Paul Wouters , Peter Bowen Thread-Topic: [Trans] Adoption of draft-strad-trans-redaction-00 Thread-Index: AQHSRqJTt5z4dzWcTUChTv31eeJyQ6DqM8iA//+weYA= Date: Fri, 25 Nov 2016 16:27:46 +0000 Message-ID: <691d46380fe5461f848ad905822edc5e@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.226] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Adoption of draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 16:27:49 -0000 I think Peter is mixing up the Chrome/Google project and the IETF working g= roup. -- =20 Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz From nobody Fri Nov 25 08:57:22 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5511295C2 for ; Fri, 25 Nov 2016 08:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm21nld5bscS for ; Fri, 25 Nov 2016 08:57:19 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29AB0129461 for ; Fri, 25 Nov 2016 08:57:19 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id v84so86937885oie.3 for ; Fri, 25 Nov 2016 08:57:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8b7vq8K5nbE9onT3VUSVZkRwEsoilWCGz3PacUqyKYs=; b=eD4aFfmXxXLmDAAuuk5s93Glerlk1zGz0dcdGFQa1ybUzw4gQEw7UurK4Wvbd7ZP/c Ak0QrMYEd2Mfd46eXsvgFv9i6i/MQZal/L1LFE2+hZeVLAK8OdvzLF2ehvFxkFeSBMEW yoM5KPLIL+JxOsl5on1NLIGVxkQhDDXrMeasY1qcq5M0eJbsFe0NMWJcLy+FMDL5lsL1 JPjjwlzFae5F+Zl4LFAqNLfrWCqnU2i1HWFT2kBoWt3AW/CB5AZVUItkJpTg6Y6wyFjB s2H5qgodWFVmEI2TqymNSYBIJiFUW4NbMuN9Xh8K/5dLKFZ49vg7ZwXo3Czr8J59XBit 050g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8b7vq8K5nbE9onT3VUSVZkRwEsoilWCGz3PacUqyKYs=; b=gO8NQgYYMf9lODTsOiiOH68vC/C/K3uPrD+6GnlvU6oIvgB/rffBhwPeg+VI/92TBn GW9DN1VCSh6JkQTlcFr0bfz+5uBavAOjlCLtxb+2pHjc0+OGxZGx7E2XbV/gx/mTsQml M0KGcAKfRZCjEUf5GNuaMnV3PwQ31wHXooYoLbryl1VmSM5RzbdZguK0ZlO0JxtqKJVD QNvVjwccZSGOYLyvbEo/2ipUA+lbaKclYe6uKV1Vt7kFBuBvUMxNBJu/vUAdgVZ4iLFw UwBG+GNkDf4cwRXZnTjVM4OXmOe36YjBz7zBw4gMhAABCgXWw4iIeTV1aewwIaPiCj/k garw== X-Gm-Message-State: AKaTC01aX37wnQepwhj+zvTlRbJt4yXR7YBGUxoxWbdWaNbx8XeTjFm61WEsoJxkpvxetm/dYGmwSmxGZuhhVA== X-Received: by 10.157.44.38 with SMTP id f35mr5110186otb.192.1480093038359; Fri, 25 Nov 2016 08:57:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.76.87 with HTTP; Fri, 25 Nov 2016 08:57:17 -0800 (PST) In-Reply-To: References: From: Peter Bowen Date: Fri, 25 Nov 2016 08:57:17 -0800 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Adoption of draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 16:57:21 -0000 On Fri, Nov 25, 2016 at 8:11 AM, Paul Wouters wrote: > On Thu, 24 Nov 2016, Peter Bowen wrote: > > [ chair hat on ] > >> I've been thinking more about >> >> [draft-strad-trans-redaction-00](https://tools.ietf.org/html/draft-strad-trans-redaction-00) >> and I am now leaning against adoption by the WG. This working group >> is about transparency not translucency. The goals stated in [What is >> Certificate >> Transparency?](http://www.certificate-transparency.org/what-is-ct) >> have not changed since first published in 2013 (according to the >> WayBackMachine). They are: > > > Note that the website you quote is the Google transparency project page. > It is not the IETF Trans WG charter, which you can find at: > > https://datatracker.ietf.org/wg/trans/charter/ You are correct, I cited the Google (6962) project, not the IETF WG charter. That being said, I don't think that the underlying concern is invalid. > It includes: > > While the privacy issues related to use of RFC6962 for public > web sites are minimal, the working group will consider privacy > as it might impact on uses of CT e.g. within enterprises or > for other uses of logs > > If redaction support is something that can influence whether or not CT > gets deployed, it is definitly within the charter (or a charter update) > to work on redaction. Lack of redaction has not prevented 6962 from being widely deployed. There are more than a dozen logs in operation which contain over 24.5 million distinct unexpired certificates. 6962-bis builds on 6962 adding lots of positive features based on experience with 6962 and I'm sure most logs operators will stand up new logs following the standards track RFC when published. Privacy is something that needs to be considered, but that does not mean redaction is the right solution. I would prefer that CT offer a strong guarantee of transparency even if it means not logging every certificate. 6962bis offers an option for privacy -- logging name constrained CA certificates. >> I think the primary driver for the redaction draft has been the fact >> that one major web browser vendor has suggested that they may set a >> policy to require CT by default. The IETF has been very successful by >> avoiding policy and focusing on technical protocols. > > > I would argue that facilitating certain properties like redaction in > the standard would be the way to guarantee different logs can apply > different local privacy policies to their log operation. With redaction > support logs can choose to support redaction or not. With no redaction > in the specification, logs cannot make that choice. This means different logs have different properties which runs contrary to prior discussions on similar topics. How is allowing logging "redacted" certificates different from allowing a log to accept certificates that it finds valuable even if they don't chain to a known root? >> The question at hand is watering down CT and that is something I do not >> think should happen. > > That's certainly in scope to discuss on this list during the adoption > call. > > Paul Thanks, Peter From nobody Fri Nov 25 15:53:22 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237FF1294B2 for ; Fri, 25 Nov 2016 15:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poJMTIvH6_Ol for ; Fri, 25 Nov 2016 15:53:20 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 097AD127058 for ; Fri, 25 Nov 2016 15:53:19 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 70CB4433423; Fri, 25 Nov 2016 23:53:19 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 5ACC2433421; Fri, 25 Nov 2016 23:53:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480117999; bh=qRBO3v0xUS3VpNXlTGTlsCn7a4dSuPZ0vPhXiVkPWnE=; l=1162; h=From:To:CC:Date:References:In-Reply-To:From; b=ucyzjonvmg7qJNBkfcNTb+K+VFlhjbJbRyQ+4pUt4eQXSgvPVUKwGO1DraCOmGSZ5 T4H0m7XCO3EajPwWMvt7b6D0xnAVhNypVb2JUd9HvvYrVg+jCgpp7mML/6RT56dTQV RNBacvxCONltLSmANZLwPVbtWMA0/kEAHn5FINGw= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 578711FC94; Fri, 25 Nov 2016 23:53:19 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 25 Nov 2016 18:53:18 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 25 Nov 2016 18:53:19 -0500 From: "Salz, Rich" To: Peter Bowen , Paul Wouters Thread-Topic: [Trans] Adoption of draft-strad-trans-redaction-00 Thread-Index: AQHSRqJTt5z4dzWcTUChTv31eeJyQ6DqM8iAgAAMuYCAAB824A== Date: Fri, 25 Nov 2016 23:53:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.226] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Adoption of draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 23:53:21 -0000 > Lack of redaction has not prevented 6962 from being widely deployed. > There are more than a dozen logs in operation which contain over 24.5 mil= lion > distinct unexpired certificates. We don't know that. What we do know is that the world's most-used browser = is requiring it for some, soon all, certificates. I could claim that Chrom= e is the only reason why 6962 is deployed. And 12 logs is still one less t= han the number of root zone DNS servers :) =20 > Privacy is something that needs to be considered, but that does not mean > redaction is the right solution. I would prefer that CT offer a strong > guarantee of transparency even if it means not logging every certificate. > 6962bis offers an option for privacy -- logging name constrained CA > certificates. And how much does it cost, on average, to get a name-constrained subCA from= one of the trusted roots? (I have no idea; that's an honest question.) B= ut should privacy only be limited to those who can afford to get one, or fo= rced to buy a wildcard, or similar? The IETF considers privacy to be very important. Certificates should not b= e exempt from that. From nobody Fri Nov 25 16:11:09 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1481293DC for ; Fri, 25 Nov 2016 16:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLTguenlFM93 for ; Fri, 25 Nov 2016 16:11:05 -0800 (PST) Received: from mail.hezmatt.org (minotaur.hezmatt.org [IPv6:2a01:4f8:121:3431:e2e4:22bb:25f5:6cad]) by ietfa.amsl.com (Postfix) with ESMTP id 74DAE1294BA for ; Fri, 25 Nov 2016 16:11:05 -0800 (PST) Received: from mistress.home.hezmatt.org (2001-44b8-510e-8600-fc3a-8e1d-9a41-f8fa.static.ipv6.internode.on.net [IPv6:2001:44b8:510e:8600:fc3a:8e1d:9a41:f8fa]) by mail.hezmatt.org (Postfix) with ESMTPSA id B8CAAA553D for ; Sat, 26 Nov 2016 00:11:03 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 7A0589FF59; Sat, 26 Nov 2016 11:10:58 +1100 (AEDT) Date: Sat, 26 Nov 2016 11:10:58 +1100 From: Matt Palmer To: trans@ietf.org Message-ID: <20161126001058.GX11153@hezmatt.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Adoption of draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 00:11:07 -0000 On Fri, Nov 25, 2016 at 11:11:45AM -0500, Paul Wouters wrote: > I would argue that facilitating certain properties like redaction in > the standard would be the way to guarantee different logs can apply > different local privacy policies to their log operation. With redaction > support logs can choose to support redaction or not. With no redaction > in the specification, logs cannot make that choice. Logs don't redact, and they don't choose what to log (other than a few very broad criteria to ensure stability). - Matt From nobody Fri Nov 25 16:12:40 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B40F12946F for ; Fri, 25 Nov 2016 16:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9lho__dgmVh for ; Fri, 25 Nov 2016 16:12:37 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 365161293DC for ; Fri, 25 Nov 2016 16:12:37 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6D7E643342B; Sat, 26 Nov 2016 00:12:36 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5539C433413; Sat, 26 Nov 2016 00:12:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480119156; bh=w7mEkB1OhWc915iHzjLBwFKUsIW+vsW4k/LLFavL5kQ=; l=229; h=From:To:Date:References:In-Reply-To:From; b=Kp5wjlKkQnf+1aJPcmnwzYi6LfRcwJKa6Wtq0YMmzX0yBnHjsn+i+/LpEWP0czV3H rqKQLPbvRcmGDWrwcwLFyB7qGH/wGO/rfynzikGLBtAVAWz7iWcvJSzvsObrbRFSZX ZHMaa1AMxURRfn8EI/Onghd/z8sUqGanOBcX6uVk= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 511821FC8D; Sat, 26 Nov 2016 00:12:36 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 25 Nov 2016 19:12:35 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 25 Nov 2016 19:12:35 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 25 Nov 2016 19:12:36 -0500 From: "Salz, Rich" To: Matt Palmer , "trans@ietf.org" Thread-Topic: [Trans] Adoption of draft-strad-trans-redaction-00 Thread-Index: AQHSRqJTt5z4dzWcTUChTv31eeJyQ6DqM8iAgACF5QD//6x94A== Date: Sat, 26 Nov 2016 00:12:35 +0000 Message-ID: <5f96997baf83451ea0b4706b7cd974f3@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20161126001058.GX11153@hezmatt.org> In-Reply-To: <20161126001058.GX11153@hezmatt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.226] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Adoption of draft-strad-trans-redaction-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 00:12:38 -0000 > Logs don't redact, and they don't choose what to log (other than a few ve= ry > broad criteria to ensure stability). Was it finally settled in -bis that logs cannot take a subset of certs from= the roots they accept?