Skip to main content

Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records
draft-ietf-ltans-ers-scvp-07

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 steering group member) Yes

Yes ()

                            

(Cullen Jennings; former steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Ward; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2008-06-19)
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 steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()