In general, if you want us to remember to do something about your comments, you need to open or update Trac tickets (discussion here before doing so is fine, of course).
On 5 March 2015 at 21:39, Stephen Kent <[email protected]> wrote: > 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. > I have just done this, so no need to open a ticket. > > > There are a number of instances where the document cites normative > references, but the cited documents appear as informative references in > Section 10.2 > And I am doing this right now, so again, no need for a ticket. > > > > > > > *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 :-)? > It is informal in that the treatment of the subject is informal. The remainder of the RFC is the formal part. > > > 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. > However, the remainder of the document does. If we turn the introduction into a formal treatment, it becomes the whole document. And then we need to write a new introduction. > > > 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. > This point has already been addressed in the next version of the I-D. > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
