Glad to see this revision of the protocol. My comments and questions should be easy to address.

= Section 10.2, 10.4, 10.5 =

A Specification Required registry policy implies expert review. So a registry policy of "Specification Required and Expert Review" is duplicative; it should just say "Specification Required." I know this seems trivial but there has been so much confusion about this through the years that it is important to be precise.

= Section 10.3 =

This section needs to state what the registry policy is for the code points not already registered (presumably Expert Review given 10.3.1, but it needs to be explicit).

= Section 10.6.1 =

Using the term "Parameters Required" as a capitalized term is confusing. FCFS registries by definition can require additional information to be provided in order to get something registered. For avoidance of confusion I think the assignment policy should be listed as First Come First Served and the requirement that parameters be included in the application can use a normative MUST in the last paragraph if there is concern that the parameters won't be supplied.

However, I also wonder what will be done with the parameters that are supplied. Is IANA expected to just maintain them privately, or to publish them?

What is expected to appear in the 'Log' column in the registry?

In Section 1.1, please use the RFC 8174 boilerplate in lieu of the RFC 2119 boilerplate.

First off, thanks for this well-written document!  I intend to ballot Yes,
but there are a few issues that need to be resolved first.

Sections 4.11 and 4.12 have arrays of NodeHash to carry consistency and
inclusion proofs, respectively, with minimum array size of 1.  However,
Sections 2.1.4.1 and 2.1.3.1 (respectively) seem to admit the
possibility of zero-length proofs in degenerate cases, which the
aforementioned protocol description language forbids the conveyance of.
(Section 5.3 explicitly requires the use of an empty consistency proof.)
Do those minimum array sizes need to be (implicit) zero?
(If they do not, it seems that a minimum size of 32 would have the same
effect as that of one, since a NodeHash has minimum size 32.)

I support Alexey's Discuss regarding the registration of a
"urn:ietf:params:trans:error" URN namespace.

In Section 6:

   o  An Online Certificate Status Protocol (OCSP) [RFC6960] response
      extension (see Section 7.1.1), where the OCSP response is provided
      in the "CertificateStatus" message, provided that the TLS client
      included the "status_request" extension in the (extended)
      "ClientHello" (Section 8 of [RFC6066]).  [...]

This is not quite a TLS 1.3-compliant formulation -- TLS 1.3 does not
use the "CertificateStatus message", but rather uses the encoding of
that structure in a status_request extension in the CertificateEntry.

I also think we need greater clarity on the (non-)usage of CT for TLS
client certificates; see COMMENT

I also support Alissa's Discuss.

Since the 64-bit timestamp format (milliseconds since epoch) is used in
multiple places, there is perhaps room for consolidation into a single
definition.

Section 1

Do we need to provide a definition or reference for "public
certification authority"?

   It is necessary to treat each log as a trusted third party, because
   the log auditing mechanisms described in this document can be
   circumvented by a misbehaving log that shows different, inconsistent
   views of itself to different clients.  Whilst it is anticipated that
   additional mechanisms could be developed to address these
   shortcomings and thereby avoid the need to blindly trust logs, such
   mechanisms are outside the scope of this document.

Doesn't Section 11.3 discuss/link to some (partial) mechanisms to detect
misbehaving logs?  It's not clear that "anticipated" is quite the right
terminology to use here, then...

Section 2.1.1

   We have established a registry of acceptable hash algorithms (see
   Section 10.2).  [...]

It's not clear that we need to use the first person here.

Section 2.1.2

   When a client has a complete list of n input "entries" from "0" up to
   "tree_size - 1" and wishes to verify this list against a tree head
   "root_hash" returned by the log for the same "tree_size", the
   following algorithm may be used:

This seems to imply that n equals "tree_size"; do we want to normalize
to one name or the other?

   3.  If there is more than one element in the "stack", repeat the same
       merge procedure (Step 2.3 above) until only a single element
       remains.

nit: we just want the sub-sub-bullets of 2.3, and not the "repeat
merge_count times" part, since "merge_count" is not defined in this
scope?

Section 2.1.3.2

IMPORTANT: We need to define/specify what "leaf_index" is.

Section 2.1.4.1

   SUBPROOF(m, D[m], true) = {}

I don't remember seeing the "D[m]" notation defined; is this a typo for
something else?

   If m <= k, the right subtree entries D[k:n] only exist in the current
   tree.  We prove that the left subtree entries D[0:k] are consistent
   and add a commitment to D[k:n]:

   SUBPROOF(m, D_n, b) = SUBPROOF(m, D[0:k], b) : MTH(D[k:n])

This 'b' is always 'false', right?

Section 2.2

   Various data structures Section 1.2 are signed.  A log MUST use one
   of the signature algorithms defined in Section 10.3.

A literal reading of this forbids any algorithms registered in the
future but not listed in this document; we probably want to say "listed
in the registry defined in".

Section 3.2

   o  "SignedData.digestAlgorithms" MUST only include the
      "SignerInfo.digestAlgorithm" OID value (see below).

nit: this could be misread as saying that there is a single
distinguished OID that has symbolic name "SingerInfo.digestAlgorithm";
we just want this one to match the one in the SignerInfo in the
SignedData.signerInfos, so maybe something about "same as" would avoid
the ambiguity.

Section 4.1

   Maximum Chain Length:  The longest chain submission the log is
      willing to accept, if the log imposes any limit.

Is the absence of a limit indicated by the absence of the parameter or a
distinguished sentinel value?

   Final STH:  If a log has been closed down (i.e., no longer accepts
      new entries), existing entries may still be valid.  In this case,
      the client should know the final valid STH in the log to ensure no
      new entries can be added without detection.  The final STH should
      be provided in the form of a TransItem of type
      "signed_tree_head_v2".

Is this a lowercase "should" or a "SHOULD" or a "MUST"?  (How else would
it be provided?)

Do we need to say that the Final STH is not provided for a log that is
still accepting submissions?

Section 4.4

   Note that the ASN.1 length and the opaque vector length are identical
   in size (1 byte) and value, so the DER encoding of the OID can be
   reproduced simply by prepending an OBJECT IDENTIFIER tag (0x06) to
   the opaque vector length and contents.

nit: maybe "full DER encoding (including tag and length)" to contrast
with the previous paragraph?

   OIDs used to identify logs are limited such that the DER encoding of
   their value is less than or equal to 127 octets.

This seems to be a new requirement to this spec, in which case RFC 2119
language would be appropriate?

Section 4.7

   "sct_extensions" matches the SCT extensions of the corresponding SCT.

Is this supposed to imply the ordering and non-duplication requirements?
(If it does not, then recreating the log entry from the SCT for
signature validation could prove difficult.)

Sections 4.9, 4.10

Do we really want to allow for zero-length signatures in the structure
definition?

Section 4.11

   "consistency_path" is a vector of Merkle Tree nodes proving the
   consistency of two STHs.

A backreference to Section 2.1.4 might be helpful.

Section 4.12

   "inclusion_path" is a vector of Merkle Tree nodes proving the
   inclusion of the chosen certificate or precertificate.

A backreference to Section 2.1.3 might be helpful.

Section 5

Sometimes documents using base64 note explicitly that the padding
characters are (or aren't) included; 4648 is fairly clear that the
default is to include the padding characters, so there isn't necessarily
any change needed here.

Section 5.1

      chain:  An array of zero or more base64 encoded CA certificates.
         The first element is the certifier of the "submission"; the
         second certifies the first; etc.  The last element of "chain"
         (or, if "chain" is an empty array, the "submission") is
         certified by an accepted trust anchor.

I'm reading this to be a JSON array of strings; is that correct, and do
we want to be more explicit about it ("no" may well be fine)?

   If "submission" is an accepted trust anchor whose certifier is
   neither an accepted trust anchor nor the first element of "chain",
   then the log MUST return the "unknown anchor" error.  A log cannot
   generate an SCT for a submission if it does not have access to the
   issuer's public key.

Is this a descriptive "cannot" or a normative "MUST NOT"?

   If the returned "sct" is intended to be provided to TLS clients, then
   "sth" and "inclusion" (if returned) SHOULD also be provided to TLS
   clients (e.g., if "type" was 2 (for "precert_sct_v2") then all three
   "TransItem"s could be embedded in the certificate).

nit: the grammar is a bit weird around the second "then", maybe ", so
that" is easier to read?

Section 5.4

IMPORTANT: The input to get-proof-by-hash has a "tree_size" but the
processing discussion refers to a single "requested STH".  It does not
seem like the one uniquely determines the other, since there could be
multiple valid STHs for a given tree size (e.g., if there are no
submissions for more than the MMD).  Is the intent to supply an STH as
input, or is there otherwise need for further clarity here?

      inclusion:  A base64 encoded "TransItem" of type
         "inclusion_proof_v2" whose "inclusion_path" array of Merkle
         Tree nodes proves the inclusion of the chosen certificate in
         the selected STH.

We don't seem to define "chosen certificate"; do we just want to refer
to the (input) leaf hash?

Section 5.5

[similar note about tree_size/STH mapping]

Similarly, we talk about "index of requested hash", which is at least
unambiguous (IIUC), but we don't give a description of how the server
could/should determine.

[same comment about "chosen certificate"]

Section 5.6

         submitted_entry:  JSON object representing the inputs that were
            submitted to "submit-entry", with the addition of the trust

What does "representing" mean?  (In particular, does it use the same
JSON structure?)

Section 5.7

There is not a note here about how no signature is required on the
results, and in fact this data does seem to only be authenticated by the
surrounding TLS connection.  Perhaps it's worth making a note of that.

Section 6

   CT-using TLS servers MUST use at least one of the three mechanisms
   listed below to present one or more SCTs from one or more logs to
   each TLS client during full TLS handshakes, where each SCT

This MUST may need some caveats, given that the server can't use TLS
extensions not offered first by the client.  So maybe it has to be
"each CT-using TLS client".

Section 6.1

   o  One or more logs may not have become acceptable to all CT-using
      TLS clients.

nit: are we concerned about (new?) logs potentially becoming acceptable
to clients, or logs acceptable to clients becoming no longer accepted
(or both)?

Section 6.3

   In each "TransItemList" that is sent to a client during a TLS

nit: I don't know that "to a client" is needed; the server can just as
well use CT for client certificates, right?

   o  The TLS server MUST construct a "TransItemList" of relevant
      "TransItem"s (see Section 6.3), which SHOULD omit any "TransItem"s
      that are already embedded in the server certificate or the stapled
      OCSP response (see Section 7.1).  If the constructed
      "TransItemList" is not empty, then the TLS server MUST include the
      "transparency_info" extension with the "extension_data" set to
      this "TransItemList".

Am I allowed to send an empty "transparency_info" extension if the
TransItemList is empty?

   TLS servers MUST only include this extension in the following
   messages:

   o  the ServerHello message (for TLS 1.2 or earlier).

   o  the Certificate or CertificateRequest message (for TLS 1.3).

Servers sending it in CR implies that clients can send it in Certificate
(heh, the normal "CT" abbreviation is not really usable in this
context), but we don't explicitly say that.

Section 10.3

I'm confused by this registry.  Is the SignatureScheme value required to
come from/match the TLS SignatureScheme registry?  Is anything going to
key off that value or otherwise use the value in a protocol data
structure?  (Why are there two entries for 0x0403?)

Section 10.5

   All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been
   reserved.  This is a limited resource of 8,192 OIDs, each of which
   has an encoded length of 4 octets.

The table says "Unassigned"; which is it?

Section 11.1

This seems to be making some unstated assumptions, including perhaps
that someone has actually submitted the misissued certificate in
question to a log (in order to support the claim that the maximum time
it can be used without audit is twice the MMD).

Section 11.3

We may want to note the potential privacy concerns relating to gossip
and similar mechanisms, at least in passing.  I do see Section 11.4,
though there's not a terribly tight linkage in the text, and 11.4 may
not have comprehensive coverage of all privacy considerations.

Section 13.2

I think that RFCs 6234 and 6979 may need to be normative, since they're
needed for the signature/hash algorithms that are specified for use.

There was a presentation at maprg IETF 103 about the question if CT helps attackers to find new domains. I think this risk should at least be mentioned in the security considerations section.

 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?

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?

General:

STH is only defined in the table of Content! Please define it early in the document (before the "Changes since v1" section), so that it would be easier to understand for somebody who is new to this.

"LSB" is never defined.

It might be just me, but I don't know what is the meaning of the ":" operation for an expression "A : B" outside of an index.

DER encoding needs a Normative Reference.

TLS 1.2 needs at least an Informative Reference.



In 4.1: URL needs a reference.

In 4.1:
 What is the typical resolution for Maximum Merge Delay? 10 seconds? 20 minutes?

In 4.3:

   This prevents the CA from avoiding blame by logging a partial or empty chain.

"prevents the CA from avoiding blame" reads very awkwardly, maybe rephrase?

4.4.  Log ID

   Each log is identified by an OID, which is one of the log's
   parameters (see Section 4.1) and which MUST NOT be used to identify
   any other log.  A log's operator MUST either allocate the OID
   themselves or request an OID from the Log ID Registry (see
   Section 10.6.1).  Various data structures include the DER encoding of
   this OID, excluding the ASN.1 tag and length bytes,

OID encoding in DER really needs a normative reference.

5.  Log Client Messages

   Messages are sent as HTTPS GET or POST requests.  Parameters for
   POSTs and all responses are encoded as JavaScript Object Notation
   (JSON) objects [RFC8259].  Parameters for GETs are encoded as order-
   independent key/value URL parameters, using the "application/x-www-
   form-urlencoded" format described in the "HTML 4.01 Specification"
   [HTML401].  Binary data is base64 encoded [RFC4648] as specified in

Please clarify whether you are using Section 4 or Section 5 version of base64.
Also, are the trailing "=" expected in values?

   the individual messages.


   Note that JSON objects and URL parameters may contain fields not
   specified here.  These extra fields SHOULD be ignored.

Why not "MUST be ignored"? This is important for forward compatibility.



8.1.6.  Evaluating compliance

   A TLS client can only evaluate compliance if it has given the TLS
   server the opportunity to send SCTs and inclusion proofs by any of
   the three mechanisms that are mandatory to implement for CT-using TLS
   clients (see Section 8.1.1).  Therefore, a TLS client MUST NOT
   evaluate compliance if it did not include both the

Maybe "evaluate" above is a wrong verb, I think "enforce" would be better here.

   "transparency_info" and "status_request" TLS extensions in the
   ClientHello.


8.2.  Monitor

   1.  Fetch the current STH (Section 5.2).  Repeat until the STH
       changes.

I think the above text should recommend how often the client should poll for this.

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.