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

Jeremy Rowley jeremy.rowley at digicert.com
Thu Jan 23 21:28:27 UTC 2014

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140123/c0d48d85/attachment-0003.html>

More information about the Public mailing list