Subject: RE: Validation policy in DPV/DPD rqmts

From: "Deacon, Alex" <[email-masked]>
Date: Tue, 5 Mar 2002 09:55:26 -0800

All,

My .02 cents after catching up on this very long thread.  I'll try to make
them quick:

* Mandating additional granularity on the current "valid, invalid, unknown"
status is a bad idea IMO.  I would prefer to have this requirement removed;
however if server support for "potentially valid" (or sort-of-valid,
kind-of-valid, whatever) is specified as a MAY (as I believe we have
decided) then I suppose I can live with it.

* Requirements that add additional processing requirements on clients is
also, IMO, a bad idea.  The idea of OCSP/DPD/DPV/etc servers is to move
complexity away from the client.  I'm scared by the talk of path validation
policy negotiation.  Concepts like this will lever fly in constrained
clients such as mobile phones.

* I agree with Mike's wording below on the minimum requirements need for a
server to assert a "valid" status.  Lets make sure we have some base/minimum
assumptions regarding what a server should do, and lets make sure it
reflects the hard work and decisions we made in PKIX path processing.  

Alex

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]]
> Sent: Friday, March 01, 2002 12:30 PM
> To: Housley, Russ
> Cc: [email-masked]
> Subject: RE: Validation policy in DPV/DPD rqmts
> 
> 
> 
> > -----Original Message-----
> > From: Housley, Russ
> > Sent: Friday, March 01, 2002 5:26 AM
> >
> > Mike:
> >
> > Please post your suggested text.  Based on your
> > message, it should not need to be more than a
> > paragraph.  Did I miss something?
> >
> > Russ
> 
> Russ,
> 
> Here's a first cut.  I suggest inserting this text immediately
> following the identification of the various states a DPV server
> must be capable of producing.
> 
> Mike
> 
> 
> Prior to asserting a "valid" status, a DPV server SHALL, at a
> minimum:
> 
> 1. confirm that, in the time context of the request, the subject
> certificate is (or was) niether revoked nor suspended by the
> authority that issued the certificate;
> 
> 2.  confirm that, in the time context of the request, all
> certificates needed to complete the associated validation path
> are (or were) niether revoked nor suspended, up to and including
> the trust anchor; AND
> 
> 2.  confirm that the subject certificate and its associated
> intermediate and trust anchor certificates form a chain that
> satisifies the path validation algorithm defined by RFC 2459 or
> its successors [PKIX-1].
>

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 5 Mar 2002 16:56:00 -0800

Hi Alex,

We've agreed that we're now back to {valid, invalid, unknown}.
The notion of "potentially valid" is a client-side
interpretation of the data that MAY be transmitted from the
server to aid the client in assessing this situation.

Mike

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Deacon, Alex
> Sent: Tuesday, March 05, 2002 9:55 AM
> To: [email-masked]'