Re: [Trans] Another Question about the PRIVATE option (Ticket #1)

[Daniel Kahn Gillmor <[e-mail]>]

On 03/18/2014 12:22 PM, Ben Laurie wrote:
> On 18 March 2014 16:07, Daniel Kahn Gillmor <[e-mail]> wrote:
>> a) <PRIVATE>.com
 [...]
>> But if (a) is observed from monitoring the log, what can the site
>> operator do?  Do we declare that (a) is indication of log misbehavior?
> 
> Surely not - this, again, is misissuance (or misreporting by the CA,
> if you prefer). i.e. the CA should be taken to task. The log does not
> judge, it merely records.

hm, i think this introduces a new way that a CA can misissue -- in
particular, it's misissuing a precertificate by putting a <PRIVATE>
label where it should not.

Do you expect the logs to accept (and certify, and publish)
arbitrarily-structured data in the PreCertificate so long as it is
signed by a known CA?  Or will there be some constraints on the data
submitted?

If there are constraints on what kind of precerts a log is willing to
certify, then this would seem to be a reasonable addition to the list of
constraints (though it would be another way that a log could itself
misbehave -- we'd want to add that to the list of things a monitor
should look for).

If the logs just accept and sign this data, what do you suppose should
happen to a CA that has sent a precert of type (a) to the public logs?
It's not clear who was harmed by it (since the actual dNSName used in
the cert itself is not known, right?), and for CT-aware TLS clients that
know to ignore SCTs where <PRIVATE> falls immediately to the left of an
entry in the public suffix list should ignore the SCT anyway.  But
inevitably there will be some clients that see this and don't have an
updated version of the public suffix list, or don't have the ability to
fetch and retain such a thing, and will be fooled by the SCT.

It's very difficult for the domain holder to tell that they have
specifically been harmed in this case (and possibly even difficult to
make a strong case for negative consequences to the issuing CA or
misbehaving log), so it seems like CT isn't fulfilling its mission of
making detection of misissuance isn't being met here.  Or have i missed
something?

>> presumably, this would be
>> the same mechanism used to report an SCT that didn't show up within the
>> MMD, right?  is there a reporting mechanism defined?
> 
> Currently, only Chrome is implementing CT as a client (to our
> knowledge) and so I guess the appropriate recipient of such a report
> would be Google. We have not yet defined a way to do this, but
> anticipate that Chrome will offer to do it when appropriate.

Given that the scheme's robustness relies on clients reporting errors
(in both the logs or the CAs), i think we need to be clearer about how
such a report should happen.

> Another option might be the CA/B Forum.

End users operating their browsers are not going to know how to send any
kind of report to the CA/B Forum, unless you're suggesting that CA/B
Forum could set up a public repository to hold cryptographically-proven
documentation of misissuance or something, and the submission could be
automated somehow.  I don't know enough about the CA/B Forum to know if
that's within their scope or not.

Regards,

	--dkg