Subject: RE: Signing Untrusted SCVP?

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 5 Apr 2004 14:43:30 -0700

So Dave, if we supported the ability for the client to specify if it
wanted a fresh response vs. would accept a pre caned response - would
that address you concern?
Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Dave Engberg
Sent: Monday, April 05, 2004 1:18 PM
To: Stephen Kent
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Stephen -

Sorry, I wasn't clear enough on pregeneration.  In the current draft,
the combination of a mandatory signature (or MAC) plus the mandatory
RequestReference inclusion in every response means that you can never
provide SCVP DPD without using a protected online key for each
transaction.  No caching (e.g.
http://www.rfc-editor.org/internet-drafts/draft-deacon-lightweight-ocsp-
profile-00.txt, section 4.2), no pregeneration, no keyless DPD servers.

My preference would be support for keyless DPD through optional
signatures, but pregeneration with a keyless HTTP caching tier would be
an unpleasant second option that would require that the RequestReference
be made optional.  Without at least one of these options, I'm
pessimistic about SCVP's usability for the sort of big (e.g.
governmental, inter-banking) PKIs that my company works with.

My reference to DPV security is well summarized in section 10 of the
SCVP spec:

   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.

In a serious PKI, most trust anchors are highly secured offline roots
with armed guards and missile launchers and whatnot.  I'm nervous about
trying to secure online DPV servers "at least as well as" PKI trust
anchors, and then service millions of requests a day from them over
public networks.  Server compromise (network or physical) of an
explicitly-trusted DPV server would be a very bad thing until you catch
it and reconfigure every relying client.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, April 05, 2004 1:58 PM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

At 12:17 PM -0400 4/5/04, Dave Engberg wrote:

...

>I actually have a strong preference
>AGAINST pre-signing (or any kind of signing) for DPD responses, which 
>is the opposite of CoreStreet's preferred approach to OCSP.

I'm surprised by that assertion, given your comment in the previous
message that pre-signed responses were a problem if we require signed,
nonced (pardon the neologism) responses for DVD. if you are not a fan of
pre-signed responses, I would not have expected you to cite that
concern, nor raise the related issue of the cost of an expensive crypto
module. But, I'll take your word that these arguments, which seem to be
motivated by a preference for pre-signing, are not really representative
of your personal views.

...

>To be less
>circumspect about my motives:  I am interested in DPD and DPV, but 
>believe that SCVP DPV is a gigantic step backward for PKI security,

What parts of the rationale in 3379 for DPV do you not believe are true?

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 5 Apr 2004 15:33:42 -0700

Trevor,

Is not the issue at hand whether not DPD responses MUST be
signed?

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Trevor Freeman
Sent: Monday, April 05, 2004 2:44 PM
To: Dave Engberg; Stephen Kent
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

So Dave, if we supported the ability for the client to specify
if it
wanted a fresh response vs. would accept a pre caned response -
would
that address you concern?
Trevor

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Dave Engberg
Sent: Monday, April 05, 2004 1:18 PM
To: Stephen Kent
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Stephen -

Sorry, I wasn't clear enough on pregeneration.  In the current
draft,
the combination of a mandatory signature (or MAC) plus the
mandatory
RequestReference inclusion in every response means that you can
never
provide SCVP DPD without using a protected online key for each
transaction.  No caching (e.g.
http://www.rfc-editor.org/internet-drafts/draft-deacon-lightweig
ht-ocsp-
profile-00.txt, section 4.2), no pregeneration, no keyless DPD
servers.

My preference would be support for keyless DPD through optional
signatures, but pregeneration with a keyless HTTP caching tier
would be
an unpleasant second option that would require that the
RequestReference
be made optional.  Without at least one of these options, I'm
pessimistic about SCVP's usability for the sort of big (e.g.
governmental, inter-banking) PKIs that my company works with.

My reference to DPV security is well summarized in section 10 of
the
SCVP spec:

   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.

In a serious PKI, most trust anchors are highly secured offline
roots
with armed guards and missile launchers and whatnot.  I'm
nervous about
trying to secure online DPV servers "at least as well as" PKI
trust
anchors, and then service millions of requests a day from them
over
public networks.  Server compromise (network or physical) of an
explicitly-trusted DPV server would be a very bad thing until
you catch
it and reconfigure every relying client.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, April 05, 2004 1:58 PM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

...

>is the opposite of CoreStreet's preferred approach to OCSP.

I'm surprised by that assertion, given your comment in the
previous
message that pre-signed responses were a problem if we require
signed,
nonced (pardon the neologism) responses for DVD. if you are not
a fan of
pre-signed responses, I would not have expected you to cite that
concern, nor raise the related issue of the cost of an expensive
crypto
module. But, I'll take your word that these arguments, which
seem to be
motivated by a preference for pre-signing, are not really
representative
of your personal views.

...

>believe that SCVP DPV is a gigantic step backward for PKI
security,

What parts of the rationale in 3379 for DPV do you not believe
are true?

---

From: David Engberg <[email-masked]>
Date: Mon, 05 Apr 2004 18:48:14 -0400

> that address you concern?

That would be my second choice.

When a client asks an untrusted SCVP DPD server, "Please give me a path 
between certs A and E that satisfy constraints X," my first choice would 
be that the client could say "I don't need a signed response because I 
don't explicitly trust you."  The untrusted server would be able to 
provide a response ("B, C, and D") with an empty Set of SignerInfo.  The 
DPD server would not need to have any protected keys, in the same way 
that an LDAP directory fulfilling the same task would not be required to 
support SSL.  It lets a mature PKI use DPD without having to add yet 
another set of protected keys or new certificate profiles, etc.

My second choice would be what you describe.  I wouldn't continue to 
call this "untrusted" SCVP ... it's more like "semi-trusted."  In this 
mode, a client would indicate that it doesn't require a RequestReference 
(or a nonce), and a local keyless cache server could provide a cached or 
pregenerated response ("B, C, and D") which was previously signed.

Thanks