Agreed, it’s more controversial, but whether a white out mechanism undermines CT depends on whether a whited-out entry still serves as a SCT. If a whited-out entry does not count towards a the log requirements, then it’s the same as not logging the cert in the first place. I’m not sure how that would work yet, but that was a suggestion at the CT days.
Currently, the Chrome policy doesn’t permit quickly spinning up new logs with omitted certificates. From: Ryan Sleevi [mailto:[email protected]] Sent: Monday, March 6, 2017 4:46 PM To: Rob Stradling <[email protected]> Cc: Jeremy Rowley <[email protected]>; Ben Laurie <[email protected]>; [email protected]; Peter Bowen <[email protected]> Subject: Re: [Trans] White out (was Re: Reviving Redaction) On Mon, Mar 6, 2017 at 6:30 PM, Rob Stradling <[email protected] <mailto:[email protected]> > wrote: I think the "white out" proposal that was discussed at the CT Policy Days is likely to be far more controversial than the various redaction proposals. "White out" proposes a mechanism for removing or omitting entire certificates from logs whilst still "proving" that those certificates are "included". Relying parties have to trust the log to only "white out" certs for good reasons. ISTM that this defeats most of the purpose of CT! >From https://tools.ietf.org/html/rfc6962#section-1... "Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, append-only, untrusted logs of all issued certificates." ISTM that supporting "white out" would turn that sentence into this... "Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, modifiable, trusted logs of some issued certificates." That sounds not too dissimilar to the WebPKI minus CT! Indeed. I think the takeaway from the proposed solution is that it undermines the goals of CT to provide the ability to later 'remove' certificates (by effectively inserting a later node in the tree that includes sufficient data to recreate the Merkle Tree, by providing its hash, while refusing to provide that entry to clients). This is the question of whether to solve this problem technologically - if it is even possible (and full disclosure, like Rob states, I believe this seriously undermines the security guarantees) - or whether through policy. The policy approach is simply to shut the log down, should it ever need to violate the append-only property, thereby avoiding any particular notion of additional trustworthiness. This then becomes an 'implementation guidance' aspect, as clients, monitor/auditors, and CAs must all be prepared to adjust to changes in trusted logs commiserate to their belief such a mechanism is necessary/appropriate. That is, if implementations do not believe there exists a need to 'remove' certificates, or are willing and able to tolerate the disappearance of a log, then no further action is necessary.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
