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

[Ben Laurie <[e-mail]>]

On 18 March 2014 16:07, Daniel Kahn Gillmor <[e-mail]> wrote:
> On 03/18/2014 08:02 AM, Phillip Hallam-Baker wrote:
>
>> Unfortunately it is focused mostly on fixing cookies which is trying to fix
>> stupid which is never going to produce a sensible result. But there is
>> already a zone prefix list used for issue of wildcard certs.
>>
>> The problem of <private>.<domain>.foo.com looks to me to be the same as the
>> problem of *.<domain>.foo.com.
>>
>> *.uk would be a bad thing...
>
> the CABForum guidelines split "registry-controlled" zones from the next
> level of labels using http://publicsuffix.org/, though they acknowledge
> that this is not a scalable long-term solution and something else needs
> to be done eventually (see section 11.1.3):
>
> https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_6.pdf
>
> This idea of a "natural split" between public registries and private
> zones is appealing, because of the tradeoffs between auditability and
> resistance to zone enumeration.  The entities closer to the root of the
> hierarchy need to be audited, since they have power over the leaves; the
> entities nearer to the leaves have less power, little or no
> responsibility delegated to them from third-parties, and possibly more
> legitimate need for hiding individual zone entries or avoiding enumeration.
>
> So how would this work in CT?  if i'm an admin for the example.com zone,
> i'd want to monitor the logs for any entries matching:
>
> a) <PRIVATE>.com
> b) example.com
> c) *.example.com
> d) <PRIVATE>.example.com
>
> if any of b, c, or d are observed which were not issued from within my
> authority, i now have proof of misissuance, and can take the issuing CA
> to task.

Right.

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

> if so, then we need to also consider that CT-aware TLS clients need to
> be able to identify SCTs of the (a) form and report them publicly
> somehow, so that log misbehavior is known.

See above. I think these two cases are different.

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

Another option might be the CA/B Forum.