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

[Ben Laurie <[e-mail]>]

On 18 March 2014 18:47, Daniel Kahn Gillmor <[e-mail]> wrote:
> 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?

It has to look like an X509v3 certificate. But that's about it.

> 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).

As I said, the function of a log is to record and publish, not to
judge. The main reason we ask for logged items to be signed is to
avoid spam (also, of course, there's not a huge amount of point in
logging things that nothing can be done about, so attribution to a CA
seems useful).

> 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?)

That is the the problem surely? The purpose of the log is to ensure
correct issuance. If the logged certificate contains insufficient data
to do that, then the CA is not cooperating.

> 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.

The SCT does not tell you whether you should accept or reject the
certificate - it merely tells you it was logged. You always have to
check further to discover whether it was OK or not.

> 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?

I would claim that it is the CA that is not fulfilling its mission (of
logging appropriately). Logs need to be liberal in what they accept
otherwise they become a chokepoint for policy, which is surely not a
desirable outcome.

>>> 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.

OK, so I'm not specifying a detailed mechanism for reporting right
now, but clearly one is needed. For now "tell Ben or Chrome team"
seems sufficient. In general, enforcement has to lie with the clients
(and therefore, mostly with the authors of those clients), so I don't
see how I can define a general mechanism for this.

>> 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.

I am not expecting end users to have to know anything - I expect
clients to assist them in this matter. Exactly how we will do this in
Chrome has not yet been decided, but clearly we do need to decide it,
and we will.