Skip to main content

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