[cabfpub] Time in Mountain View to discuss business rules around CT

[Rob Stradling]

On 23/01/14 20:47, Jeremy Rowley wrote:
<snip>
> c.  Audits – should we fold CT log requirements into the relevant parts
> of the existing WebTrust/ETSI third party audit structure?  Require
> public audit reports?  And what should be audited?  (1) The integrity of
> the CT log, (2) the security around the CT log (data center,
> configuration between CT log signing and CT log so no signed certs are
> omitted from the log), (3) who has been given access to the CT log, and
> whether access rules and restrictions have been followed, or (4) all
> three issues?
>
> No.  Security is less relevant for logs than CAs.

Less relevant, perhaps.  But definitely still relevant.

If a CT log's private key is compromised and used to produce SCTs that 
are not then logged, this log misbehaviour will be detected and the log 
will be struck off the list of acceptable logs.

There will be costs associated with having a log struck off.  It'd 
definitely be in the log operator's interest to do what they can to 
protect their private key!

<snip>
> b.  Can a domain owner “opt out” of CT?  Domain owners probably can’t
> opt out of having their certs signed by CT logs (that sounds like it
> will be a technical requirement), but some domain owners may not want
> anyone but themselves to be able to view/query CT log data about their
> certs for their domains – not the public, and not the browsers.  In this
> regard, it would be like a “Do Not Call” list for telemarketing.
>
> Nope. Domain owners can opt out by having an intermediate that is
> technically constrained added to the log.  However, they cannot opt out
> completely.

Actually, RFC6962 doesn't specify any way for a domain owner to opt out.

For the RFC6962-bis effort, I've proposed 2 ideas relating to this:
https://code.google.com/p/certificate-transparency/issues/detail?id=20

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online