Subject: [Trans] List of Roots Accepted by Log Servers

From: Rick Andrews <[email-masked]>
Date: Fri, 18 Jul 2014 11:11:24 -0700

I finally got around to reading the list of roots accepted by the pilot and aviator log servers (using the get-roots command). I see a number of our roots that seem inappropriate to me, meaning that we have never issued SSL certs (EV or non-EV) from those roots, and never intend to. It seems to me that Google cast a wide net to add all relevant roots to kickstart the log servers (perhaps bootstrapped from Mozilla's root list?), but at some point (before CT is "live") I would like to see the list trimmed.

My thinking is that if I somehow issue an SSL cert from a root that I did not intend to use for SSL, I would prefer to catch that as quickly as possible; ideally, when the log server refuses to give me an SCT. Is Google willing to remove roots from pilot and aviator?

I think we need a somewhat formal way for CAs to provide log server operators their list of roots, and update that over time. For example, we have a few new roots that we expect to be using in the next few months, and I need to make sure they're added to log servers before I start using them. If log server operators provide an service level agreement (SLA) for such changes, that would be great.

Comments?

-Rick

---

From: Matt Palmer <[email-masked]>
Date: Sat, 19 Jul 2014 06:16:57 +1000

I can't speak for Google, but I'll speak as an intending log operator.

On Fri, Jul 18, 2014 at 11:11:24AM -0700, Rick Andrews wrote:
> My thinking is that if I somehow issue an SSL cert from a root that I did
> not intend to use for SSL, I would prefer to catch that as quickly as
> possible; ideally, when the log server refuses to give me an SCT.  Is
> Google willing to remove roots from pilot and aviator?

I'd be willing to remove root certs from the logs I run if requested, based
on a suitably authenticated communication from the CA operator.

I wonder, though, why a root CA certificate would end up in a log in the
first place if it wasn't intended to produce publically-trusted
certificates.  Like you, I've been led to believe that Google scraped one or
more browser trust stores for the list of certs on pilot/aviator.  Why would
a root CA operator have added their root cert to a browser trust store if
they weren't intending to issue trusted certificates?  If the root was added
for a non-web-server trust bit, I see that as being within the purview of
CT, because I'd like to be able to audit for the issuance of code signing
and e-mail certificates as well.

> I think we need a somewhat formal way for CAs to provide log server
> operators their list of roots, and update that over time.  For example, we
> have a few new roots that we expect to be using in the next few months,
> and I need to make sure they're added to log servers before I start using
> them.  If log server operators provide an service level agreement (SLA)
> for such changes, that would be great.

I'm planning on publishing operator contact details in or near the log
itself -- send an e-mail to the address in there and you'll get a response
within the MMD.  Seem reasonable?

- Matt

-- 
You know you have a distributed system when the crash of a computer you’ve
never heard of stops you from getting any work done.
		-- Leslie Lamport "Security Engineering: A Guide to Building
		   Dependable Distributed Systems"

---

From: Jeremy Rowley <[email-masked]>
Date: Fri, 18 Jul 2014 20:31:33 +0000

Although I can see the appeal for a process with Google operated logs, I don't think there is much value in creating a system to add/remove roots from a log at a CA's request.  If CAs don't want to include their cert on a specific log, the CA shouldn't ever hit the log with a pre-cert.   For our log, we are simply going to enable roots as we see appropriate, most liked based on the certs trusted in both Mozilla and MS (but we are still debating this issue).

Jeremy

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Matt Palmer
Sent: Friday, July 18, 2014 2:17 PM
To: [email-masked]
Subject: Re: [Trans] List of Roots Accepted by Log Servers

On Fri, Jul 18, 2014 at 11:11:24AM -0700, Rick Andrews wrote:
> My thinking is that if I somehow issue an SSL cert from a root that I 
> did not intend to use for SSL, I would prefer to catch that as quickly 
> as possible; ideally, when the log server refuses to give me an SCT.  
> Is Google willing to remove roots from pilot and aviator?

I'd be willing to remove root certs from the logs I run if requested, based on a suitably authenticated communication from the CA operator.

I wonder, though, why a root CA certificate would end up in a log in the first place if it wasn't intended to produce publically-trusted certificates.  Like you, I've been led to believe that Google scraped one or more browser trust stores for the list of certs on pilot/aviator.  Why would a root CA operator have added their root cert to a browser trust store if they weren't intending to issue trusted certificates?  If the root was added for a non-web-server trust bit, I see that as being within the purview of CT, because I'd like to be able to audit for the issuance of code signing and e-mail certificates as well.

> operators their list of roots, and update that over time.  For 
> example, we have a few new roots that we expect to be using in the 
> next few months, and I need to make sure they're added to log servers 
> before I start using them.  If log server operators provide an service 
> level agreement (SLA) for such changes, that would be great.

I'm planning on publishing operator contact details in or near the log itself -- send an e-mail to the address in there and you'll get a response within the MMD.  Seem reasonable?

- Matt

--
You know you have a distributed system when the crash of a computer you’ve never heard of stops you from getting any work done.
		-- Leslie Lamport "Security Engineering: A Guide to Building
		   Dependable Distributed Systems"

_______________________________________________
Trans mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trans

---

From: Rick Andrews <[email-masked]>
Date: Fri, 18 Jul 2014 13:52:15 -0700

Matt, Jeremy,

Matt asked "Why would a root CA operator have added their root cert to a browser trust store if they weren't intending to issue trusted certificates?" Because we also issue client auth certificates, S/MIME certificates, code signing certificates, timestamping certificates, etc. If Google had filtered out just those roots without the "This certificate can identify websites" bit set, that would have eliminated a lot of the irrelevant roots.

Matt also asked "I'm planning on publishing operator contact details in or near the log itself -- send an e-mail to the address in there and you'll get a response within the MMD.  Seem reasonable?" Yes, definitely.

Jeremy, if we don't want to add our certs to a specific log, you're right that we can avoid using that log. But CT allows anyone (the CA, the owner of the cert, an interested party) to log any cert in any log server. By keeping all these roots in a log server, we're allowing any type of cert to be added to the log. We may get there someday, but that's not the intent for this first use of CT. We're focused on EV SSL certs. Let's not force monitors and auditors to wade through irrelevant certs.

-Rick

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Jeremy Rowley
Sent: Friday, July 18, 2014 1:32 PM
To: 'Matt Palmer'; [email-masked]'
Subject: Re: [Trans] List of Roots Accepted by Log Servers

Jeremy

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Matt Palmer
Sent: Friday, July 18, 2014 2:17 PM
To: [email-masked]
Subject: Re: [Trans] List of Roots Accepted by Log Servers

- Matt

---

From: Ben Laurie <[email-masked]>
Date: Fri, 18 Jul 2014 21:58:23 +0100

On 18 July 2014 19:11, Rick Andrews <[email-masked]> wrote:
> I finally got around to reading the list of roots accepted by the pilot and
> aviator log servers (using the get-roots command). I see a number of our
> roots that seem inappropriate to me, meaning that we have never issued SSL
> certs (EV or non-EV) from those roots, and never intend to. It seems to me
> that Google cast a wide net to add all relevant roots to kickstart the log
> servers (perhaps bootstrapped from Mozilla’s root list?), but at some point
> (before CT is “live”) I would like to see the list trimmed.

The list is the union of the roots accepted by popular browsers on
popular platforms.

> possible; ideally, when the log server refuses to give me an SCT. Is Google
> willing to remove roots from pilot and aviator?

Yes, it if makes sense.

> have a few new roots that we expect to be using in the next few months, and
> I need to make sure they’re added to log servers before I start using them.
> If log server operators provide an service level agreement (SLA) for such
> changes, that would be great.
>
> Comments?
>
> -Rick
>
>
>

---

From: Kurt Roeckx <[email-masked]>
Date: Fri, 18 Jul 2014 23:09:57 +0200

> My thinking is that if I somehow issue an SSL cert from a root that I did not intend to use for SSL, I would prefer to catch that as quickly as possible; ideally, when the log server refuses to giv…

It's my understanding that CT shouldn't only work for HTTPS, but
for all different kind of certificates.  Maybe you want a log that
only contains HTTPS, and have logs for different kind of
certificates?

Kurt

---

From: Jeremy Rowley <[email-masked]>
Date: Fri, 18 Jul 2014 21:15:47 +0000

Although CT could function for all types of certificates, Google doesn't necessarily utilize client or code signing certs.  Until other software vendors implement CT as a requirement, you'll likely only see CT used for SSL.  Plus, utilizing the logs only for SSL reduces log size.  Logging every client certificate issued will quickly fill up the log with less important information. 

Jeremy

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Kurt Roeckx
Sent: Friday, July 18, 2014 3:10 PM
To: Rick Andrews
Cc: [email-masked]
Subject: Re: [Trans] List of Roots Accepted by Log Servers

> My thinking is that if I somehow issue an SSL cert from a root that I did not intend to use for SSL, I would prefer to catch that as quickly as possible; ideally, when the log server refuses to giv…

It's my understanding that CT shouldn't only work for HTTPS, but for all different kind of certificates.  Maybe you want a log that only contains HTTPS, and have logs for different kind of certificates?

Kurt

---

From: "Mehner, Carl" <[email-masked]>
Date: Sat, 19 Jul 2014 00:12:04 +0000

Hi Rick,

I think that it might be best to have a glut of roots for now. This way, you (as a CA) can monitor the logs to see if anyone has issued a cert that could be valid for SSL off of any “inappropriate” root and I (as a host operator) can monitor to see if someone has issued anything off that (or any) root for our domain. At least until all the major browsers/platforms require CT for all SSL connections. Otherwise, someone could issue a cert for our domain that could be used for SSL transport of data between a server and a non-CT validating client (which I expect to remain in plentiful supply for several years).

On the other hand, even though it's predominantly for TLS, that is not the only thing that CT is useful for. I would not mind a window into who is issuing s/mime certs, code signing certs, and any number of other cert types for our domain in order to put a stop to issuance against our standards and policy. So perhaps casting the widest net of roots that, as Ben says, does not “suddenly become spammy” would be best. Although, as Jeremy pointed out, this could increase log size by quite a bit.

-carl

________________________________
From: Trans [[email-masked]] on behalf of Rick Andrews [[email-masked]]
Sent: Friday, July 18, 2014 1:11 PM
To: [email-masked]
Subject: EXTERNAL: [Trans] List of Roots Accepted by Log Servers

I finally got around to reading the list of roots accepted by the pilot and aviator log servers (using the get-roots command). I see a number of our roots that seem inappropriate to me, meaning that we have never issued SSL certs (EV or non-EV) from those roots, and never intend to. It seems to me that Google cast a wide net to add all relevant roots to kickstart the log servers (perhaps bootstrapped from Mozilla’s root list?), but at some point (before CT is “live”) I would like to see the list trimmed.

I think we need a somewhat formal way for CAs to provide log server operators their list of roots, and update that over time. For example, we have a few new roots that we expect to be using in the next few months, and I need to make sure they’re added to log servers before I start using them. If log server operators provide an service level agreement (SLA) for such changes, that would be great.

Comments?

-Rick

---

From: Rick Andrews <[email-masked]>
Date: Fri, 18 Jul 2014 18:02:44 -0700

Carl,

Unless I've lost control over my private keys, I don't need to monitor CT logs to see if anyone else has issued an SSL cert from one of my inappropriate roots. I can just look in my database.

Within the CA/Browser Forum, there's been a lot of discussion about how to define an SSL cert, but unfortunately every browser (and every non-browser app that acts as a TLS client) seems to have a different definition, and it doesn't seem likely that we'll ever reach consensus. My point is that for the moment, CT is a browser initiative, and one browser is building support for it. You're not alone in thinking that CT is useful beyond TLS; there's been a lot of discussion about where else it might be used. However, I think it's prudent to work out the kinks with a limited set of certs first, which is why I think Google decided to limit it to Chrome-based EV SSL for now.

-Rick

-----Original Message-----
From: Mehner, Carl [mailto:[email-masked]] 
Sent: Friday, July 18, 2014 5:12 PM
To: Rick Andrews; [email-masked]
Subject: RE: List of Roots Accepted by Log Servers

Hi Rick,

I think that it might be best to have a glut of roots for now. This way, you (as a CA) can monitor the logs to see if anyone has issued a cert that could be valid for SSL off of any "inappropriate" root and I (as a host operator) can monitor to see if someone has issued anything off that (or any) root for our domain. At least until all the major browsers/platforms require CT for all SSL connections. Otherwise, someone could issue a cert for our domain that could be used for SSL transport of data between a server and a non-CT validating client (which I expect to remain in plentiful supply for several years).

On the other hand, even though it's predominantly for TLS, that is not the only thing that CT is useful for. I would not mind a window into who is issuing s/mime certs, code signing certs, and any number of other cert types for our domain in order to put a stop to issuance against our standards and policy. So perhaps casting the widest net of roots that, as Ben says, does not "suddenly become spammy" would be best. Although, as Jeremy pointed out, this could increase log size by quite a bit.

-carl

Comments?

-Rick

---

From: Ben Laurie <[email-masked]>
Date: Sat, 19 Jul 2014 12:13:27 +0100

> I think that it might be best to have a glut of roots for now. This way, you (as a CA) can monitor the logs to see if anyone has issued a cert that could be valid for SSL off of any “inappropriate”…

Indeed, one of the nice things about CT (I think) is that it confers
some level of herd immunity, even for non-validating clients.

> On the other hand, even though it's predominantly for TLS, that is not the only thing that CT is useful for. I would not mind a window into who is issuing s/mime certs, code signing certs, and any…

Log size isn't inherently a problem, unless it becomes truly massive.
Each doubling adds a single hash to inclusion proofs. STH consistency
proof size is related to the growth in the log, and so doubling in
size would tend to also add a single hash to those (on average). The
main problem is for monitors, but even so, the size of logs we're
currently looking at are easily managed by monitors.

---

From: Ryan Hurst <[email-masked]>
Date: Fri, 18 Jul 2014 15:14:07 -0700

The transparency offered by CT has value outside of SS;, therefore I am interested in seeing the log services contain as much information about the WebPKI  ecosystem as possible. 

Of course nothing should require a log service operator to contain information they are not interested.

With that said this is outside the scope of the specification of CT protocol.

Ryan Hurst
@rmhrisk / [email-masked]
 
Sent from my iPhone

> On Jul 18, 2014, at 2:15 PM, Jeremy Rowley <[email-masked]> wrote:
>

---

From: Gervase Markham <[email-masked]>
Date: Mon, 21 Jul 2014 10:32:48 +0100

On 19/07/14 02:02, Rick Andrews wrote:
> Unless I've lost control over my private keys, I don't need to
> monitor CT logs to see if anyone else has issued an SSL cert from one
> of my inappropriate roots. I can just look in my database.

Not implying anything about your security, Rick, but one of the benefits
of CT is that people who don't realise that they've lost control of
their private keys can find out! :-)

Gerv

---

From: Rick Andrews <[email-masked]>
Date: Mon, 21 Jul 2014 08:08:13 -0700

True. The point I'm trying to make is that we're a long way from requiring SCTs for all types of certs, SSL and non-SSL. Until all applications require SCTs for all types of certs, I see no reason to add the complexity of logging all certs. At this point in time, Google wants SCTs for EV SSL certs, and that's what I'm shooting for. Chrome knows which roots are enabled for EV, and so those are the only roots that log servers MUST accept.

Other CAs might want to log all their certs. Relying parties might want to push every cert they see into log servers. But I see value in limiting which of my roots are accepted by log servers, and I'd like the ability to control that.

-Rick

-----Original Message-----
From: Gervase Markham [mailto:[email-masked]] 
Sent: Monday, July 21, 2014 2:33 AM
To: Rick Andrews; Mehner, Carl; [email-masked]
Subject: Re: [Trans] List of Roots Accepted by Log Servers

On 19/07/14 02:02, Rick Andrews wrote:
> Unless I've lost control over my private keys, I don't need to monitor 
> CT logs to see if anyone else has issued an SSL cert from one of my 
> inappropriate roots. I can just look in my database.

Not implying anything about your security, Rick, but one of the benefits of CT is that people who don't realise that they've lost control of their private keys can find out! :-)

Gerv

---

From: Kyle Hamilton <[email-masked]>
Date: Mon, 21 Jul 2014 12:59:59 -0700

Until there's adequate support in SCT for all types of certs, there is
no drive to add SCT to other protocols and clients.  Therefore, there
will never be a requirement for it.  Ultimately, the unwillingness to
support it now shall only guarantee that it will never be required.

But unless and until Google wants to step up and actively promote it, I
guess Google gets a lack of it.  Therefore, according to your argument,
Google now has de facto administrative control over Internet security
infrastructure administration and buildout.

Value might be perceived because of the lack of cost to modify *all* 
issuance systems to be on the same code base, as opposed to forking them
all.  However, as a reminder, forks increase maintenance cost and
decrease capacity, capability, and interoperability across multiple
systems -- particularly on previously-enabled systems that haven't yet
been fully brought into production.

-Kyle H

---

From: Jeremy Rowley <[email-masked]>
Date: Mon, 21 Jul 2014 20:44:29 +0000

Because of the differences in root program requirements, operational requirements, and verification needs, from my experience, most client and code signing systems already fork from the SSL cert systems.  Client certs are especially different in their issuance process. For most CAs, I imagine it's more work to add CT support for the three base certificate types than simply enable it for SSL.

Jeremy

From: Trans [mailto:[email-masked]] On Behalf Of Kyle Hamilton
Sent: Monday, July 21, 2014 2:00 PM
To: Rick Andrews; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Trans] List of Roots Accepted by Log Servers

-Kyle H

-Rick

-----Original Message-----

To: Rick Andrews; Mehner, Carl; [email-masked]<mailto:[email-masked]>

Gerv

Trans mailing list

[email-masked]<mailto:[email-masked]>

---

From: Eran Messeri <[email-masked]>
Date: Tue, 22 Jul 2014 17:34:13 +0100

To support what Jeremy and Rick said, I'll point out that it's entirely
possible to spin up multiple logs for different uses of X.509 certificates.
I understand that different X.509 certificates are used by different client
software, each kind of client software could use a different set of logs
(and these sets would be monitored differently depending on the
application).
Nothing prevents the logs to be based on the same software and
infrastructure.

Specifically:
* There's already a reference implementation for a CT log server as
open-source code (and we're working on a more robust version).
* Given Ben's interest in binary transparency and general transparency, I
believe he won't outright reject running extra logs for other cert types
(on Google's infrastructure).
* Code for general transparency service would allow running a transparency
log for arbitrary binary blobs. Ben may be able to share some details on
such an effort.

On Mon, Jul 21, 2014 at 9:44 PM, Jeremy Rowley <[email-masked]>
wrote:

>  Because of the differences in root program requirements, operational
> requirements, and verification needs, from my experience, most client and
> code signing systems already fork from the SSL cert systems.  Client certs
> are especially different in their issuance process. For most CAs, I imagine
> it’s more work to add CT support for the three base certificate types than
> simply enable it for SSL.
>
>
>
> Jeremy
>
>
>
> *From:* Trans [mailto:[email-masked]] *On Behalf Of *Kyle Hamilton
> *Sent:* Monday, July 21, 2014 2:00 PM
> *To:* Rick Andrews; [email-masked]; [email-masked]; [email-masked]
>
> *Subject:* Re: [Trans] List of Roots Accepted by Log Servers
>
>
>
> Value might be perceived because of the lack of cost to modify ****all**
>
> From: Gervase Markham [mailto:[email-masked] <[email-masked]>]
>