Now we've completed WGLC for 6962-bis, I'd like to pick this thread back up again.
Several different public CT monitoring services now exist (crt.sh, Cert Spotter, Censys.io, etc). ISTM that it would be useful to define a common API that could be implemented by each monitor, so that end-users don't have to implement multiple APIs in order to talk to multiple monitors. Matt Palmer and I made a start on a (very drafty) draft a while ago: https://github.com/tobermorytech/ct-monitor-api-rfc/blob/master/draft-palmer-ct-monitor-api.md Who's interested in working on this? On 12/06/15 18:34, Stephen Kent wrote: > Rob, > >> On 11/06/15 22:40, Stephen Kent wrote: >>> Rob, >>> >>>> 6962-bis notes that: >>>> "Those who are concerned about misissue can monitor the logs, asking >>>> them regularly for all new entries, and can thus check whether >>>> domains they are responsible for have had certificates issued that >>>> they did not expect." >>>> >>>> If you act as a monitor yourself, you can be sure that the logs you're >>>> monitoring aren't misbehaving. You don't have to trust the logs. >>> >>> I'm not sure I follow your argument above. >> <snip> >> >> Hi Steve. I was aiming for a quick summary rather than a >> fully-specified problem statement. You're correct that the audit role >> is vital too. >> >> If the CT ecosystem is functioning as intended, then a monitor can be >> sure that they've seen every logged cert, without having to trust the >> log. > yes. >> >> But a client of a monitor has to trust the monitor. > agreed. >> >> Is that any clearer? > yes. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
