From nobody Thu Jan 11 15:59:58 2018 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 ACDB41243F6 for ; Thu, 11 Jan 2018 15:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se 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 M1jIjkxSL8tM for ; Thu, 11 Jan 2018 15:59:53 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 33A1412EC69 for ; Thu, 11 Jan 2018 15:59:52 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w0BNxm6j038807 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 12 Jan 2018 00:59:48 +0100 Received: from datan ([185.65.135.179]) (authenticated bits=0) by smtp1.sunet.se (8.15.2/8.14.9) with ESMTPSA id w0BNxiUw004007 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jan 2018 23:59:47 GMT VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1515715187; bh=2KC9au/LQcyRNnoc/xQmsVr76h+yy/InwPSByHWhkhM=; h=From:To:Subject:References:Date:In-Reply-To; b=ROmrORf9/ZHyjrQWvBvxcFE2jegfEs9gF5Mkp4w40TLDnPAIfwKDGNVJ2JtGJpxhQ QESyw/AVoAD/vKHj568td6TjlsirVxgByhaFG6o5/5npNRUwEAgcaKWwKMSijTzDzN udLssZm5ZCsfBUbfeBABnP/oU90b2D2ZzxqT9vDI= From: Linus Nordberg To: Eric Rescorla , trans@ietf.org Organization: Sunet References: Date: Fri, 12 Jan 2018 00:59:40 +0100 In-Reply-To: (Eric Rescorla's message of "Sat, 14 Oct 2017 17:03:36 -0700") Message-ID: <87inc8osk3.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Bayes-Prob: 0.5 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=185.65.135.179; country=SE; latitude=59.3247; longitude=18.0560; http://maps.google.com/maps?q=59.3247,18.0560&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09UVbXM9O - d69d99b81655 - 20180112 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 185.65.135.179 is neither permitted nor denied by domain linus@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=185.65.135.179; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [Trans] AD Review: draft-ietf-trans-gossip-04 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jan 2018 23:59:58 -0000 Hi Ekr, hi group, Most of the issues in the AD review have been addressed in upcoming -05 (see [0] for the current status of the document). Apart from a couple of clarifying questions to Ekr, there are two particular questions we'd like to ask the working group -- please see "WG:" below. [0] https://github.com/ln5/draft-ietf-trans-gossip/ Eric Rescorla wrote Sat, 14 Oct 2017 17:03:36 -0700: > View Inline draft-ietf-trans-gossip.txt:434 > The data sent in the POST is defined in Section 8.1.1. This data > SHOULD be sent in an already-established TLS session. This makes it > hard for an attacker to disrupt SCT Feedback without also disturbing > > See above about the privacy implications of creating a new connection. Ekr: What privacy implications are you refering to here? > View Inline draft-ietf-trans-gossip.txt:673 > validity window not to be personally identifiable data, and STHs > outside this window to be personally identifiable. > > 14 just seems like a random number here. There's nothing that makes these > STHs personally identifiable other than that you told everyone else not to > save after 14, right? The choice of 14 days _was_ arbitrary. However, you can't substitue any number in there for the same result. The other component, besides everyone using the same configuration, is that the timeframe must be _short_ enough that seeing a STH on the tail end of it is not rare. If we had chosen a 720 day window, it would be very rare for a client to have a particular STH on the tail of the window. A client could be fed a 719-day-old STH on a.com, and when they pollinate it on b.com, they can be recognized cross-domain with a much greater chance. We guessed that 14 days was an appropriate number. WG: Should we perform real-world measurements before picking a number for STH freshness or will our guess be good enough for an experimental RFC if we add text along the lines of the above explanation? > View Inline draft-ietf-trans-gossip.txt:804 > proofs from that third party could be considered reasonable from a > privacy perspective. The HTTPS client may also do its own auditing > and might additionally share SCTs and STHs with the trusted party to > > Why would this be the case? Ekr: Are you questioning why it could be considered reasonable to share gossip data with any of the suggested types of third party organisations? Or why an HTTPS client might do auditing? > View Inline draft-ietf-trans-gossip.txt:932 > Unlike SCT Feedback, the STH Pollination mechanism is not hampered if > only a minority of HTTPS servers deploy it. However, it makes an > assumption that an HTTPS client performs Proof Fetching (such as the > > I'm not sure that this is true. Say that only one server deploys it. Maybe > you meant that there is still ecosystem value. Yes. "Ecosystem value" is the only value provided by STH Pollination. > View Inline draft-ietf-trans-gossip.txt:996 > HTTPS clients are afforded the greatest chance of detecting an attack > when they either participate in both SCT Feedback and STH Pollination > > "greatest chance" isn't that encouraging. Please actually quantify this in > some way. Ekr: Do you think that the document is lacking text on _why_ a client has the greatest chance of detecting an attack when $foo? Or are you asking for reasoning about how large the chance of detecting an attack might be? > View Inline draft-ietf-trans-gossip.txt:1283 > from a CT log that it doesn't accept SCTs from. An HTTPS client > SHOULD regularly request an STH from all logs it is willing to > accept, even if it has seen no SCTs from that log. > > Is any HTTPS client actually planning to do this? We have no idea. WG: Do you know of any HTTPS client planning on implementing _any_ of the methods described in this document? From nobody Fri Jan 12 01:01:04 2018 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 D9A8E12DA26 for ; Fri, 12 Jan 2018 01:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se 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 9svPLMabGT2d for ; Fri, 12 Jan 2018 01:00:55 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 E50EE1200C1 for ; Fri, 12 Jan 2018 01:00:54 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w0C90oxj063707 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 12 Jan 2018 10:00:50 +0100 Received: from datan ([185.65.135.179]) (authenticated bits=0) by smtp1.sunet.se (8.15.2/8.14.9) with ESMTPSA id w0C90jUW016786 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jan 2018 09:00:49 GMT VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1515747649; bh=gtByafwcFZa9O0840l1uLUQAOyCht3miCI9wE00Z2q8=; h=From:To:Subject:References:Date:In-Reply-To; b=lZfdl+lrjy3zxeoTHXKIV39oBt62ww/PDc+Weq7S2towykxw3dW3aV6N6zwPCpmr/ 2JJr/Ts0gRGTYuc+dV9eXLbBPf2rawx7QjThdft0DWQT2C1IScaKi0GCNbCISmWoSR tbCgFCrXnT8BjNGNrNZDZ2XYTQl50flc8n9YBHek= From: Linus Nordberg To: Eric Rescorla , trans@ietf.org Organization: Sunet References: <87inc8osk3.fsf@nordberg.se> Date: Fri, 12 Jan 2018 10:00:40 +0100 In-Reply-To: <87inc8osk3.fsf@nordberg.se> (Linus Nordberg's message of "Fri, 12 Jan 2018 00:59:40 +0100") Message-ID: <874lnrpi2v.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Bayes-Prob: 0.9999 (Score 5, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=185.65.135.179; country=SE; latitude=59.3247; longitude=18.0560; http://maps.google.com/maps?q=59.3247,18.0560&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09UVl0OSi - 3490de036195 - 20180112 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 185.65.135.179 is neither permitted nor denied by domain linus@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=185.65.135.179; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [Trans] AD Review: draft-ietf-trans-gossip-04 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jan 2018 09:01:03 -0000 Hi Ekr, hi group, Naturally, I failed at including all our comments and questions in my last email. Let me try again, listing them all, including those in my previous email. Most of the issues in the AD review have been addressed in upcoming -05 (see [0] for the current status of the document). Apart from a couple of clarifying questions to Ekr, there are two particular questions we'd like to ask the working group -- please see "WG:" below. [0] https://github.com/ln5/draft-ietf-trans-gossip/ > View Inline draft-ietf-trans-gossip.txt:413 > Gossip would be performed normally for third party domains only when > the user revisits the first party domain. In lieu of 'double- > > Is this supposed to be the result of following the previous advice to > double-key? Yes. > View Inline draft-ietf-trans-gossip.txt:417 > treats other security mechanisms that can enable tracking (such as > HSTS and HPKP.) > > What is that manner? As far as I can tell, it's "do nothing special" HSTS and HPKP are special, they often have subtly different behavior than other things. For example, they are generally shared from the normal browsing context into a Private Browsing Mode, which is different from nearly every other thing that can enable tracking. We're under the impression that browser makers are keeping an eye out for actual uses of HSTS and HPKP for tracking, and if it becomes a problem, they may close the Private Brrowsing Mode population behavior. > View Inline draft-ietf-trans-gossip.txt:434 > The data sent in the POST is defined in Section 8.1.1. This data > SHOULD be sent in an already-established TLS session. This makes it > hard for an attacker to disrupt SCT Feedback without also disturbing > > See above about the privacy implications of creating a new connection. What privacy implications are you refering to here? > View Inline draft-ietf-trans-gossip.txt:468 > actually preserve user privacy. The Issuer field in the certificate > describes the signing certificate. And if the certificate is being > submitted at all, it means the certificate is logged, and has SCTs. > > describes, yes, but doesn't uniquely identify. This paragraph describes certificates that chain to a somewhat-publicly trusted, but still locally added trust root. We were under the impression that the Issuer field in CA certificates is required to be unique. Even if it's not required to be unique, the Issuer name, the public nature of the intermediate, and the signature all combine to enable a unique identification of the certificate chain in question. > View Inline draft-ietf-trans-gossip.txt:673 > validity window not to be personally identifiable data, and STHs > outside this window to be personally identifiable. > > 14 just seems like a random number here. There's nothing that makes these > STHs personally identifiable other than that you told everyone else not to > save after 14, right? The choice of 14 days _was_ arbitrary. However, you can't substitue any number in there for the same result. The other component, besides everyone using the same configuration, is that the timeframe must be _short_ enough that seeing a STH on the tail end of it is not rare. If we had chosen a 720 day window, it would be very rare for a client to have a particular STH on the tail of the window. A client could be fed a 719-day-old STH on a.com, and when they pollinate it on b.com, they can be recognized cross-domain with a much greater chance. We guessed that 14 days was an appropriate number. WG: Should we perform real-world measurements before picking a number for STH freshness or will our guess be good enough for an experimental RFC if we add text along the lines of the above explanation? > View Inline draft-ietf-trans-gossip.txt:799 > browser that is "logged in to" a provider of various internet > services. Another equivalent arrangement is a trusted party like a > corporation to which an employee is connected through a VPN or by > > What's an example of this? Just because I'm logged into (say) Google > doesn't mean I'm providing them with my browsing data. "Google Chrome provides the option to sign in with your Google Account and synchronize your Chrome data across multiple devices. Synced data can include bookmarks, saved passwords, open tabs, browsing history, extensions and other settings. In Advanced sync settings, you can choose which types of data to synchronize with this device. By default, all syncable data types are enabled." https://www.google.com/chrome/browser/privacy/whitepaper.html#signin > View Inline draft-ietf-trans-gossip.txt:804 > proofs from that third party could be considered reasonable from a > privacy perspective. The HTTPS client may also do its own auditing > and might additionally share SCTs and STHs with the trusted party to > > Why would this be the case? Are you questioning why it could be considered reasonable to share gossip data with any of the suggested types of third party organisations? Or why an HTTPS client might do auditing? > View Inline draft-ietf-trans-gossip.txt:932 > Unlike SCT Feedback, the STH Pollination mechanism is not hampered if > only a minority of HTTPS servers deploy it. However, it makes an > assumption that an HTTPS client performs Proof Fetching (such as the > > I'm not sure that this is true. Say that only one server deploys it. Maybe > you meant that there is still ecosystem value. Yes. "Ecosystem value" is the only value provided by STH Pollination. > View Inline draft-ietf-trans-gossip.txt:996 > HTTPS clients are afforded the greatest chance of detecting an attack > when they either participate in both SCT Feedback and STH Pollination > > "greatest chance" isn't that encouraging. Please actually quantify this in > some way. Do you think that the document is lacking text on _why_ a client has the greatest chance of detecting an attack when $foo? Or are you asking for reasoning about how large the chance of detecting an attack might be? > View Inline draft-ietf-trans-gossip.txt:1160 > be in addition to the expected set, and will be evidence of the > attack. > > Why can't an attack add a lot of STHs to the cache? We've tried to clarify this in text, but the cache should be slightly larger than the maximum valid STHs. So if an attacker tries to flush the cache, they will have to use invalid STHs to flush it, and we only need one of those to detect a compromised log. > View Inline draft-ietf-trans-gossip.txt:1283 > from a CT log that it doesn't accept SCTs from. An HTTPS client > SHOULD regularly request an STH from all logs it is willing to > accept, even if it has seen no SCTs from that log. > > Is any HTTPS client actually planning to do this? We have no idea. WG: Do you know of any HTTPS client planning on implementing _any_ of the methods described in this document? > View Inline draft-ietf-trans-gossip.txt:1431 > SHOULD send gossip data in an already established TLS session. This > can be done through the use of HTTP Pipelining, SPDY, or HTTP/2. > > My understanding is that almost nobody currently does pipelining. Okay, but it's still part of the HTTP standard, is it not? It seems like it's still a valid example of a measure that would achieve our desired goal here. > View Inline draft-ietf-trans-gossip.txt:1533 > with SCTs received from other clients, and act upon them at some > period of time > > This all seems pretty vague. Do you provide specific algorithms? We don't and we'd prefer not to try and specify one, but if we needed to, we could point to specific sections of STH Pollination and say "Do something like that." > View Inline draft-ietf-trans-gossip.txt:1752 > && now() - sth.timestamp > LOG_MMD > && sth.proof_attempts != UINT16_MAX > // Only fetch a proof is we have never received a proof > > What does this check do? Prevents an int overflow that would reset a counter from the 'abnormal' situation to a 'normal' situation. You could move it into a checked increment, but the idea is if you've attempted to fetch a proof UINT16_MAX number of times already, we can omit further attempts. > View Inline draft-ietf-trans-gossip.txt:2142 > num_feedback_loop_failures = 0 > if(num_submissions_succeeded != UINT16_MAX ) > num_submissions_succeeded++ > > Is this because the limit might be as high as UINT16_MAX Yea, seems unlikely we'd reach it, but we're guarding against an int overflow. From nobody Fri Jan 12 01:06:46 2018 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 9259D127863 for ; Fri, 12 Jan 2018 01:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se 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 uNKpusXpHPVW for ; Fri, 12 Jan 2018 01:06:40 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 35C15124BFA for ; Fri, 12 Jan 2018 01:06:39 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w0C96buT069513 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 12 Jan 2018 10:06:38 +0100 Received: from datan ([185.65.135.179]) (authenticated bits=0) by smtp1.sunet.se (8.15.2/8.14.9) with ESMTPSA id w0C96YWJ001880 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 12 Jan 2018 09:06:37 GMT VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1515747997; bh=h3xBJ+ZO2Ofz4NRMOJfUODicb6svQ9aEKqrN2MC2rYM=; h=From:To:Subject:Date; b=HzMKNVoBnaxI68+H/l78zbdTqjNf6pj6OCi6Wf3vFcsttfV4dLnaribYq3c7aLLAb TJgqVgw1JIjHeM/OCYCjoR/3zmQitjpszVWFcBC9Y+sIjmGZoMvgaEvTGxQnzXPMsz 6WavATf2DfwtUXnRq5DhgZmfHxl8UFmMeecBJhxA= From: Linus Nordberg To: trans@ietf.org Organization: Sunet Date: Fri, 12 Jan 2018 10:06:29 +0100 Message-ID: <87zi5jo38q.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=185.65.135.179; country=SE; latitude=59.3247; longitude=18.0560; http://maps.google.com/maps?q=59.3247,18.0560&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09UVl6Ca5 - dc3d38f097e9 - 20180112 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 185.65.135.179 is neither permitted nor denied by domain linus@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=185.65.135.179; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: [Trans] Gossip ticket #103 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jan 2018 09:06:43 -0000 Hi, I think that #103 [0] has been resolved and should be closed. [0] https://trac.ietf.org/trac/trans/ticket/103 From nobody Fri Jan 12 01:16:18 2018 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 4890E12D77C for ; Fri, 12 Jan 2018 01:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se 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 Xxmfy4o_5oH4 for ; Fri, 12 Jan 2018 01:16:15 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 DD84712DA4D for ; Fri, 12 Jan 2018 01:16:14 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w0C9GC4D077962 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 12 Jan 2018 10:16:12 +0100 Received: from datan ([185.65.135.179]) (authenticated bits=0) by smtp1.sunet.se (8.15.2/8.14.9) with ESMTPSA id w0C9G80P000551 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 12 Jan 2018 09:16:11 GMT VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1515748572; bh=dUgZzv9AfDNOe04vgQqYbsQakGFp7T/9frdo81/8Wxw=; h=From:To:Subject:Date; b=X3XzkNwVVAz3pXCtPxf0Z6BJCl59MJrySbk9BxInvkZS8OSJu50/VY7ZvBx6sQZG5 YQ1bUAjhPttSDOge6Ldd2qkqg0v9SWFKmbvUHQ7AnIflNVr/rkESGy8W127NQkq5vC nOKrLv+ihJ9UDn5MkfIjpjJR1FBfaSBIxt/k1i0M= From: Linus Nordberg To: trans@ietf.org Organization: Sunet Date: Fri, 12 Jan 2018 10:16:04 +0100 Message-ID: <87vag7o2sr.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Bayes-Prob: 0.0086 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=185.65.135.179; country=SE; latitude=59.3247; longitude=18.0560; http://maps.google.com/maps?q=59.3247,18.0560&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09UVlgczW - 0d041ccc4625 - 20180112 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 185.65.135.179 is neither permitted nor denied by domain linus@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=185.65.135.179; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: [Trans] Gossip ticket #130 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jan 2018 09:16:17 -0000 Hi, I think that #130 [0] should be considered resolved as wontfix since we passed wglc without anyone raising this issue. If the wg suddenly feel strongly about this, someone should provide text describing how delegation should be done. [0] https://trac.ietf.org/trac/trans/ticket/130 From nobody Fri Jan 12 01:34:00 2018 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 4F5A312DA6C for ; Fri, 12 Jan 2018 01:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se 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 ZU5dXy0vZGZT for ; Fri, 12 Jan 2018 01:33:57 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 AD0AC1243F3 for ; Fri, 12 Jan 2018 01:33:56 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w0C9XrQ1091373 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 12 Jan 2018 10:33:54 +0100 Received: from datan ([185.65.135.179]) (authenticated bits=0) by smtp1.sunet.se (8.15.2/8.14.9) with ESMTPSA id w0C9Xnse014472 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 12 Jan 2018 09:33:52 GMT VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1515749632; bh=PajR/CjLXdIP4VswaL2uDkpAGdlPF8QAFKkgK9P10nE=; h=From:To:Subject:Date; b=pU/aUg7llE6IOCgNhF6aDIHZfhlHEAI49e+mB45UMwID55IH/CLGiOK4ZTL+PDtTB nC2Elto00swcdRuak2O/SRnOmDgxcL+pNupP1+NxNqgkqsr/j+a4bHsQwAz/dKNlyl bvKwlEFmvi6/iLCnELBN09LcmRUSOMRIHD1bGV6U= From: Linus Nordberg To: trans@ietf.org Organization: Sunet Date: Fri, 12 Jan 2018 10:33:44 +0100 Message-ID: <87o9lzo1zb.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Bayes-Prob: 0.0177 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=185.65.135.179; country=SE; latitude=59.3247; longitude=18.0560; http://maps.google.com/maps?q=59.3247,18.0560&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09UVlxRgK - 02c59949ddb8 - 20180112 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 185.65.135.179 is neither permitted nor denied by domain linus@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=185.65.135.179; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: [Trans] Gossip ticket #146 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jan 2018 09:33:59 -0000 Hi, I think that #146 [0] should be closed as wontfix since the sections of 6962bis that it refers to no longer exist. [0] https://trac.ietf.org/trac/trans/ticket/146 From nobody Sun Jan 14 13:55:21 2018 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 02AC512D88D; Sun, 14 Jan 2018 13:55:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trans@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151596691897.3222.9954562228218276501@ietfa.amsl.com> Date: Sun, 14 Jan 2018 13:55:19 -0800 Archived-At: Subject: [Trans] I-D Action: draft-ietf-trans-gossip-05.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2018 21:55:19 -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 WG of the IETF. Title : Gossiping in CT Authors : Linus Nordberg Daniel Kahn Gillmor Tom Ritter Filename : draft-ietf-trans-gossip-05.txt Pages : 57 Date : 2018-01-14 Abstract: The logs in Certificate Transparency are untrusted in the sense that the users of the system don't have to trust that they behave correctly since the behavior of a log can be verified to be correct. This document tries to solve the problem with logs presenting a "split view" of their operations or failing to incorporate a submission within MMD. It describes three gossiping mechanisms for Certificate Transparency: SCT Feedback, STH Pollination and Trusted Auditor Relationship. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trans-gossip-05 https://datatracker.ietf.org/doc/html/draft-ietf-trans-gossip-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-gossip-05 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 Mon Jan 22 21:48:26 2018 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 61C0F12D95A for ; Mon, 22 Jan 2018 21:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no 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 TyevmDo9bax9; Mon, 22 Jan 2018 21:48:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA6B12D95F; Mon, 22 Jan 2018 21:48:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Tue, 23 Jan 2018 05:48:23 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/146#comment:3 Message-ID: <047.8295591fc655f450c640102133d77321@ietf.org> References: <032.9e6b0bea200188329b454e1d41f6a81d@ietf.org> X-Trac-Ticket-ID: 146 In-Reply-To: <032.9e6b0bea200188329b454e1d41f6a81d@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #146: SCT Feedback doesn't account for privacy-sensitive EE certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 05:48:25 -0000 #146: SCT Feedback doesn't account for privacy-sensitive EE certs ---------------------+------------------------------------------------- Reporter: david@… | Owner: draft-ietf-trans-threat-analysis@… Type: defect | Status: closed Priority: major | Milestone: Component: gossip | Version: Severity: - | Resolution: wontfix Keywords: | ---------------------+------------------------------------------------- Changes (by melinda.shore@…): * status: new => closed * resolution: => wontfix Comment: From Linus: {{{ I think that #146 [0] should be closed as wontfix since the sections of 6962bis that it refers to no longer exist. }}} -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Mon Jan 22 21:49:34 2018 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 11EF912DA18 for ; Mon, 22 Jan 2018 21:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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, URIBL_BLOCKED=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 QmC5h0tTxcMR for ; Mon, 22 Jan 2018 21:49:31 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 713EC12DA09 for ; Mon, 22 Jan 2018 21:49:31 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id t12so8957211pfg.2 for ; Mon, 22 Jan 2018 21:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=8wCwJzzDhTkr0QIfMI4y/WTdkTCmbmwZTgzWOL7ATEk=; b=X+UXQ2j75+SnQ3cfCefeXcnYPGF+iCy/rtnYpIzzPxkf1ubfQgmcXN23HG6oV95y62 fgtLC7c7B5OieuyYq4ZRd1uLyT/RBEmuY6AZqls9sVnXP5RUk++fQNliKsBr0SltbR6e io6/4bdGF0pG/w9VD7GkKolQniw0qAmK78tc/M0pj1l58uFVdGvQjg7whQ5R4ohAKKQD 2qYgyGpU9zzwiHmzn6kvVVLmgDWFxXC1qR1VopJXKdrhNeKbsfNxfywkmC8J5rPTdqjG IstlnACU8S9B2xnPvjrZlEssG2KH5PtA7o1NgtctkU6jVRmhceZasNG7CeWkl1efleIx m71Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=8wCwJzzDhTkr0QIfMI4y/WTdkTCmbmwZTgzWOL7ATEk=; b=c40wEQfP2hdCbTVXKr3Bn8UVZ0fMkZqmZlNQxwhbw6l/yAqfXrWMbnWZVgyViqPkYX MognGYtmG7HEFUbLldM303lYtRrFrr808s/C39E6huZ4ElHfingDIbPCxiMrq64x4uGE XE4Yl3pNX+NJ1rV9EyuaLbshyj6Y5rOBjMjCuzl14+SzvQpImQ0mcTn9nYaNqswFqhFx FYTFpjZZvcHAftkM864esvzPtgjXHv3e2HNDt2S3KB64tAWRMX1APozcmK6RhXs8Fyfx MvyMBfdguGSYKJj5dPQB0Eu84Yi+IkcUYPvxGetwrmiPwf1X1cC5Jks93iIXN4zSDNa5 e61A== X-Gm-Message-State: AKwxytfDCAVQxZGemchp9udtnH45NGx4PvwcjIJqP+I2772vYwxddXCD zifwmNMHMjrzfDtRLmWs5FIIrQ== X-Google-Smtp-Source: AH8x225F/0s7v2LJLqBNEoiF0dxeqjpFdzZTuWBmci73tJxZrii+HIfeBjiPGj0SrNsHHD8L6QqUyw== X-Received: by 10.98.248.75 with SMTP id c11mr9565580pfm.54.1516686570467; Mon, 22 Jan 2018 21:49:30 -0800 (PST) Received: from aspen.local (69-162-195-194-radius.dynamic.acsalaska.net. [69.162.195.194]) by smtp.gmail.com with ESMTPSA id e3sm3087797pfb.143.2018.01.22.21.49.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 21:49:29 -0800 (PST) To: trans@ietf.org References: <87vag7o2sr.fsf@nordberg.se> From: Melinda Shore Message-ID: Date: Mon, 22 Jan 2018 20:49:25 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <87vag7o2sr.fsf@nordberg.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i0DGQVeOlhzsYrd29X7UGijuNawjh0iPe" Archived-At: Subject: Re: [Trans] Gossip ticket #130 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 23 Jan 2018 05:49:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i0DGQVeOlhzsYrd29X7UGijuNawjh0iPe Content-Type: multipart/mixed; boundary="cV4RlVKRN2e3luQMZyz6ZuCOMe2j4w3xN"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Message-ID: Subject: Re: [Trans] Gossip ticket #130 References: <87vag7o2sr.fsf@nordberg.se> In-Reply-To: <87vag7o2sr.fsf@nordberg.se> --cV4RlVKRN2e3luQMZyz6ZuCOMe2j4w3xN Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 1/12/18 12:16 AM, Linus Nordberg wrote: > I think that #130 [0] should be considered resolved as wontfix since we= > passed wglc without anyone raising this issue. >=20 > If the wg suddenly feel strongly about this, someone should provide tex= t > describing how delegation should be done. >=20 > [0] https://trac.ietf.org/trac/trans/ticket/130 Any objections? Thanks, Melinda --cV4RlVKRN2e3luQMZyz6ZuCOMe2j4w3xN-- --i0DGQVeOlhzsYrd29X7UGijuNawjh0iPe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJMBAEBCgA2FiEEOwSIcj4Q6xsnay8FuIZGkzoegS4FAlpmzOUYHG1lbGluZGEu c2hvcmVAZ21haWwuY29tAAoJELiGRpM6HoEucpwP/3RDTIhMpn4eQ92Hdh0cefJk e+ftX9PWlv3sINVMHwcbDzszvpUzL7jlxIfVJMYB3Sopmq/MCBxiYPZxZiD/UhFr OUUxgTPNvYYGhhN5W61nJll+YfjqJ0pnKTH/UEEDs0V7y7k4+IWcSuMaNsTuswxo eYxtKfqKDNExedDIkYhmFGtIdrO7SpoCWf1fJt2q4DcOCvdGFTwYentse8db0cgM AVHx5aWqJ/+96tuW61n6OjAI6s3PaISRa99hrGY/CgnSkpeatNYceS/fdUt1YVZe /AVCFmKNqEsEKt+ClbI45YLOERoGdUkAnIFqDDWONjA6UE2AmVTqQCEiqDg3uJJu uX5Z0rd9zyXb8aJxCPhv8lU08TCKieOmdBi5Ms7AzVBfARYH2r/10J3/7GyaoRp4 8+dePi5lOX31Tl/to259doL+ZOBLnbAzhzjg/JdIQx4AFp/HshgveNb0THcKkvdG tYoSdDrWLxFouauPFtZpbbYnP1afTRQ0GoMR5tjlRYDIbsKCcTYjMk/xoCAHXalS GYLvPdjL6VOd1lPZgz+4F5GcvtTpSwiZdqI31o2oCSPKhNk2K1u8Yd9+9jUI1rPA 410g/f68XOPWDejeKVeEizON3g+e2iwcwLgjWchtTZ3WAZLqgVxLn9pfdvGmIDLf kiUwx/AqittomkBNBVxl =H40y -----END PGP SIGNATURE----- --i0DGQVeOlhzsYrd29X7UGijuNawjh0iPe--