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"
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
