Subject: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-02.txt

From: [email-masked]
Date: Mon, 11 Feb 2002 06:56:55 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Delegated Path Validation and Delegated Path Discovery
                          Protocol Requirements (DPV&DPD-REQ)
	Author(s)	: D. Pinkas, R. Housley
	Filename	: draft-ietf-pkix-dpv-dpd-req-02.txt
	Pages		: 14
	Date		: 08-Feb-02
	
This document specifies the requirements for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD). It also specifies the  requirements for DPV and DPD policy management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-dpv-dpd-req-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 22 Feb 2002 19:29:55 -0800

Russ, Denis:

Item #3 of the definition of DPV response status requirements
states that a server must be able to produce a value indicating:

   "3) the certificate is not yet valid at this time. If another
      request could made later on, the certificate could
possibly be
      determined as valid. This condition will occur before a
      certificate validity period has begun, while a certificate
is
      suspended, or when, at the time the server generated the
      response, all conditions of the validation policy could
not be
      met."

I translate this to a "potentially valid" state vs. the more
conclusive "valid", "invalid" or "unknown" states.

I'm a bit wary of this semantic.  It's not at all clear to me
how one would define a protocol or write code to comply with
this requirement.

This requirement should be eliminated.  A certificate is either
valid or it isn't in the time context of the request.

Mike

---

From: "Khaja E. Ahmed" <[email-masked]>
Date: Fri, 22 Feb 2002 23:27:20 -0800

I am inclined to agree with Michael.  I can see the benefit of being able to
communicate such complex states but in practice this benefit will be hard to
realize and is just the type of thing that causes interoperability problems.
The best thing might be to, as Michaels suggests, drop this requirement.
The next best thing would be to make it optional - a MAY rather than a MUST.

Khaja

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Michael Myers
> Sent: Friday, February 22, 2002 7:30 PM
> To: [email-masked]
> Subject: "Potentially valid" response state in DPV/DPD rqmts I-D
>
>
>
> Russ, Denis:
>

---

From: "Roberto Opazo Gazmuri" <[email-masked]>
Date: Mon, 25 Feb 2002 10:50:41 -0300

I agree with eliminating this state.

I think there is a big difference with a certificate that is “still not
valid” with another that is “suspended”. The first one will probably be
valid while the second one is probably going to be invalid.

If not, I would prefer to separate this state.

Roberto

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Khaja E. Ahmed
> Enviado el: sábado, 23 de febrero de 2002 4:27
> Para: Michael Myers; [email-masked]
> Asunto: RE: "Potentially valid" response state in DPV/DPD rqmts I-D
>
>
>

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 25 Feb 2002 15:31:32 +0100

Michael,

>       possibly be determined as valid. This condition will occur 
>       before a certificate validity period has begun, while a 
>       certificate is suspended, or when, at the time the server 
>       generated the response, all conditions of the validation 
>       policy could not be met."
> 

Fine. We could rename that status: "potentially valid".

> how one would define a protocol or write code to comply with

Some applications can take advantage of that information, 
e.g. by querying again later on. For those that may not take 
advantage of it, they could apply the same treatment as they would 
with "invalid".

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 25 Feb 2002 09:18:50 -0800

Denis,

Thank you for your quick response.  However, I remain convinced
that the requirement should be eliminated for three reasons.

1.  Either a certificate is valid in the time context of the
request or it isn't.

Conditions for validity are well documented elsewhere. Fail in
any one and the certificate is, by definition, "not valid".
We've been working on this for years.  Not so the notion of
"potentially valid".  The scope of the DPV/DPD requirements
document should limit itself to that which can be replicated in
other contexts.  In particular, to my knowledge the notion of a
separate state of "potentially valid" does not present itself in
the work of the X.509 group, with whom PKIX' charter is vitally
linked.

2.  At the systems level, this requirement is broke on the face
of it.  It is ambiguous, open-ended and untestable in practice.

As such I fear it will lead to non-interoperable
implementations.  Here's an example:  a certificate could be
considered "potentially valid" if a server timed out in its
query to a repository of revocation data simply because that
data may have shown the certificate not to be revoked.  This can
go on and on ad nauseum.  And because it is difficult if not
impossible to exhaustively document such conditions due to the
requirement's open-endedness, one application's "invalid" could
be another's "potentially valid".

3. The function "try again later and maybe get a different
response" is already there.

It's there implicitly.  The app can simply try again, receiving
a string of "invalid" responses until it receives "valid", or
just give up.  Which is the same systems-level behavior that
"potentially valid" would cause with no added value.

Again, I strongly urge elimination of this requirement prior to
the WG recommending this document to the IESG.  These online
certificate status mechanisms we've been working on had at their
initiation and continue to have as their primary goal the
simplification of X.509-based PKI while maintaining all the
security benefits that practice enables.  PKI is already hard
enough.  Let's not make it even more difficult by inventing new
concepts at this late date.

Mike

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

---

From: Petra Barzin <[email-masked]>
Date: Mon, 25 Feb 2002 23:14:58 +0100

I also agree with Michael. We are right now working on a so called
PKI server. I took Denis DPV/DPD draft (because I liked it the best
compared to  SCVP, OCSP-V2, RFC3029 and it met most of our
requirements). But we agreed that the response type conditionally valid
will not be supported for the same reasons as stated by Michael.

Petra

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 26 Feb 2002 10:50:47 +0100

Michael,

> that the requirement should be eliminated for three reasons.

The matter of the discussion is not to eliminate that state but more 
on how to express that state.

We have experienced this in the past with the suspension state, where we
have not defined a separate state for suspension but defined suspension as a
refinement of "revoked". Suspension has been invented much later that the
revoked state and since most people where only doing real time checking at
that time, there was not difference to be done on the treatment of suspended
or revoked. When validating a signature, this is different.

We could do the same as we do for CRLs, consider only three states, as long
as we allow to discriminate the reason of the "invalid" state, which will
then have a secondary state saying more: definitively invalid and
temporarily invalid.

So I would propose the following fix:

The DPV response MAY indicate one of three status alternatives:

   1) the certificate is valid according to the validation policy.

   2) the certificate is invalid according to the validation policy. 
      A secondary status MAY indicate that the certificate is 
      definitively invalid or potentially valid. 

      In the former case, if another request was made later on, 
      the certificate will still be determined as invalid.

      In the later case, if another request could made later on, 
      the certificate could possibly be determined as valid. This 
      condition will occur before a certificate validity period has 
      begun, while a certificate is suspended, or when, at the time 
      the server generated the response, all conditions of the 
      validation policy could not be met.

   3) the server cannot determine the validity of the certificate.
      This condition will occur when a certification path cannot be 
      constructed or some revocation information is unavailable.

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 26 Feb 2002 08:30:48 -0800

Denis,

Okay, if I may summarize at a high level my current
understanding:

We are now effectively back to {valid, invalid, unknown}.  All
responses MUST indicate the relevant validation policy. This
policy MAY be established out of band.  An "invalid" response
MAY contain reason codes or similar information that aids a
client in determining the likelihood that the same request sent
at a later time would return "valid". An "unknown" response MAY
contain reason codes or similar information that indicates a
failure to acquire all relevant data.

Is that a fair summary?  If so, a few more thoughts:

Since the server MUST indicate a validation policy, provision
should be made in the I-D for a DEFAULT validation policy that
indicates compliance to RFC 2459 or whatever RFC # is to follow
that work.  The DPV/DPD rqmts I-D is probably the best place to
define that OID.

The next issue is going to be articulating some standard subset
of reason codes for invalid and unknown.  Since validation
policies may be arbitrarily complex and dynamically produced,
perhaps just addressing the DEFAULT policy is the best that can
be done.

For "invalid" in the DEFAULT context one would have to a first
degree either a failure in cert chaining per 2459 or revocation
(including suspension) somewhere along that chain.

For "unknown" in the DEFAULT case one would have: an
unrecognized subject certificate; failure to acquire the
relevant intermediate or root certificates; and failure to
acquire the relevant revocation information.

Mike

Michael Myers
t: +415.819.1362

> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Tuesday, February 26, 2002 1:51 AM
>
> 2) the certificate is invalid according to the
> validation policy. A secondary status MAY indicate
> that the certificate is definitively invalid or
> potentially valid.
>
> In the former case, if another request was made
> later on, the certificate will still be determined
> as invalid.
>
> In the later case, if another request could
> made later on, the certificate could possibly
> be determined as valid. This condition will
> occur before a certificate validity period has
> begun, while a certificate is suspended, or
> when, at the time the server generated the
> response, all conditions of the
> 3) the server cannot determine the validity of the
> certificate. This condition will occur when a
> certification path cannot be constructed or
> some revocation information is unavailable.
>
> Denis

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 27 Feb 2002 14:19:17 +0100

Michael,

 
 
> Is that a fair summary?  

Yes, indeed it is.

> If so, a few more thoughts:

It is also fair to address one topic at a time. This is a different topic, 
I will respond to it separately using a different thread title.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 27 Feb 2002 14:33:34 +0100

Michael,

This is my answer on the second thread.

> that work.  The DPV/DPD rqmts I-D is probably the best place to

The principles of path validation contained in RFC 2459, are a set of 
rules which by themselves are insufficient to be considered as a 
validation policy. RFC 2459 "describes an *algorithm* for validating 
certification paths", but not a validation *policy*.

The text also says:

" The algorithm requires the public key of the CA, the CA's name, and any
constraints upon the set of paths which may be validated using this key.
The selection of a "most-trusted CA" is a matter of policy."

Without that minimal information, there is no validation policy possible.

So I do not think that a DEFAULT validation policy, as being proposed, 
is possible.

> perhaps just addressing the DEFAULT policy is the best that can

This is unrelated.

> (including suspension) somewhere along that chain.

Once again unrelated.

> acquire the relevant revocation information.

Once again unrelated.

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 27 Feb 2002 12:02:05 -0800

Denis,

(and anybody else with an opinion on the matter)

Do you agree that defining an OID indicating use of a DEFAULT
policy is useful?

If so, then the next question is what constitutes the elements
of that policy.  But if not, then I have some further thoughts.
Apologies to all for the length of this but I will not be able
to attend Minneapolis to argue these points in person so I'll
use the list to present my opinions.

We should not be forcing every environment wishing to use the
core functionality of delegated path validation to take on the
added burden of establishing a validation policy advisory board
or writing a validation policy practices statement or submitting
a proposed validation policy to some sort of validation policy
police or all that other predictable hoo-hah just because
there's this OID slot that needs filling.

Certainly there exists environments where such customized
diligence is justified. We should take care to enable them to do
so. But I'm pretty sure PKIX can define what it means for a
certificate to be "valid" in the DEFAULT case and with respect
to PKIX' own work products.

This default definition would be useful in ensuring not only a
uniformity of deployed functionality, but it would also
establish a floor on operational use with very little impact to
those environments who find the definition acceptable.

Specification of a default definition of "valid" would also
force into existence known minimal functionality on servers and
clients, most if not all of which is already in place.  Else
what is someone who wishes to design and code a DPV server and
DPV-enabled client to do?  What code to write?  Requirements
should be actionable and testable.

The real question is, what are the elements, the requirements,
of that default validation policy?  In essence, this reduces
down to what is running code minimally supposed to do when it's
running?

Since this is the PKIX working group, I have hard time believing
that compliance to 2459's path validation logic would not be
incorporated into that thinking.  The WG has worked hard and
long on this point.  Clearly one needs some sort of checking
against revocation data. In addition, reference has been made to
the public key of the CA, the CA's name, path constraints and
selection of a most-trusted CA.

I propose the working group establish that, in the DEFAULT case
and specifically with respect to delegated path validation
requirements, a certificate SHALL be considered valid if:

1. The path chosen by a delegated path validator satisfies the
path validation logic defined by RFC 2459 (or more likely its
immediate antecedent now in process), which algorithm is defined
to consider, among other things, path constraints, should any
exist;

2. Is neither revoked nor suspended;

3. Nor are any of the certificates in the path revoked or
suspended; and

4. The path terminates in a trusted CA certificate, which
certificate is or may be established as a consequence of local
policy.

Denis, I must confess that I'm having a very hard time trying to
translate your statements regarding what a "policy" actually is
into actionable requirements that relate directly to the
production of running code.  As to what a "policy" actually is
in this proposed default context, well, I suppose it could be
one's policy simply to accept the default.  But that is an
operational issue, not a bits on the  wire issue.

Or that policy could go on to superset the above baseline with
externally specified trust anchors or hubs, clever use of
subject directory attributes extension, reference to
specifically identified external authorities, or whatever else
might be relevant to local needs.

That localized policy could go on to indicate SAS/70 or BS 7799
etc. type auditing of related ancillary technical practices, the
security of physical premises and background checks on trusted
employees.  However, in those cases I again don't see any impact
to a bits on the wire specification of a protocol.

I strongly suspect that the above four factors, or some
variation, will always be at the core of any deployment of
delegated path validation.  Thus it only makes sense to allocate
a PKIX OID identifying this technical practice as the default in
order to establish a floor on the trustworthiness of any
deployment of delegated path validation.

What harm is there in doing so?

Mike

Michael Myers
t: +415.819.1362

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 27 Feb 2002 17:31:05 -0500

Mike:

I think that each server will have a default, but I do not think that each 
server will have the same policy as the default.  To that end, I do not 
think that it is useful to have the request specify at the default should 
be used.  I would like the response to state the policy that was actually 
used.  If there is not an OID defined that means my default, then the issue 
is avoided.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 27 Feb 2002 16:37:47 -0800

Russ,

Good to hear from you.  Apologies for making things difficult.
Responses embedded below.

Mike

> From: Housley, Russ [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2002 2:31 PM
> To: Michael Myers
> Cc: [email-masked]
> Subject: RE: Validation policy in DPV/DPD rqmts
>
>
> Mike:
>
> I think that each server will have a default, but I
> do not think that each server will have the same
> policy as the default.

I agree.  Probably so.

But I strongly suspect that those defaults will all identify
precisely the same logic.  Namely:  1) the path is checked; 2)
no revocation exists among the path's certificates; and, 3)the
path terminates in a locally trusted root.  Thus, modulo WG
consensus, I continue to advocate that PKIX define an OID that
identifies, among other elements, compliance to PKIX' own RFC
2459 as a defining characteristic of what it means for a
certificate to valid.  Maybe it's just me, but I'm having a very
hard time trying to understand why that might not be the case
given all the cycles the WG has put into this stuff over the
years.

> To that end, I do not  think that it is useful to have the
> request specify  at the default should be used.

In the I-D there exists no requirement (to my reading) that a
client MUST specify in its *request* use of a default.  It MAY
do so, but there is no MUST.  The critical MUST is on the server
side.  A server MUST indicate the policy used in performing
delegated path validation.

My concern is, given that server-side MUST, in the case when an
environment hasn't the organizational bandwidth to fully
consider all the issues, can we, and indeed should we, define
for them a minimal baseline?  Especially given all the work the
WG has been doing related to that issue.  What does it mean for
an X.509 certificate to be "valid".

> I would like the response to state the policy that was
actually
> used.  If there is not an OID defined that means my default,
then
> the issue is avoided.

This entire issue can be quickly resolved by simply changing
that server-side MUST to a MAY.

Mike

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 28 Feb 2002 11:38:35 +0100

Mike,

Russ gave you the right answer (copied below).

> used.  If there is not an OID defined that means my default, then the issue

The requirements are simple, if the client does not indicate the policy to 
be used in his request then the default policy of the server will be used, 
and the response will indicate the policy that was actually used.

(...)

> >production of running code.  

Since you confessed, you are forgiven. :-)

There is a difference between :

1) the logic of an algorithm (RFC 2459 describes one algorithm) and 
2) both the logic of an algorithm and the parameters used by that logic 
   (i.e. what a validation policy is).

The parameters are well decribed in the document. Without values for these
parameters, you cannot apply a policy nor know which policy has been used.

In your answer to Russ you said: "This entire issue can be quickly resolved
by simply changing that server-side MUST to a MAY." I would not agree.

A server may first support one policy, so it is the default. Three months
later, a new policy is supported and then it becomes the default. The
previous one is still supported. If you store two signed responses from two
different times, it would not be possible to directly know which policy has
been used. Making the reference of the validation policy mandatory in the 
response, solves the problem.

I hope we can now close this issue.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 28 Feb 2002 09:24:46 -0500

Mike:

My concern is "locally trusted roots."  Specifying those roots should be an 
element of the policy.

Russ

---

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Feb 2002 10:04:08 -0500

>given all the cycles the WG has put into this stuff over the

The local policy will need to reflect which roots are being used and 
what additional data is associated with each (for example, name 
constraints, policy mapping, etc.). It doesn't seem feasible to 
represent all of that with a common, default OID given the 
site-to-site variability that will ensue.

>that server-side MUST to a MAY.

I would think the best approach would be for an organization to tell 
its users what the local, default OID is, via some out of band means. 
Then they can pass in this policy and the server need not pass back 
the policy info.  However, in the absence of distribution of this 
info, I worry that users might get unexpected results, and no 
appropriate feedback.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 28 Feb 2002 07:48:58 -0800

Steve, Russ:

OK, I get it now.  It's basically a roots issue.

Then perhaps the I-D could include some informative text that
expands on what a rational validation policy might likely
address.

Mike

Michael Myers
t: +415.819.1362

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 28 Feb 2002 18:01:37 +0100

Michael,

> expands on what a rational validation policy might likely

Some text is already there. 

Take a look at section 7.1. Validation Policy

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 28 Feb 2002 10:22:04 -0800

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: Thu, 28 Feb 2002 11:10:10 -0800

> From: Denis Pinkas [mailto:[email-masked]]
>

Denis,

I read that part.  I'm not arguing with anything said there.
But the text of that section is so full of MAYs and
tutorial-like advice that it's unclear what this document is
actually establishing with respect to the constituent elements
of a validation policy other than the MUST with respect to a
root.

I had expected something with a bit more or structural bite to
it, roughly in line with RFC 2527 as that document guides the
production of CPs and CPSs, although considerably reduced.
Something along the lines of "A validation policy SHOULD at a
minimum assert: <element 1>, <element 2>, <element 3>" and so
on.  Maybe even elevate that to a SHALL.

That's why I was digging into the DEFAULT policy issue, in order
to bring to the surface our collective thinking on that meta
structure.  I think we all know more or less what it is.  I
think we should write that down in a more structured fashion
than currently expressed by Section 7.1.

Is that possible?

Mike

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 28 Feb 2002 15:38:59 -0500

>expands on what a rational validation policy might likely

Is this really something that needs to be in the requirements document?

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 28 Feb 2002 14:14:17 -0800

Russ,

Section 7.1 addresses the issues but not in my opinion to useful
degree of clarity.  Additional work in this area might improve
the document.

Mike

Michael Myers
t: +415.819.1362

> Sent: Thursday, February 28, 2002 12:39 PM
> To: Michael Myers
> Cc: [email-masked]