[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Unsigned DPD responses for SCVP15
Trevor,
There is no requirement that an SCVP server MUST operate under an
explicit and technically enforceable policy document. There is no SHALL
statement to this effect in the Sections 3, 4 or 5. A casual parse of
the optional and default elements of SCVP's ASN.1 supports this.
I see that you ultimately restated your original request to the WG.
Thus Russ, Dave, Denis and I are still back to now what is your option
(B).
Mike
-----Original Message-----
From: Trevor Freeman [mailto:trevorf@xxxxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, July 13, 2004 11:29 AM
To: Michael Myers; ietf-pkix@xxxxxxx
Subject: RE: Unsigned DPD responses for SCVP15
Hi Mike,
Let me restate the question then.
The SCVP server publishes a policy document (see SCVP section 6) which
defines the default server behavior for that instance of server and the
set of validation policies it recognizes. We can add a flag to that
policy to indicate the server will only support DPD and in that mode the
server would not sign SCVP responses. We could also add another flag to
say the server was cached responses only.
The alternative if to have the client use a request flag and the server
can either process the request or return an error. If the objective to
support DPD only servers then having the server publish its DPD only
seems cleaner and simpler from the client perspective rather than have
the DPV client try and get an error back.
There is still the unanswered question of the value of having an SCVP
server support mixed mode operation i.e. it can return either signed or
unsigned responses based on the request flag. With the above server
policy flag we can support always sign or never sign which means I ca
sign all responses or lock a server to DPD only and never sign
responses. If you want to have a low cost to deploy server then I would
have thought you would lock it down to DPD only. Once you take the cost
hit to deploy a signing SCVP server, beyond the CPU savings for not
dsigning some responses, what is the benefit over always signing policy
if you have a signing server given requests can be anonymous?
Therefore to support unsigned DPD do we
(A) add a flag to the Server policy response (SCVP section 6) to allow
the server to always sign or never sign?
Or
(B) Do we add a flag to the client request to allow the client to
express a preference to sign or not
If we want to support DPD only servers then option A meets that goal. If
we want to support mixed mode operation where a SCVP server can support
both signed and unsigned responses and that that there is tangible
benefits to mixed mode over always signing vs. never signing, then we
need option B.
Trevor
* -----Original Message-----
* From: Michael Myers [mailto:mmyers@xxxxxxxxx]
* Sent: Tuesday, July 13, 2004 10:26 AM
* To: Trevor Freeman; ietf-pkix@xxxxxxx
* Subject: RE: Unsigned DPD responses for SCVP15
*
* Trevor,
*
* I believe Dave, Denis and I thought we were talking two
* alternative mechanisms to address the unsigned DPD consensus: a
* mechanism based on explicit policy OR a mechanism based on a new
* request flag, as you had earlier posted.
*
* Your discussion below, i.e. "it seems prudent to have a flag in
* the server policy" is confusing in that context.
*
* Please clarify what you are asking the WG to consider.
*
* Mike