Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records
RFC 5276
Yes
(Tim Polk)
No Objection
Lars Eggert
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Mark Townsley)
(Pasi Eronen)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert
No Objection
Tim Polk Former IESG member
Yes
Yes
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2008-06-19)
Unknown
A review by Christian Vogt: This document specifies extensions to the Server-based Certificate Validation Protocol to inquire about changes on the certification path of a certificate of interest. Such changes may happen due to expiry of previous certificates, or due to replacement of compromised cryptographic algorithms. The document is in good shape. I have one main comment though, which I think should be addressed before forwarding this document for publication: The specified technique enables the establishment of trust into a certificate even after certificates in the certification path have changed. To which extent can this be used when certificates have been revoked explicitly? Suggest adding a discussion on this. Some smaller comments: - Abstract: SCVP is the *Server-based* Certificate Validation Protocol, not the Simple Certificate Validation Protocol. - Abstract/Introduction: The document is unclear about the purpose of the technique it specifies. Although the document states in its abstract that it defines an extension to SCVP, the ultimate purpose of this extension remains a bit blurry. - Security considerations: It is unclear which security vulnerabilities this section is trying to address. It seems that the section focuses on possible protocol extensions, or alternative ways to realize the protocol. This is not what the Security Considerations section is to be used for; it should instead focus on security aspects of the specified protocol itself. - Appendix A: Suggest adding an introductory paragraph that explains the ASN.1 constructs defined in this appendix and their relation to the protocol elements defined earlier in the document.
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown