Subject: Signing Untrusted SCVP?

From: "Dave Engberg" <[email-masked]>
Date: Thu, 1 Apr 2004 17:43:26 -0500

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.

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 1 Apr 2004 17:18:56 -0700

Dave,

Your analysis is consistent with original intent.  We may have
some work in front of us.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Dave Engberg
Sent: Thursday, April 01, 2004 3:43 PM
To: [email-masked]
Subject: Signing Untrusted SCVP?

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:

   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.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Apr 2004 16:45:29 -0500

Dave,

I agree that one might not want to invest as much effort and money in 
securing a DPD server as a DPV server. But that does not necessarily 
translate into removing the need for signatures on responses from 
such servers. If responses from a DPD server are spoofed, a client 
may be subject to a form of DoS attack, as it tries to make use of 
bogus certs formed chains intended to maximize the amount of crypto 
processing the client does, before realizing that the chain is bad. 
Or certs might be returned that conflict with certs from some other 
DPD server.  Without signed responses it could be very hard to 
determine what went wrong and what servers ought to be avoided, based 
on bad behavior.

Steve