Rich,
Thanks for the review and the suggested changes. I have made edits
to accommodate almost all of your suggested changes.
Here's my notes. All are nits/editorial. This is a very good document, nice
work!
thanks.
Overall -- should it point out that "revocation" in the sense of CRL's doesn't
work in web pki? I know you say it includes things like blacklists and crlsets
(rightfully, without using that browser-specific term)
I have added a paragraph to address your concern, and modified the text
slightly:
Certificate Revocations Lists (CRLs) [RFC5280] are the primary means of
certificate revocation established by IETF (and ISO) standards.
Unfortunately, most browsers do not make use of CRLs to check the
revocation status of certificates presented by a TLS Server (Subject).
Some browsers make use of
Online Certificate Status Protocol(OCSP) data [RFC4366] as a
standards-based alternative to CRLs. Also, most browser vendors employ
proprietary
means of revoking certificates, e.g.,via a ''blacklist'' or
abad-CA-list. Such capabilities enable a browser vendor to cause
browsers to reject any certificates on the blacklistor for which the
issuing CA is on the bad-CA-list. This approach also
remediesmis-issuance. Throughout the remainder of this document
referencesto certificate revocation as a remedy encompass this and
analogousforms of browser behavior, if available. Note: there are no IETF
standards defining a browser blacklist of bad-CA list capability.
Overall -- should we say user-agent, not browser?
I have used the term "browser" because the focus of 6962-bis has been the
browser/WebPKI context, more than the general TLS user agent context.
P3/bottom: Love the definition of the term bogus :) On next para (p4) need to say
"use the term erroneous here"?
fixed
P4/bottom: SCT isn't defined before used.
fixed
P5/middle: MMD and STH not defined before used?
expanded these acronyms.
P6: Fig 1 is a tour de force
David Mandelberg is responsible for all the ASCII art in this and
out other docs.
P8/middle: remove the <want to list... phrase.
done
P8/middle: change "to present the forged" to "so that it can present the
forged" ?
fixed
P8/bottom: Why use single quotes here, but double-quotes in previous words
(e.g., bogus)?
my copy shows double quotes here. we'll look into this detail.
Perhaps add a sentence explaining that the malicious term is being used,
even when the CA is forced to act under duress?
done.
p10/top: single quotes around fake,
again, my copy shows double quotes.
And extra close-paren at end of sec 3.1.1.2
removed
p10/middle: brings up general point that too much important text is put in
parenthesis :)
parentheses removed!
p13/top: Add "For example, the CA could make excuses..."
fixed.
p14/middle: Remove parens around "(legitimate)"
parenthesis removed.
p14/bottom: Move the "we refer" to p4 as noted above?
text now notes that the term was introduced in Section 1.
P15: Don’t get why those three paragraphs are set off as list items?
upon further review, not realy necessary. will make them top-level
paragraphs, no bullets.
p15/bottom: The "Bottom line:" needs to be put into prose :)
fixed.
p19: These are VERY IMPORTANT QUESTIONS. Should we have (tentative?) answers?
I'd like to have answers from the CT designers for these questions. If
we don't have answers, we can say these topics require further
study and thus merit discussion in the Security Considerations sections
of RFCs that purport to define requirements for these elements of CT.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
