Skip to main content

Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-42

Note: This ballot was opened for revision 31 and is now closed.

Roman Danyliw Yes

Comment (2020-02-24 for -34)
(Adding a Yes ballot with comments on my own document as it was inherent during an AD change)

** Section 2.2 and 3.2.  Reference the IANA registry name, not just the document section

-- Section 2.2. Per “A log MUST use one of the signature algorithms defined in Section 10.3.”, recommend instead saying that the acceptable signature algorithms are defined in “the IANA ‘CT Signature Algorithms’ registry described in Section 10.3.

-- Section 3.2.  Per the digestAlgorithm “MUST be one of the hash algorithm OIDs listed in Section 10.2”, recommend instead saying “MUST be one of the hash algorithms OIDs listed in the IANA ‘CT Hash  Algorithms’ registry described in Section 10.2”.

** Section 4.13.  Per the list of guidance on shutting down a log following “[t]o avoid that, the following actions are suggested:”, should normative language be used in making this recommendation.  Perhaps “To avoid that the following actions are RECOMMENDED:” or “To avoid that the following actions SHOULD be taken:”?

** Section 4.13.  Per “Make it known to clients and monitors that the log will be frozen.”, I recommend clarifying that this is via some out-of-band/out-of-scope mechanism not defined in the Section 5.x API.

** Section 5.1, 5.3, 5.4, 5.6.  Each of these sections helpfully lists the possible errors given the action, however, the corresponding HTTP response codes is not clear.

** Section 11.3 and 11.4.  Do the following references to gossip still make sense since ietf-trans-gossip is not proceeding?
-- (Section 11.3) “There are various ways this could be done, for example via gossip (see [I-D.ietf-trans-gossip]) …”

-- (Section 11.4)  “Clients that gossip STH …”, if the gossip reference is removed, using this verb doesn’t make sense.

** Editorial nits:

-- Per “Various data structures Section 1.2 are signed”:
o s/Section 1.2/in Section 1.2/
o practically, there are no data structures in Section 1.2, only a reference to a presentation language of available data structures.

Alvaro Retana No Objection

Erik Kline No Objection

Comment (2021-06-20 for -39)
Thanks for this document.  Just a few random thoughts.

[S1.3] [nit]

* Consider expanding SCT and STH on first use.  Among other reasons, the
  RFC Editor Abbreviations List entry for SCT has multiple values (which
  one is intended seems obvious, but still...).

[S4.2.1] [nit]

* The first sentence reads like a bit of a run-on sentence to me. Perhaps:

  "To A, and to B, and to C, the log MUST..." ->
  "To A, to B, and to C, the log MUST..."

[S10.1.2] [comment]

* Not to start a bikeshed, but "trans" strikes me a bit generic for direct
  registration under ietf:params (I'd think it meant "transport" before I
  thought of "transparency", for example :-).

Martin Duke No Objection

Comment (2021-06-30 for -39)
Thanks for this document; I found it very interesting and enjoyed working through the Merkle Tree algorithms. Some non-blocking comments:

1. I have some concerns about the scalability of this proposal and the Log ID registry. If I understand correctly, there are at least two reasons an operator would choose to shut down their log and start a new one, which requires a new log ID: 

- to refresh the signature algorithm and/or key

- As certificates expire and are renewed over time, the log has to retain an ever-expanding listing of useless, expired certificates and chains. While the Merkle tree makes this computationally inexpensive, pruning the storage requirements would require a refresh.

Which is to say that log IDs should change quite frequently. I'm not very knowledgeable about the OID hierarchy, but it might be valuable for log IDs to have enough structure for a given provider to be given one tier of log IDs (e.g. 1.3.101.80.x.y, where "x" is assigned to an operator via IANA and "y" is a version number incremented by that operator).

2. Would it be valuable to have a new "certificate revoked" object type in logs that could provide some assurance that entries hadn't been revoked? I can think of some ways this might work, but am not familiar enough with the use cases to say if it'd be valuable.

3. One nit: 4.1.1 and 4.1.2 have broken markdown tags.

Murray Kucherawy (was Discuss) No Objection

Comment (2021-05-14 for -38)
Thanks for the extra work on the IANA Considerations section.  My DISCUSS (and Alexey's) points are all resolved.

Zaheduzzaman Sarker No Objection

Comment (2021-07-01 for -39)
Thanks for the efforts of this document.

I think it will be good to add section describing what is expected out of this experimental document. Shepherd's write up describes the intention of publishing this as Standard Track then WG decision to move it back to Experimental. I think it is worth capturing the thoughts and reasoning there and also set some expectations on this document for potential future reversions.

(Alexey Melnikov; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2019-03-14 for -31)
I think this is an important document and I am looking forward to seeing it as a Proposed Standard in the future.
However, it has a good number of editorial issues that make the document hard to read and implement.

5.  Log Client Messages

   type:  A URN reference identifying the problem.  To facilitate
      automated response to errors, this document defines a set of
      standard tokens for use in the "type" field, within the URN
      namespace of: "urn:ietf:params:trans:error:".

I think you need to register this in <https://www.iana.org/assignments/params/params.xhtml#params-1>

Also, can you clarify whether error need an IANA registry?

(Benjamin Kaduk; former steering group member) (was No Record, Discuss) Yes

Yes (2021-06-30 for -39)
I owe a sizeable apology to the authors and the WG for being rather
unresponsive to attempts to discuss my previous Discuss points.
I am sorry that I did not respond promptly (or, sometimes, at all) to
questions about this document.
Fortunately, the changes made to address my concerns have been
successful even in my absence, and I appreciate the efforts of the WG
members to push forward and make progress while I was not providing
feedback.

I made a pull request on github with some editorial-level suggestions:
https://github.com/google/certificate-transparency-rfcs/pull/337
and have only two other comments.

Section 10.2.2

"Expert Review" with instructions to the experts to ensure that there is
a public specification sounds basically equivalent to "Specification
Required".

Appendix B

I think we should actually use the 'id-mod-public-notary-v2' OID
allocated in Section 10.3 as the identifier for the module.

(Eric Rescorla; former steering group member) Yes

Yes (for -31)

                            

(Adam Roach; former steering group member) (was Discuss) No Objection

No Objection (2019-08-19 for -32)
Based on the discussion at IETF 105, and on the discussion on the
ART mailing list, it appears that there is at least weak support for
allowing a narrow carve out to BCP 190 regarding provisioned
directory prefixes in URLs. I'm therefore clearing my DISCUSS in
advance of an anticipated update to BCP 190 to reflect this carve
out. The initial DISCUSS is retained below for historical purposes.

---------------------------------------------------------------------------

Thanks to everyone who worked on updating this protocol to reflect experience
gathered from the initial CT protocol. I have one blocking comment, and a small
number of editorial suggestions.

---------------------------------------------------------------------------

§5:

>  Clients are configured with a base URL for a log and construct URLs
>  for requests by appending suffixes to this base URL.  This structure
>  places some degree of restriction on how log operators can deploy
>  these services, as noted in [RFC7320].  However, operational
>  experience with version 1 of this protocol has not indicated that
>  these restrictions are a problem in practice.

The synthesis of URLs by a protocol in this fashion is prohibited by BCP 190:

   Scheme definitions define the presence, format, and semantics of a
   path component in URIs; all other specifications MUST NOT constrain,
   or define the structure or the semantics for any path component.

Unless the intention of this document is to update BCP 190 to change this
normative requirement, we can't publish it in its current form. Note that doing
so would require a change of venue, as updates to BCP 190 would not be covered
by the current TRANS charter.

Please see BCP 190 section 3 for alternate approaches. All three approaches
could be made to work for CT, and I would be happy to explain how to do so if
clarification is desired.

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

Consider using the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§1.3:

>  This document revises and obsoletes the experimental CT 1.0 [RFC6962]
>  protocol, drawing on insights gained from CT 1.0 deployments and on
>  feedback from the community.

Given that *this* document is also experimental, it seems a bit odd to call out
RFC 6962 as experimental.

---------------------------------------------------------------------------

§2.1.1:

>  We have established a registry of acceptable hash algorithms (see

The use of first person here is awkward. Consider: "This document
establishes..."

---------------------------------------------------------------------------

§10.2:

>  | 0x01 - | Unassigned |                        | Specification      |
>  | 0xDF   |            |                        | Required and       |
>  |        |            |                        | Expert Review      |

The policy being cited here is confusing. It is unclear whether the intention is
that values can be registered under both §4.5 and §4.6 of RFC 8126. I suspect
the intention here is the policy specified in RFC 8126 §4.6 only, without
reference to the policy in §4.5. If so, please use the formal name
"Specification Required."

---------------------------------------------------------------------------

§10.4:

>  | 0x0008 -    | Unassigned           | Specification Required and   |
>  | 0xDFFF      |                      | Expert Review                |

Same comment as above.

---------------------------------------------------------------------------

§10.5:

>  | 0x0000 -      | Unassigned | n/a | Specification Required and     |
>  | 0xDFFF        |            |     | Expert Review                  |

Same comment as above.

(Alissa Cooper; former steering group member) (was Discuss) No Objection

No Objection (2019-09-27 for -33)
Thanks for addressing my DISCUSS.

(Mirja Kühlewind; former steering group member) (was Discuss) No Objection

No Objection (2020-02-25 for -34)
Thanks for addressing my discuss and adding some more text in the security consideration section!

I believe all comments below are still valid, expect 2 which is a nit that was fixed. I would really like to see some recommendations on point 5 before this document moves on!

 1) I found section 2 a bit hard to follow. Would it maybe be possible to provide more textual explanation of the algorithms instead of just describing the steps of the algorithms? Also I was wondering how much much these algorithms are actually „part“ of the protocol spec…? Are could these be rather seen as example algorithms? Maybe that could be further clarified

 2) Please expand STH on first occurrence (in sec 4.1)

 3) Sec 4.4: „A log's operator MUST either allocate the OID
    themselves or request an OID from the Log ID Registry (see
    Section 10.6.1).“
Isn't there an obligation to register?

 4) sec 4.8: „If an
   implementation sees an extension that it does not understand, it
   SHOULD ignore that extension.“
Maybe it’s just me because I may have missed some context but does „ignore“ mean here that it should log it or not?

 5) sec 5: „MAY retry the same
   request without modification at a later date.“
Would it be possible to provide a recommendation how long the client should wait?
 
 6) sec 5.6: „Logs MAY restrict the number of entries that can be retrieved per
   "get-entries" request.“
Should this be added to sec 4.1?

 7) sec 10.3: Couldn’t you use the TLS  SignatureScheme Registry directly (instead of forming an own registry)?

 8) sec 10.4: i Wonder if an RFC-required policy wouldn’t be more appropriate for the VersionedTransTypes registry?

 9) sec 10.6.1:I guess  the registration policy is FCFS? RFC 8126 recommend to always (clearly) name the registry.

And finally one higher level question mainly out of curiosity: was it considered to e.g. use json for all data structures? Is there a performance reason to not do that or wasn’t that even discussed?