On Fri, Feb 24, 2017 at 11:21 AM, Eran Messeri <[email protected]> wrote: > Following up on this thread, after a few discussions about it in online & > offline forums: > - It is necessary to have the "Redaction reason" entry in the log to commit > the log to the redaction of a particular entry and avoid allowing the log to > present redacted/unredacted view at will. > - A few have echoed Phillip's sentiment that once an entry is suppressed > then the suppression reason can't be effectively audited for correctness. > - There was a strong push-back against this mechanism on the basis that it > weakens the basic properties we get from the Merkle tree right now. > Potential problems: What if the "Redaction reason" entry itself was > redacted? > - A suggestion by Peter Bowen was to simply not serve the redacted entry: > The only API method by which a suppressed entry can be obtain is > 'get-entries', it's possible to return an error when the range specified > includes a suppressed entry. That suffers from the same drawback of the log > being able to selectively presenting redacted/unredacted view.
Another option would be to return something other than "leaf_input" and "extra_data" in the object. For example the log could return the hash of the MerkleTreeLeaf that was there along with a reference to the leaf that has the redaction reason entry. > - An approach many see as superior is to reduce the chances of having > entries with undesirable content in the log by restricting the certificates > that may be logged (e.g. forbidding certificates with embedded images). > > Eran > > On Wed, Nov 16, 2016 at 6:20 AM, Phillip Hallam-Baker <[email protected]> > wrote: >> >> 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 <[email protected]> wrote: >>> >>> On 16 November 2016 at 11:39, Paul Wouters <[email protected]> wrote: >>> > On Wed, 16 Nov 2016, Ben Laurie wrote: >>> > >>> > (no hats on) >>> > >>> >> On 16 November 2016 at 03:46, Paul Wouters <[email protected]> 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. >> >> >> >> _______________________________________________ >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans >> > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
