1) "Gossiping in CT" is intended for publication as an
Experimental Standard. We opted for Experimental because we
suspect that there may be other approaches to gossiping CT
data structures that will work as well, and we need more
experience with this gossip protocol to develop confidence
in it.
2) Document announcement:
Technical summary
The logs in Certificate Transparency are untrusted in the sense that
the users of the system don't have to trust that they behave
correctly since the behavior of a log can be verified to be correct.
This document tries to solve the problem with logs presenting a
"split view" of their operations. It describes three gossiping
mechanisms for Certificate Transparency: SCT Feedback, STH
Pollination and Trusted Auditor Relationship.
Working group summary
The only concern expressed during last call on this
document was that while there was no substantive
disagreement with the contents of this document, there
was also not much interest expressed. However, there are
several implementations underway, and there was consensus
that under the circumstances it is appropriate to
progress the document towards publication as an
experimental standard.
Document quality
There are several implementations in progress. We have
not heard of vendor plans to deploy the protocol. Again,
this is why we chose to request publication as an
experimental standard.
Personnel
Document shepherd: Melinda Shore
Responsible AD: Stephen Farrell
3) The document shepherd is also the working group co-chair
and has been reviewing the document since before adoption as
a working group deliverable. This version is mature and
stable, and is ready for publication.
4) No concerns.
5) No portion of the document needs cross-area or
outside review.
6) The IETF has traditionally avoided taking on work on what
are essentially distributed computing problems, such as
gossip protocols. homenet published a consensus protocol
recently (RFC 7787) but it is still somewhat unusual. Also,
it has just recently been brought to attention that trans
documents do not conform to the recommendations regarding
URI structure described in BCP 190.
7) Yes, each author has confirmed that any IPR disclosures
(would) have been filed.
8) There are no IPR disclosures associated with this
document.
9) There is no technical disagreement with the content of
this document. The only concern expressed by working group
participants is that there is not universal enthusiasm for
it, although there is consensus that it is appropriate to
publish it as an experimental standard.
10) There are no threats of appeal.
11) There is a missing reference to RFC 2110, and there are
some "weird spaces" in some of the diagrams. The nits
checker incorrectly interprets some message numbers in
diagrams as references. There are 39 too-long lines, and 4
instances of non-RFC2606-compliant FQDNs. These will be
corrected prior to publication.
12) This document does not require MIB doctor, URI type, or
media type reviews.
13) All references have been identified as normative or
informative.
14) There is a normative reference to a document which has
not been published (rfc6962-bis). That document is the core
working group deliverable and is close to completing working
group last call.
15) There are no normative downward references.
16) This document will not change the publication status of
any existing RFCs.
17) There are no IANA considerations. The "IANA
Considerations" section has been [TBD]-ed in.
18) There are no new IANA registries.
19) The pseudocode has been given a manual review by the
document shepherd. The JSON framework given in the document
is not quite correct, as the strings are demarked by single
quotes rather than double. This will be corrected prior to
publication.