Subject: RE: Validation policy in DPV/DPD rqmts

From: "Housley, Russ" <[email-masked]>
Date: Fri, 01 Mar 2002 08:26:10 -0500

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

At 10:22 AM 2/28/2002 -0800, Michael Myers wrote:
>Russ, Denis:
>
>After further thought, I see that what I was actually hunting
>for was that set of requirements leading to, among other things,
>assurance of the existence of path validation logic conformant
>to RFC 2459 among *any* technical specification claiming
>conformance to this requirements specification.
>
>I would count among those, for example, an XML-based approach
>towards satisfying these requirements.  While that technology
>platform is at present out of PKIX' scope, the existence of this
>document enables such claims from a PICS-like perspective.
>
>But if "valid" means whatever the policy OID says it means, we
>could see NULL policies, or something along the lines of "that
>individual is no longer in our customer directory, thus the
>certificate is invalid" without any path checking
>whatsoever--basically treating a certificate hash as nothing
>more than a database index. Or scenarios where a certificate may
>have a NULL subject DN, a non-conformant practice according to
>RFC 2459, but is nonetheless "valid".
>
>I don't think we want that, but I see no requirements that
>prohibit such practices.  I you'd like, I can draft up some
>text.
>
>Mike

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 1 Mar 2002 12:30:29 -0800

> -----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].