Subject: Delegated Path Validation draft.

From: Michael Zolotarev <[email-masked]>
Date: Thu, 12 Oct 2000 18:53:58 +1000

A couple of comments.

Should we require the id-pkix-ocsp-valid-req extension to be marked as
critical?

If neither DVPOptions::initialPolicySet nor DVPOptions::trustPoints is
included in the request, the draft says "SHALL omit both optional fields".
This is not clear. Should we include an empty sequence into extension? or
probably a zero-lenght OCTET STRING value?

What should the server do if the both initialPolicySet and trustPoints are
missing? I think the draft should say something about it.

Michael

---

From: Michael Myers <[email-masked]>
Date: Thu, 12 Oct 2000 13:47:45 -0700

Michael,

Regarding the criticality flag, in fact I'd rather change 2560's current
"Support for any specific extension is OPTIONAL. The critical flag SHOULD
NOT be set for any of them." to SHALL NOT set the criticality flag.  I
believe this will improve interoperability and reduce confusion with no loss
of security assurances.  Are there are any criticality flag advocates out
there who would wish to argue a contrary position?

I propose to clarify the "omit both fields" requirement to read "If neither
initialPolicySet nor trustPoints are included in the request, the DPVOptions
structure SHALL be encoded as an SEQUENCE of zero length (that is, an empty
sequence)."

And I will give some thought to the instance when a relying party includes
both initialPolicySet and trustPoints.  In fact, we had talked at length
about these kind of combinatorics in blocking out the draft, but I wanted
first to get a sounding from the WG on the overall approach before drilling
down too deeply.  Minimally, we need an "invalid" response value in
BasicOCSPResponse to distinguish the case when a certificate isn't revoked
but fails to validate against OCSP request extension content.

Mike

---

From: Michael Zolotarev <[email-masked]>
Date: Fri, 13 Oct 2000 10:51:47 +1000

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]]
> Sent: Friday, 13 October 2000 6:48
> To: Michael Zolotarev; [email-masked]
> Subject: RE: Delegated Path Validation draft.
> 
> 
> Michael,
> 

In my opinion the extentions defined for DPV (and DPD as a matter of fact)
must be marked as critical. The client adds those extensions as an indicator
of the type of service it expects. Leaving those extension non-critical
would be just wrong, equivalent to say "the client wants DPV (not basic
OCSP), but the responder may ingore it". It obviously defeats the purpose.

> structure SHALL be encoded as an SEQUENCE of zero length 

Agree.

> but fails to validate against OCSP request extension content.

I agree. The client asks the question "Can this cert be validated given that
policy and trust critirea, provided that the cert is NOT 
revoked". Therefore, if any of the conditions fail, the response must be
'invalid'.

However, my original question was what does the server do if both Policy and
Trust components aren't there. I'd assume that the server has two options:
1. Check revocation status and then apply some 'default' implicit policy and
trust points. This would be an option for a pre-configured (i.e.
enterprise-wide) responder.
2. Check revocation status and then discard the request on the basis that
there is no 'implicit' verification context which the server can apply (at
all, or for that particular certificate). In this case the error code can be
either 'invalid', if the cert is revoked, or 'unknown', indicating that the
cert is not revoked, but validation couldn't be executed due to lack of
input conditions.

Michael

---

From: [email-masked]
Date: Fri, 13 Oct 2000 00:08:29 -0400

I'm a bit removed from OCSP details these days.  Can an OCSP repsonder
indicate which extensions in the request it didn't like?

Even if this is not possible, I see no reason to remove the CRITICALITY
feature.  A client can always resend without that bit if it decides
the semantics are optional after all.

---

From: Frank Balluffi <[email-masked]>
Date: Fri, 13 Oct 2000 07:04:16 -0700

> cert is not revoked, but validation couldn't be executed due 

Considering that validating a path includes more steps than checking the
revocation status of each certificate (in the path), and that at least one
of these steps should not "check out" under normal operations (or at least
until there are no adversaries), I expect that clients will want to know why
a path was not valid, and possibly why a path was valid. For example:

1. the server did not possess the necessary information to validate each
certificate
2. the server applied some default policy
3. a certificate's basic information (e.g., its signature, validity period,
revocation status or subject name) did not "check out" (i.e., adhere to RFC
2459, section 6.1)
4. a certificate extension did not "check out"

RFC 2560 addresses some failure paths (e.g., malformed request, internal
error). So my answer to your question is that the protocol needs to:

a. provide a mechanism for the server to return detailed information about
why the server deemed the path valid or not valid (e.g., it applied some
default policy, it encountered a "bad" extension, etc.)
b. define a set of cases and each's expected behavior

Frank

---

From: Michael Zolotarev <[email-masked]>
Date: Sat, 14 Oct 2000 01:19:07 +1000

Frank,

please, do not go this way. Keep it simple. 
Realistically speaking, a client only needs a simple 'yes' or 'now'. The
whole purpose of defining a TTP for path validation was to simplify things.

If a client is not satisfied by the 'yes' or 'now', there are other options
(other then been shot, of course). Mind you I fail undestand why a client
would ever ask 'why yes?' - would like to hear from you on this one,
frankly. 

To find out why 'No', a client can use DPD to get the path, and then ask DPV
for each component in the path.

Otherwise we'll end up with a hugely blown-up service, which wasn't the
purpose of the exercise.

M

-----Original Message-----
From: Frank Balluffi [mailto:[email-masked]]
Sent: Saturday, October 14, 2000 12:04 AM
To: 'Michael Zolotarev'; Michael Myers; [email-masked]
Subject: RE: Delegated Path Validation draft.

Frank

---

From: Frank Balluffi <[email-masked]>
Date: Fri, 13 Oct 2000 07:35:06 -0700

Michael,

I strongly agree with your desire to keep it simple. Unfortunately, I am
learning as I go and do not know all of the answers to how this stuff will
be used. For example, I recently learned that there are many certificates in
the real world that do pass RFC 2459, section 6.1 (e.g., illegal criticality
flags, improper policy identifier values, etc.). I have no idea how the
world will choose to deal with these certificates. Also, what is a client?
An end-user device (e.g., an internet-enabled phone)? A gateway? Perhaps a
gateway will want more detailed information than an end-user device. I don't
know. As long as we can find a simple way to deal with complexity, I am
happy (e.g., by just saying no).

Frank

> From: Michael Zolotarev [mailto:[email-masked]]
> Sent: Friday, October 13, 2000 11:19 AM
> To: 'Frank Balluffi'; Michael Zolotarev; Michael Myers;
> [email-masked]

---

From: Michael Myers <[email-masked]>
Date: Fri, 13 Oct 2000 14:50:04 -0700

I generally agree.  I'm doing all I can to advocate for a principle that
"simpler is better until compelling proven otherwise." However, it was a
criticism of 2560 that there exists more easily predictable error status
values than 2560 currently recognizes.  I propose that we take a look at
that, building on Frank's suggestions and perhaps those of others, but that
we do not create a sub-protocol for error cause discovery.

Mike

> Sent: Friday, October 13, 2000 8:19 AM

---

From: Frank Balluffi <[email-masked]>
Date: Mon, 16 Oct 2000 19:09:55 -0700

> for each component in the path.

I agree that a client should be able to request the path used during DPV,
but I do not see any guarantee that a DPD response will contain the path
used to generate a previous DPV response. Is my understanding correct?

Frank

---

From: Frank Balluffi <[email-masked]>
Date: Mon, 16 Oct 2000 19:17:11 -0700

Michael Zolotarev said:

> Frank - I'm still standing on attention to hear why do you 
> think a client
> may want to know 'why Yes'. No jokes. That'd be one of the 
> major requirement
> for audit performed on DPV, if there is for example a legal reason, or
> something...

If a server were to apply a policy not requested by a client, returning this
information to the client might be valuable. Obviously, this assumes that
the protocol allows such behavior.

Frank

---

From: Michael Zolotarev <[email-masked]>
Date: Tue, 17 Oct 2000 13:43:41 +1000

Frank,

The path discovery algorithm is [meant to be] deterministic. Theoretically,
two different DPD boxes, regardless if they execute the same or different
path building algorithms, should come up with the same path for the same
certificate, provided that the input conditions are identical. The order of
components in the path may vary, though, but it doesn't change a lot.

Therefore it should be reasonable to expect that a path generated/obtained
by the DPV will be identical to a path generated by any compliant
path-discovery engine.

Michael

> Sent: Tuesday, 17 October 2000 12:10
> To: 'Michael Zolotarev'; Frank Balluffi; Michael Myers;
> [email-masked]