On 10/06/15 01:54, Matt Palmer wrote:
On Tue, Jun 09, 2015 at 10:44:58AM +0100, Rob Stradling wrote:
On 09/06/15 04:05, Clint Wilson wrote:
To further support your claims here, Chris, there are already tools coming out
which actively monitor domains in CT logs and can be set up with notifications
of misissuance:
https://www.digicert.com/certificate-monitoring/
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/EPv_u9V06n0
This type of tool for CT is only going to improve with time.
So I'm wondering if the TRANS WG should think about standardizing a JSON API
for searching CT logs and for setting up notifications of (mis-)issuance.
The server side of this API could be implemented by services such as
https://crt.sh or even directly by the logs themselves.
For logs themselves, as a requirement for *being* a log? No.
Fully agree.
A log has a single well-defined purpose, and I don't think that adding
independent
functionality to the purpose of the log itself is a winning strategy.
Indeed. A log and a monitor are separate software components.
Sorry I was unclear. I was imagining that a provider might want to
provide both a log and a monitor for that log, running from the same
server, using a shared database. (IMHO, we shouldn't require this, but
we shouldn't prohibit it either).
An API for querying the CT-relevant data for a collection of certificates...
*that* would probably be quite useful.
:-)
BTW, you probably won't be surprised to hear that I've been trying to think
of reasons to create a shell script called "crt.sh". ;-)
Nope, not particularly surprised.
:-)
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
