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

[Ben Laurie]

On 23 January 2014 21:28, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> I should mention that the detection relies on implementation of the
> Gossiping feature (which is not yet operational).  The risk is mitigated by
> requiring three logs.  However, the number of logs is not readily detectable
> if the proof is served through OCSP.

The current draft EV/CT plan only asks for 1 log in OCSP and the TLS
Extension, since they can be updated dynamically.

>  Considering that gossiping is slow to
> detect, having some minimum security requirements is a very good idea.
>
>
>
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
> Behalf Of Jeremy Rowley
> Sent: Thursday, January 23, 2014 1:48 PM
> To: kirk_hall at trendmicro.com; 'CABFPub'; ben at digicert.com
> Subject: Re: [cabfpub] Time in Mountain View to discuss business rules
> around CT
>
>
>
> Although a discussion sounds good at the face-to-face, Google has already
> answered most of these in their spec/communications.  Still, I agree with a
> discussion at Mountain View to make sure everyone is on the same page.
>
>
>
> 1.  Security requirements for CT logs
>
>
>
> a.  General security requirements – should we apply sections of the CABF
> Baseline Requirements and/or the Network and Certificate System Security
> Requirements to CT logs?  (I have a real concern that a hacker could hack a
> CT log, force a rogue cert to be signed by the log, but prevent posting to
> the log so the rogue cert will be undetectable – that would make CT
> unreliable.)
>
> No it wouldn’t. Since the SCT is public, that is a detectable event and
> would cause the log to lose trust.
>
>
>
> b.  Should there be other required qualifications to run a CT log –
> finances, insurance?
>
> Uptime.  That is the only requirement.
>
>
>
> 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.
>
>
>
> d.  Access – who may submit certs for signing and posting to a CT log?  Only
> WebTrust/ETSI audited CAs?  Anyone?  What restrictions, if any, should be
> considered?
>
> I believe this is up to the log operator.
>
>
>
> e.  Costs – are CT logs allowed to charge for posting?  For queries?
>
> Sure.  However, anyone that charges will find themselves with an empty log.
>
>
>
> f.  Business continuity / disaster recovery plans – If a CT log goes down,
> it could leave many thousands of cert owners and CAs in a bind.  What if the
> company running the CT log just goes out of business – who would step in to
> maintain the CT log until all the issued certs have expired?
>
> Hence the requirement to hit three logs.  Don’t use a log you don’t trust.
> Google is running two logs.  DigiCert is planning on running a log.
>
>
>
> 2.  Handling of certificate data in a CT log
>
>
>
> a.  Who is permitted to query a CT log?  What data can they see?  What data
> can they copy?
>
> Google said anyone in their original spec.  In fact it almost needs to be
> anyone for the CT log to work properly since the monitors are not
> necessarily the domain holders. That said, some restrictions on the
> information found in certs (especially ones issued to individuals) would be
> great to avoid potential privacy issues.
>
>
>
> One alternative would be as follows:
>
>
>
> (1) Domain owners can query their own domains at any time – but could be
> required to prove domain ownership or control by using the automatic method
> at BR 11.1.1 at intervals, say every 1-3 years.  Domain owner accounts could
> then be set up protected by a user name and password, with the domain owners
> could share with third party monitor companies for automated access.
>
>
>
> (2) Browsers who support CT could query the CT logs at will, but only for
> the limited purpose of confirming that logs are in compliance with
> applicable rules and that their Merkle trees are available and not
> corrupted.  Browsers would not be able to compile the CT log certificate
> data, productize it, or reuse it for other purposes, as this raises privacy
> concerns for domain owners and also would appropriate valuable business data
> belonging to the CAs and domain owners.
>
>
>
> (3) The public – it would be possible to allow the public to look up certs
> issued to a particular domain on a one-by-one basis (having to establish a
> user account and go through a captcha to see the data for a domain) – but
> for what valid purpose does the public need access to the data in a CT log?
> Because of domain owner privacy concerns, the collected data has a business
> value to CAs and domain owners, and to avoid data mining for unauthorized
> purposes, there may not be any reason to allow public lookups in CT logs.
> After all, if a member of the public sees a cert issued by a public CA that
> has been signed by a CT log but looks suspicious for some reason, the person
> can simply report the cert as suspicious to the issuing CA using the
> Reporting address on each CA’s website.  Why else would the public have a
> need to query CT logs?
>
>
>
> 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.
>
>
>
> Also, could a hacker leverage CT logs as a way to discover internal
> resources about the organization that is not normally available?  (Many
> certificates cannot be publically discovered today because they are behind a
> firewall).  Because BR 9.2.1 phases out Internal Server Name and IP address
> certs, the Forum has encouraged customers to use FQDN certs for their
> internal systems – but customers may not want to reveal the names of these
> internal FQDN certs to anyone else.
>
> They could.  This has always been a concern.  Again, the answer to this is
> use a logged technically-constrained intermediate.
>
>
>
> 3.         Who must meet CT requirements?
>
>
>
> (a) Commercial CAs only?
>
> They must meet the CA part of CT requirements
>
> (b) External sub-CAs?
>
> Yes – all certs must be logged except where they are only used internally.
> Entities only issuing certs within their own infrastructure can configure
> Chrome to trust certs without the SCT.  However, these certs will be
> considered untrusted if they leak outside the entities’ own systems.
>
> (c) All CAs with roots in the browsers?  (Government CAs, etc.)
>
> All CAs issuing SSL Certs that will work in Chrome.
>
> (d) Will there be an alternative process that a CA can use besides CT?
>
> At the start, they are implementing a white list of non-compliant certs but
> all CAs will need to comply eventually. Google has not yet announced this
> date.
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>