Re: [Trans] White out (was Re: Reviving Redaction)

[Ben Laurie <[e-mail]>]

On 6 March 2017 at 23:30, Rob Stradling <[e-mail]> 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!
>

I think if this kind of thing is going to work, you have to also log the
reason for removing the cert (e.g. link to court order :-).


>
> On 06/03/17 22:26, Jeremy Rowley wrote:
>
>> On the CT days, there was an emphasis on a distinction between white
>> washing
>> a cert (removing it from CT) and redaction. Is the white washing in scope
>> for the Trans list and this discussion or should it be separate?
>>
>> I ask because two of the main arguments cited for redaction tend to be:
>> 1) Network/New project mapping reveals
>> 2) Inclusion if PII in logged certs
>>
>> If white washing address the second concern, a specification around that
>> process could eliminate a good deal of the push for redaction.
>>
>>
>> -----Original Message-----
>> From: Trans [mailto:[e-mail]] On Behalf Of Rob Stradling
>> Sent: Monday, March 6, 2017 2:39 PM
>> To: Ben Laurie <[e-mail]>
>> Cc: [e-mail]; Peter Bowen <[e-mail]>
>> Subject: Re: [Trans] Reviving Redaction
>>
>> On 06/03/17 21:22, Ben Laurie wrote:
>>
>>> I think you can waste a lot of brainpower on redaction, but really the
>>> answer is: if you don't want to publish your names, then don't use a
>>> mechanism that requires you to.
>>>
>>
>> I agree that that's the ideal answer, but as we've seen, there is
>> resistance
>> to that answer from various participants in the CT ecosystem.
>>
>> There are alternatives: name-constrained sub-CAs.
>>>
>>
>> We removed that option from 6962-bis.  It's now in
>> draft-strad-trans-redaction, but IIRC the Chrome team hinted that they're
>> unlikely to ever support it (at least in its current form).
>>
>> Private CAs. You can even have private CT to go along with them.
>>>
>>
>> Private CAs don't suit every use case, AFAIK.
>>
>> Why mess up a protocol whose intent is to show everything?
>>>
>>
>> Because Security and Useability aren't always in perfect harmony?
>>
>> Much as I'd love to stop wasting brainpower on redaction, I think it's a
>> conversation that needs to continue for now (although not indefinitely!)
>>
>> On 6 March 2017 at 21:16, Rob Stradling wrote:
>>>
>>>     On 06/03/17 06:06, Peter Bowen wrote:
>>>     <snip>
>>>
>>>         8) The only way to get the content of a full certificate is to
>>>         have a
>>>         full certificate.
>>>
>>>         Rationale: An alternative option is to have some sort of escrow
>>>
>> key
>>
>>>         that can "unlock" a precertificate.
>>>
>>>
>>>     In previous iterations of 6962-bis, we proposed a redaction
>>>     mechanism that envisaged replacing domains labels with ?s in
>>>     precertificates. That mechanism was deemed problematic by the Chrome
>>>     team precisely because "The only way to get the content of a full
>>>     certificate is to have a full certificate".
>>>     What recourse does a domain owner have when they discover a
>>>     precertificate for their domain space that they don't recognize?
>>>     How do they figure out whether the (pre)cert was misissued or
>>>     whether it was legitimately requested by a different team within
>>>     their organization?
>>>
>>>     The redaction mechanism that's documented in
>>>     https://tools.ietf.org/html/draft-strad-trans-redaction-01#
>>> section-3.3
>>>
>>> <https://tools.ietf.org/html/draft-strad-trans-redaction-01#section-3.3>
>>
>>>     attempted to find a solution to this problem of recourse by swapping
>>>     ?s for a hash of the unredacted domain.  However, this mechanism has
>>>     also been deemed problematic, because it could be trivial to
>>>     determine unredacted labels via dictionary attacks.
>>>
>>>     I think a "sort of escrow key" may be the only viable way to
>>>     construct a redaction mechanism that is deemed non-problematic by
>>>     everyone.
>>>
>>>         This quickly turns into 'where do we keep the escrow key?' and
>>>         'who gets
>>>         to access the escrow key?'.  If there is no such thing, then
>>> these
>>>         questions don't exist.
>>>
>>>
>>>     I think these questions will need to be both asked and answered,
>>>     although I'd be delighted to be proved wrong.
>>>
>>>         Do others agree that these are true and can be used as givens for
>>>         reviewing any proposed designs?
>>>
>>>
>>>     Your other points all LGTM.
>>>
>>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>