Re: [secdir] dir review of draft-laurie-pki-sunlight-05

[Jeffrey Hutzelman <[e-mail]>]

On Tue, 2013-01-29 at 11:35 +0000, Ben Laurie wrote:
> On 24 January 2013 19:06, Jeffrey Hutzelman <[e-mail]> wrote:
> > Similarly, as an anti-spam measure, this document proposes that logs accept
> > only certificates which chain back to a known CA, and requires that logs
> > validate each submitted certificate before appending it to the log.  This
> > sounds good, but it's not the only possible mechanism, and so I think MUST
> > is too strong here.  Additionally, there is no discussion of the security
> > implications if a client depends on a log to do this and the log does not
> > actually do so.  Rather than requiring that logs validate every submitted
> > certificate, the document should only RECOMMEND that they do so, and make
> > clear that clients MUST NOT depend on such validation having been done.
> 
> On second thoughts, whilst that is an effective anti-spam measure, it
> is also part of the functionality of CT: i.e. to identify misissue and
> give some means to do something about it. The CA check ensures we have
> someone to blame for misissue.

Hrm.  I sort of thought the idea was for the logs to be untrusted
repositories, able to be audited but not themselves expected to detect
problems.  If logs are expected to do validation of this sort, is there
a way for a third party to discover whether they are doing so (or at
least, whether they are accepting certificates they shouldn't)?


> I am not averse to suggestions that achieve the overall aim, but I
> don't see the virtue of leaving it vague in the description of the
> experiment we are actually running.

I'm not suggesting vagueness; rather, I'm merely suggesting downgrading
a MUST to a SHOULD, which is still quite strong.  What happens if
someone wants to start logging certs issued by a private CA, or
self-signed certs they have observed, or...?

I'm suppose I'm OK with keeping the scope narrower than that for
purposes of the experiment, as long as it is possible to relax the
requirement later without breaking the system.  Hence the importance of
making it clear that clients must not rely on logs to have done
validation (on which point I think we've already reached agreement).

-- Jeff