Overall comments
The correct expansion of the acronym CA is certification authority, not
certificate authority. I believe I noted this typo in my comments months
ago. I won’t cite each instance of it the document.
There are a number of instances where the document cites normative
references, but the cited documents appear as informative references in
Section 10.2
**
**
**
*Abstract*
Reword the opening sentence; it’s five lines long!
*1. Informal Introduction*
Why is this still an “informal” introduction? Doesn’t a standards track
RFC deserve a real introduction :-)?
public CAs -> Web PKI CAs? (since the scope, is TLS)
each chain is rooted in a CA certificate … -> each chain terminates with
a certificate verifiable under a CA certificate …
“provide evidence to TLS clients that the chain has been submitted …”
just TLS clients, not monitors?
The text still talks about TLS clients requiring that all certificates
they accept having been logged.Since TLS client behavior is out of
scope, this statement, which motivates the use of logs, is out of scope
as well. (we can’t have it both ways, i.e., defer definitive statement
about client behavior and then cite such behavior as a motivation for
the proposed mechanism.)
This section still discusses monitoring of logs, but defers
specification of exactly how that monitoring is performed. Again, if
monitor behavior is out of scope for this document, it is inappropriate
to make vague statements about how such behavior justifies the
development of a specification for logs.
The phrase “domains for which they are responsible” is vague. It
suggests an attempt to convey how monitoring works, while deferring the
real definition to another document.
“The checking operation is asynchronous to allow TLS connections to
proceed …” The reference to asynchronicity suggests that this is
describing TLS client behavior, which is out of scope.
The last paragraph in this section asserts that it is efficient for
(unspecified parties, formerly known as Auditors) to detect log
misbehavior, but does not provide evidence that such detection is, in
fact, efficient.
This section refers to certificate mis-issuance, yet defines it
nowhere.Since mitigating problems caused by mis-issued certificates is
the rationale cited for CT, this omission is serious. And, I note, that
I have offered text to define this term.
*2. Cryptographic Components*
As I noted in my initial review of 6269-bis, I think most of the text in
2.1.1-3 belongs in an appendix.
It is common practice in the IETF today to place crypto algorithm specs
in a separate document, to better accommodate changes to such specs in
the future. This suggests removing the specs of hash and signature
algorithms from 2.1.4. There also is a need to describe how changes to
the algorithms will be accommodated by CT.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
