Subject: RE: Unsigned DPD responses for SCVP15

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 12 Jul 2004 18:11:13 -0700

I should have added that we need some rationale as well so I get some
context why. We need to consider this change in light of all SCVP users,
not just the DPD camp.
Trevor

* -----Original Message-----
* From: Michael Myers [mailto:[email-masked]]
* Sent: Monday, July 12, 2004 5:55 PM
* To: Trevor Freeman; [email-masked]
* Subject: RE: Unsigned DPD responses for SCVP15
* 
* Trevor,
* 
* I prefer the client-side flag option, with absence of the flag
* defaulting to no signatures on SCVP responses containing ONLY
* {path, rev-info}.
* 
* Mike
* 
* 
* -----Original Message-----
* From: [email-masked]
* [mailto:[email-masked]]On Behalf Of Trevor Freeman
* Sent: Monday, July 12, 2004 5:10 PM
* To: [email-masked]
* Subject: Unsigned DPD responses for SCVP15
* 
* 
* I have been asked to add unsigned responses for DPD clients to
* SCVP15. There are two models proposed on how we accomplish that
* both of which meet the requirements for 3379. I would therefore
* like some feedback on how the group views the two mechanisms
* 
* Global Server Policy that it is DPD only
* The first proposal is to make the option controlled by the
* server as a global policy. Therefore the server would publish
* via policy that is only supports DPD as such never signs a
* response. DPV client and DPD clients wanting a signed response
* then know to use another server.
* 
* SCVP Request option to not sign response
* The second option is to leave it to the client to signal to the
* server it does not need a signature on the response by a new
* flag in the request (or its twin the flag indicates it does want
* a signature on the response). This allows clients to be
* benevolent towards the server by asking it to skip the
* signature. Server can still at their discretion still sign.
* 
* Needless to say it is possible to hybridize the two but I am
* hopeful we can try and keep this as simple as possible be
* picking on of the two.
* Trevor
*

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 12 Jul 2004 18:57:43 -0700

Given the two alternatives of:

1. An approach requiring explicit policies; or

2. Client-side assertion of a new flag as Tim proposed;

I prefer #2 for the following reasons.

The SCVP I-D asserts no requirement that a server MUST have a
unique policy.  The I-D supports this by making optional all
such elements beyond the default defined by RFC3280.  An
explicit OID-based approach forces the issue for servers that
wish to support unsigned DPD.

A non-trivial subset of environments don't even know what an OID
is (think credit unions), let alone the technical details of
what must go into a policy as it relates to this context.  The
contents of such are not well defined.  Absent that, there
exists no basis to implement correponding enforcement logic that
is ensured to be interoperable across the Internet.

The I-D provides no means for technical implementation and
enforcement of a policy-based approach; it is non-implementable.
Further, the I-D provides no means to discriminate between DPD
and DPV.  Even assuming in the future a consensus on a
technically enforceable security assertion grammar, the subject
I-D defines no technical means to even say "DPD".

Mike

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Jul 2004 09:10:54 -0400

>wish to support unsigned DPD.

I thought that the requirements RFC required a default policy, which 
would be unique, to allow a client to not have to always specify a 
policy. of course, one does not take full advantage of the 
capabilities of SCVP if you do this, i.e., you don't get to use 
application context specific cert validation.

>is ensured to be interoperable across the Internet.

This paragraph seems very confusing. Of course many users will not 
know what OIDs are, but they also usually don't know many details of 
Internet technology are. what "enforcement logic" are you referring 
to here? Cert evaluation is, in general, a local matter controlled by 
a relying party. the problem of a cert user choosing the right cert 
to provide to a relying party, is outside the scope of SCVP.

>I-D defines no technical means to even say "DPD".

I have no idea what you are referring to in this paragraph. Please try again.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 13 Jul 2004 16:31:52 -0700

Steve,

There exists no SHALL statement in the SCVP I-D that compels an
environment to institute a locally unique and technically enforceable
policy with respect to SCVP.  Nor does there exist guidance on how to
implement such.  I think we are best off with the flag.

Mike