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

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Thu Jan 23 20:32:20 UTC 2014


Given that Google wants to implement CT very soon, we would like to propose some time at the Forum's Mountain View meeting to discuss appropriate business rules to apply to any CT implementation.  Ben - can we do that?

Here's a list of CT business rule issues to start with.

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

b.  Should there be other required qualifications to run a CT log - finances, insurance?

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?

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?

e.  Costs - are CT logs allowed to charge for posting?  For queries?

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?

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?

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.

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.

3.         Who must meet CT requirements?

(a) Commercial CAs only?

(b) External sub-CAs?

(c) All CAs with roots in the browsers?  (Government CAs, etc.)

(d) Will there be an alternative process that a CA can use besides CT?

Kirk R. Hall
Operations Director, Trust Services
Trend Micro
+1.503.753.3088


<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140123/56db184a/attachment-0002.html>


More information about the Public mailing list