Signing Untrusted SCVP?

["Dave Engberg" <[e-mail]>]

Section 1.1 of the SCVP draft specification has a nice justification for
supporting pure DPD to avoid the security and scalability problems of
DPV:

   SCVP can be used by clients that do much of the certificate 
   processing themselves but simply want an untrusted server to
   collect information for them. ...

   Untrusted SCVP servers can provide clients the certification paths.  
   They can also provide clients revocation information, such as CRLs 
   and OCSP responses, and the client needs to validate the 
   certification path constructed by the SCVP server.

Validating the received path on the client requires a competent local
validation engine, but avoids the first security concern listed in
section 10:

   A client that trusts a server's response for validation of a 
   certificate inherently trusts that server as much as it would trust 
   its own validation software.  This means that if an attacker 
   compromises a trusted SCVP server, the attacker can change the 
   validation processing for every client that relies on that server.  
   Thus, an SCVP server must be protected at least as well as the 
   trust anchors that the SCVP server trusts.

Rather than trying to protect _every_ SCVP server to the same level as a
root CA, DPD through "Untrusted SCVP" maintains end-to-end PKI security
integrity between clients.

Given that the spec goes to some lengths to support pure DPD by clients,
why is there a requirement (section 3) that every SCVP response be
digitally signed?  In Untrusted mode, clients MUST ignore any signature
from the SCVP server and independently verify the certificate chain and
any extra CRLs, OCSP responses, etc.  The extra dynamic signature around
the entire package is gratuitously expensive overhead (latency,
bandwidth, $20k HSM).

It would make sense (to me, obviously) to make the signature optional,
and possibly add a request flag indicating Untrusted mode.