Subject: RE: SCVP-15

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 2 Aug 2004 00:05:26 -0700

Hi Mike,
I think the definitions in 3379 are more accurate since it is what the
client does with the response which is litmus test between DPD and DPV.
I am happy to add test along the lines you suggest as illustrations of
what a DPD client might do.

Trevor

* -----Original Message-----
* From: Michael Myers [mailto:[email-masked]]
* Sent: Saturday, July 31, 2004 8:08 AM
* To: Trevor Freeman; [email-masked]
* Subject: RE: SCVP-15
* 
* 3379's definitions work well for 3379, but I think the document should
* say that with respect to 3379, "DPD" in this document (i.e. SCVP)
means
* a request where:
* 
* 1. certChecks contains at most id-stc-build-pkc-path; AND
* 
* 2. wantBack contains at most either one or both of
*    {id-swb-pkc-cert-path, id-swb-pkc-revocation-info}.
* 
* while "DPV" means a request that includes any of the other values
* defined for use in these two elements.
* 
* Mike
* 
* -----Original Message-----
* From: [email-masked]
* [mailto:[email-masked]]On Behalf Of Trevor Freeman
* Sent: Friday, July 30, 2004 10:38 PM
* To: Michael Myers; [email-masked]
* Subject: RE: SCVP-15
* 
* 
* 
* Hi Mike,
* Sorry for the slow response but I am on vacation so am not reading
mail
* as frequently as normal. I agree with your point on needing clear
* definitions for DPD and DPV but I think the ones provided in 3379 are
* adequate. That would simply require adding references to sections 2
and
* 3 of the RFC.
* 
* Do you agree?
* Trevor
* 
* * -----Original Message-----
* * From: [email-masked]
* [mailto:[email-masked]]
* * On Behalf Of Michael Myers
* * Sent: Thursday, July 22, 2004 11:43 AM
* * To: [email-masked]
* * Subject: Re: SCVP-15
* *
* *
* * Trevor,
* *
* * Section 3.2.10, extracted below, is a good step forward to closure
on
* * the issue.  Given its definition as a BOOLEAN in Query syntax, I am
* * comfortable with its default to TRUE.
* *
* * The second paragraph however needs an implementable definition of
DPD
* * vice DPV with respect to SCVP ASN.1 in order to assert that that a
* * request is in error if it asks for a validation assertion in the
* context
* * of signResponse set to FALSE.
* *
* * Mike
* *
* *
* *
* *
* * 3.2.10 signResponse
* *
* *   The signResponse specifies if the client requires the server to
* *   sign a response to the validation request. If the client is
* *   performing full chain validation on the response and it is not
* *   concerned about the authenticity of the source of the data, then
* *   the client does not benefit from the signature on the response in
* *   which case it can indicate to the server that the signature is
* *   unnecessary via the signResponse value.
* *
* *   SCVP clients that support DPD MUST support setting this value to
* *   FALSE. Since DPV responses must be signed, DPV only SCVP clients
* *   MUST NOT to support this value. SCVP servers SHOULD support
* *   returning unsigned responses. It is a local policy decision on the
* *   part of the server to return signed or unsigned responses if this
* *   value is set to FALSE.
* *
* 
* 
*

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 2 Aug 2004 07:47:48 -0700

I fully agree with your first point.  3379 is the defining document on
the concepts of DPD and DPV.  That's why we worked so hard on it.  But
my point is that, as with other 3379 text, those concepts need
translation into an implementable protocol.  Thus, for example, any SCVP
request containing any of the <validated path> certCheck or wantBack
values is, by definition, NOT a DPD request.  I think we need crisp,
normative definitions in this instance along the lines I proposed in
order to ensure security in implementations and interoperability among
them.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Trevor Freeman
Sent: Monday, August 02, 2004 12:05 AM
To: Michael Myers; [email-masked]
Subject: RE: SCVP-15

Hi Mike,

Trevor