Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt

From: Peter Williams <[email-masked]>
Date: Thu, 25 Apr 2002 11:18:51 -0700

Mike,

My question was not: what is Mike's/PeterW's opinion about the nature of
validity (or DoD policy opinion, or the RSA/VeriSign policy
opinion, or the VeriSign CPS 1.2 policy opinion, or
the VeriSign CPS 2.0 policy opinion, or the next 
VeriSign v3.0 policy opinion ).

The question was, do you have a citable, consensus definition
that you can share with us, that is purely "technical"

(a) Requirement A

Id be happy to accept RFC 2459 as the definition of 2459-valid. 
Conformance to 2459 defines a reasonable process for asserting 
valid, in a technical sense.

(b) Requirement B

Any other amendment by a DPV server to
the result of 2459 path processing must be based on application
of a rule from a requestor-cited validation policy.

I  provide two examples rules:

(1) A path that is 2459-valid at one moment
can be cited as invalid, under given validation policy
whose nth policy rule states: all certs within
6 months of expiry are to be treated as revoked.

(2) For DoD, a path that is 2459-invalid at one moment
can be cited as valid, under given validation policy
whose nth policy rule statea: all CA certs in a special
exception class, maintained by the validation policy, are to 
be treated as if operational, for 36 months beyond the
earlier of their validity-end date or an authorized 
CRL-based revocation date

Can we agree that these basic processing requirements drive the 
protocol design for DPV?

>>>>> (1) Can you provide a citation or other professional
>>>>> reference for the "precise technical meanings" of "valid" and
>>>>> "invalid", please?
>>>>
>>>>Which of the following do you believe should be eliminated from
>>>>such a definition:
>>>>
>>>>1. Formation of a valid path IAW 2459;
>>>>
>>>>2. Confirmation of revocation status for each
>>>>   certificate in said path;
>>>>
>>>>3. Cryptographic validation of said path IAW 2459.
>>>>
>>>>4. Other practices as required by policy.
>>>>
>>>>> (2) Could you also perhaps help me compare
>>>>> the definition(s) of "valid" used in the
>>>>> VeriSign CPs (1.2 and 2.0)and the US DOD CP v2 (March
>>>>> 1999), perhaps, against the recognised
>>>>> definition of "valid" (see above (1))?
>>>>
>>>>Nope.  Go for it.
>>>>
>>>>

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 25 Apr 2002 11:46:28 -0700

Peter,

I like what Russ said.  With respect to this WG, valid is
whatever 2459 or its successors says it is.  Invalid means one
or more those conditions aren't satisifed.  I see you agree.

I infer from my reading of the I-D that amendments to this
baseline are not necessarily client-driven.  -04 clearly states:
"If the DPV request does not specify a validation policy, the
server response MUST indicate the one that was used."

Mike

Michael Myers
t: +415.819.1362
e: mailto:[email-masked]
w: http://www.traceroutesecurity.com

> -----Original Message-----
> From: Peter Williams [mailto:[email-masked]]
> Sent: Thursday, April 25, 2002 11:19 AM
> To: 'Michael Myers'; PKIX
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
>
> Mike,
>