Adding 1st draft of monitoring api. #203
Conversation
|
|
||
| It is possible the server will not have any STHs between start and end. In this case it MUST return an empty sths array. | ||
|
|
||
| When implemented by a log, the log_id parameter SHALL be ommitted by clients and ignored by the log. |
There was a problem hiding this comment.
What does it mean for a subset of APIs that are part of the monitoring role to be implemented by a log server?
I'm a bit concerned that this blurring of boundaries is going to make writing interoperable tools harder rather than easier.
|
|
||
| # Monitoring V1 and V2 logs concurrently | ||
|
|
||
| Does it make sense for monitors to monitor V1 and V2 logs at the same time? |
There was a problem hiding this comment.
My inclination is to say yes.
In that case do you anticipate there being a set of /ct/v1 APIs described in this doc as well?
There was a problem hiding this comment.
The implication of the answer being 'no' is that we end up pushing the need to know the distinction between CT v1 and v2 further outwards towards the clients who want to eg. query certificates issued against their domain. I suspect that many such clients don't care for the distinction, and would be better served by a monitoring API that provides access to data ingested from both v1 and v2 CT logs.
|
|
||
| --- abstract | ||
|
|
||
| This document describes a protocol for publicly logging the existence of |
There was a problem hiding this comment.
This paragraph looks like it wants re-writing to focus on monitors.
|
|
||
| An important component of the Certificate Transparency ecosystem is that of the "monitor", a service which examines the entries made in Certificate Transparency logs and reports on anomalies. They provide an important link between the bulk data contained within logs, and end users who need to know about what the logs contain. | ||
|
|
||
| In order to benefit fully from the functionality provided by logs, it is useful that monitors can be accessed programmatically. Further, it is a benefit to end users if they can interact with multiple independent monitors using the same client code, without having to write customised programs for each monitor they wish to interact with. |
| Data structures are defined according to the conventions laid out in Section 4 | ||
| of [RFC5246]. | ||
|
|
||
| # Monitor operation |
|
|
||
| # Monitor Messages | ||
|
|
||
| These are APIs monitors SHOULD implement. |
There was a problem hiding this comment.
You might TODO in here that this is very far from being a fully thought-out list and is initially a holding place for APIs being removed from the Log RFC.
How does this relate to the monitoring requirements capture going on here: https://github.com/tobermorytech/ct-monitor-api-rfc/blob/master/draft-palmer-ct-monitor-api.md
| Note that any SCT signed by a log must have a corresponding entry in the log, | ||
| but it may not be retrievable until the MMD has passed since the SCT was issued. | ||
|
|
||
| If the log_id input parameter is ommitted, the log SHALL return entries from all |
There was a problem hiding this comment.
the log SHALL ... > the monitor SHALL
| entry. If the certificate is present in the log, then the monitor MUST return at | ||
| least one entry index. | ||
|
|
||
| If the log_id input parameter is ommitted, the log SHALL return entries from all |
There was a problem hiding this comment.
s/the log SHALL/the monitor SHALL/
This is a very, very rough 1st draft of the monitoring API.
I've created it so that I have somewhere to put the methods I'd like to remove from 6962-bis.