Subject: [Trans] Proposal: Moving optional methods from 6962-bis to monitoring API draft

From: Eran Messeri <[email-masked]>
Date: Thu, 17 Nov 2016 17:44:30 +0900

I'd like to see if there's any objection to moving two optional methods
from 6962-bis to the monitoring API draft:
* get-entry-for-sct
<https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-20#section-7.1>
* get-entry-for-tbscertificate
<https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-20#section-7.2>

These were added at a late stage by Ben, are not essential to the protocol
and would be very suitable for a monitor.

It is possible for logs to implement these methods under the same namespace
of the log (so in effect it would behave exactly as if they were defined in
6962-bis):

   - Add an optional parameter for specifying the Log ID requests refers to
   was added.
   - Logs that implement these methods would not require the Log ID
   parameter and would simply reply with data from their tree.
   - Monitors that implement these methods would require the Log ID
   parameter and would reply with data from multiple logs (output is keyed by
   Log ID).

The same thing can be applied to the proposed get-sths method which, as
decided, would live in a monitoring API document, so the three methods form
the base of the monitoring API draft.

PR for removing the methods:
https://github.com/google/certificate-transparency-rfcs/pull/204
PR adding the monitoring API draft:
https://github.com/google/certificate-transparency-rfcs/pull/203

Regards,
Eran

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Nov 2016 03:55:52 -0500 (EST)

On Thu, 17 Nov 2016, Eran Messeri wrote:

> I'd like to see if there's any objection to moving two optional methods from 6962-bis to the monitoring API draft:* get-entry-for-sct
> These were added at a late stage by Ben, are not essential to the protocol and would be very suitable for a monitor.
> 
> It is possible for logs to implement these methods under the same namespace of the log (so in effect it would behave exactly as if they were defined in
> 6962-bis):
>  *  Add an optional parameter for specifying the Log ID requests refers to was added.
>  *  Logs that implement these methods would not require the Log ID parameter and would simply reply with data from their tree.
>  *  Monitors that implement these methods would require the Log ID parameter and would reply with data from multiple logs (output is keyed by Log ID).
> The same thing can be applied to the proposed get-sths method which, as decided, would live in a monitoring API document, so the three methods form the
> base of the monitoring API draft.
> 
> PR for removing the methods: https://github.com/google/certificate-transparency-rfcs/pull/204
> PR adding the monitoring API draft: https://github.com/google/certificate-transparency-rfcs/pull/203

If anyone objects to this change, please let us know ASAP.

Paul

---

From: Matt Palmer <[email-masked]>
Date: Fri, 18 Nov 2016 09:25:06 +1100

> If anyone objects to this change, please let us know ASAP.

I object to the introduction from the existing monitor API draft RFC
(https://github.com/tobermorytech/ct-monitor-api-rfc/blob/master/draft-palmer-ct-monitor-api.md)
being lifted, wholesale, without credit.

- Matt

---

From: Eran Messeri <[email-masked]>
Date: Fri, 18 Nov 2016 09:46:21 +0900

Sincere apologies - this text (and some other leftovers) weren't intended
to be in this pull request.
I've removed it - hopefully it could be re-introduced later with proper
credits and permission, once these are sorted.

Eran

On Fri, Nov 18, 2016 at 7:25 AM, Matt Palmer <[email-masked]> wrote:

> (https://github.com/tobermorytech/ct-monitor-api-
> rfc/blob/master/draft-palmer-ct-monitor-api.md)
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>