[debc] I’ve cut anything that I agreed with. General: Remove the references to the Notes in Sections 2 and 3. They will stand alone.
[sk] do you mean the notes will stand alone? I agree that the notes can stand alone, but I worry that folks reading the sections that now contain those forward references may not tie them back to the relevant sections without the forward references. [debc] I did mean that the notes should/will stand alone. Maybe once those notes have real section numbers it will flow better with the forward references. Section 2.1.1.1.1, 2.1.1.1.2, 2.2.1.1.1, 2.2.1.1.2 : Make the “If there are many logs, it may not be feasible for a Subject to track all of them” a note in Section 4 (it is sort of Note 1 currently). [sk] we can add text to state this potential problem, in the indicated sections. However, it is the Monitor function that tracks logs. Only when a Subject self-monitors is the specific text you cited correct. So, we'll substitute Monitor for Subject in your text, OK? [debc] yes, subject or monitor will both have this problem. Section 2.2.1.2: Add a section on Self-monitoring Subject and a section on benign third party Monitor. [debc] not sure what happened to this one... Section 2.2.1.1.3 and 2.2.1.2.1: Combine these into Section 2.2.1.3 called malicious or conspiring third party monitor. [sk] I don't follow your comment above. it doesn't match the outline for section 2.1. I think 2.2.1.2.1 should be subsumed under 2.2.1.2, but 2.2.1.1.1 seems appropriate as an enumeration of cases under 2.2.1.1. [debc] no worries if this doesn’t make sense. This is just a second comment looking to make 2.1 and 2.2 outlines the same-ish. Section 3, Syntactic checks: We need to think about whether this makes sense. This paper gets much simpler w/out it. Currently not included in rfc6962bis. [sk] 6962bis failed to define what a mis-issued cert is, even though the term is the focus of the CT effort. When I asked Ben about this last year I initially thought that only bogus certs (as we now define them) were mis-issued. But, Ben stated that a failure to adhere to the DV or EV cert profiles would be considered mis-issuance for certs of that genre. I agree that this should counted as mis-issuance, and if we intend to expand CT beyond Web PKI certs, then syntactic mis-issuance is even more important. That's why we have two candidate syntactic cert profiles posted, and why I proposed a mechanism to allow a submitter to declare what type of cert is being submitted to a log. I also suggest that logs be allowed to optionally check submitted (pre-) certs against an declared type, perform appropriate checks if they can (and are willing) and record the results in the SCT. [debc] it will be interesting to see how this evolves. Deb Cooley [email protected]<mailto:[email protected]> ________________________________ From: Stephen Kent [[email protected]] Sent: Thursday, June 18, 2015 10:07 AM To: Cooley, Dorothy E CIV (US); [email protected] Subject: Re: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt Deb, Thanks for reading the doc and providing comments prior to our next planned rev. My responses are inline below. Steve
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
