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

[Ryan Sleevi]

Hi Kirk,

I'm glad that Jeremy has answered many of your questions, and pointed out
that indeed many of them have already been answered in the past, either in
our communications with CAs that are members of our EV program or within
the Certificate Transparency mailing list.

I do want to highlight that Chromium will continue to operate its EV
program in a manner that is in the best interest of Chromium's users and
their security, and thus will continue to develop our requirements around
CT in a way that we believe best meets these goals. While we appreciate the
attempt to develop a common policy framework for CT, it does seem quite
premature, considering that currently Chromium is the only browser that has
announced such plans.

As such, we plan to set our requirements - for CT Logs, for CAs, and for
servers - in a way that best meets the security requirements and goals of
Chromium and its users. We have already been in contact with the CAs that
are recognized as EV within our program, to gather feedback, and will
continue to do so as necessary.

I would suggest that such discussions about setting forth "business rule
issues" are thus perhaps not in the best interest of the Forum's time,
although we're more than happy to take a slot during the F2F to discuss our
plans and answer any questions that may arise. Considering that CT is *not*
a requirement of the Baseline Requirements - nor are we, at this time,
advocating that it should be - it does not seem a pressing issue for the
Forum to establish guidelines.

The one request I would make of such a slot is that as we're developing the
schedule, it be early in the morning to ensure that members of Google's CT
team in Europe can attend.

All the best,
Ryan


On Thu, Jan 23, 2014 at 12:32 PM, kirk_hall at trendmicro.com <
kirk_hall at trendmicro.com> wrote:

>  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
>
>
>
> 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.
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140124/4388e78d/attachment-0001.html