Server-Based Certificate Validation Protocol (SCVP)
Note: This ballot was opened for revision 33 and is now closed.
(Sam Hartman) (was Discuss, Yes) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) (was Discuss) No Objection
(Lars Eggert) No Objection
(Cullen Jennings) No Objection
Comment (2007-04-04 for -** No value found for 'p.get_dochistory.rev' **)
I wanted to note to the authors/ads that this did not seem to have a Name Validation ALgorithm that would work for SIP. I don't see any problems with a future document extending this to have one that does work for SIP, so I'm not worried about this - It would be easy to add one if people felt that would be valuable in this document. There are people that want to build phones that delegate this type of checking to a trusted server.
(Jon Peterson) No Objection
(Mark Townsley) No Objection
Magnus Westerlund (was Discuss) No Objection
(Chris Newman) (was Discuss) Abstain
Comment (2007-04-03 for -** No value found for 'p.get_dochistory.rev' **)
It's my opinion this is so complex it's not likely to be widely deployed. As a result, the failure to conform to IETF BCP 56 is unlikely to have negative repercussions significant enough to merit a DISCUSS vote. Regardless, this document could be improved by conforming to IETF BCP 56 -- specifically by registering a separate port for SCVP over HTTP, considering an SCVP URL scheme and providing mention of how this interacts with HTTP proxies in the security considerations section. There have also been a great deal of security vulnerabilities in real world security products due to the use of ASN.1. The security considerations of this document should provide a reference or text covering the security considerations of using ASN.1. It is also not clear to me how this mechanism bootstraps. It seems the client has to be manually configured with an HTTP URL (or other URL scheme) which will vary unpredicably from site to site and sufficient information to verify the server signature on the response packet. In my experience, requiring more client bootstrap info than a server DNS name is likely to be a barrior to deployment outside of well-managed enclaves. A few nits: In section 3.2 where it summarizes the structure elements, it fails to mention the producedAt element. In section 3.2.2, it requires SCVP servers that conform to DPD to implement id-stc-build-pkc-path, and DPV compliant SCVP servers to implement the other two checks. What about an SCVP server that conforms to neither DPD nor DPV? Would it be a compliant SCVP server if it implemented no checks? Section 18.104.22.168.2, the order of the final three paragraphs does not match the order of the items in the structure; moving the last paragraph up two would fix that. Section 22.214.171.124.3, Does *.a.com match a.com? I assume not, but the text would be better if it said so.