Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-34
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Benjamin Kaduk Discuss
Discuss (2019-03-14 for -31)
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.Comment (2019-03-14 for -31)
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.Murray Kucherawy Discuss
Discuss (2020-04-05)
Preserving Alexey's DISCUSS position...
Comment (2020-04-05)
No email
send info
send info
...and his comments.
(Alexey Melnikov) Discuss
Discuss (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?Comment (2019-03-14 for -31)
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.Roman Danyliw Yes
Comment (2020-02-24)
(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.
(Eric Rescorla) Yes
Alissa Cooper (was Discuss) No Objection
Comment (2019-09-27 for -33)
Thanks for addressing my DISCUSS.
(Mirja Kühlewind) (was Discuss) No Objection
Comment (2020-02-25)
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?Alvaro Retana No Objection
(Adam Roach) (was Discuss) No Objection
Comment (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.