Subject: Re: OCSPv2, DPV and DPD issues summary (long)

From: Stephen Kent <[email-masked]>
Date: Thu, 1 Feb 2001 17:54:18 -0500

Mike,

I will try to get around to reading your message tomorrow, as well as 
Denis' message on DPV/DPD requirements from a week ago.  It is time 
for the WG to settle on requirements and move on to the next phase of 
the process. I greatly appreciate the effort you have put into 
aggregating this material and look forward to producing a revised 
requirements document for DPV and DPD that the WG can review, comment 
upon, and adopt. Several additional WG members have been very active 
in contributing to the discussion and I think we have progressed in 
our understanding of the nature and some of the subtleties of the 
problems that we are trying to solve.  Several suggestions have been 
made that will allow us to narrow our focus and eliminate some 
options that were originally put forth, so that we can have standards 
that will be fully functional yet not overly complex.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Feb 2001 16:28:08 -0500

Mike,

I found your compendium very helpful in preparing the next rev of the 
requirements document. I'll keep this message short by responding 
only to thye summary points:

><snip>
>SUMMARY
>
>1.  Ambiguity in requirement 2.2 re: single certs    [Covey, 1/2/01]
>     (Kent to to update rqmts spec)

OK

>2.  Lack of specificity in rqmt 2.2 re: sort order   [Covey, 1/2/01]
>     (Kent is comfortable with proposal)

OK

>3.  Server usage of data proferred by client         [Covey, 1/3/01]
>     (Kent to to update rqmts spec)

OK

>4.  Should a DPD server nonce a DPV server?          [Covey, 1/3/01]
>     (Rqmt under study; no consensus to mandate).

odd wording, i.e., making "nonce" into a verb! I have included a 
provision for the client to supply a nonce and a flag to enable a 
client to require that the server use this nonce in OCSP requests it 
issues on behalf of the client. if not invoked by the client, the 
server is free to use cached OSCP responses, or to supply its own 
nonce in an OCSP request. the text of the RFC should discuss the 
implications of this.

>5.  Should DPD response syntax enable recursion?     [Covey, 1/4/01]
>     (OCSP framework already enables recusion)

For now I don't see the utility of supporting nested responses in 
DPV, or DPD. For a DPD server, it should be able to extract any 
certs, CRLs, or OCSP responses it receives and pass on the extracted 
data. In fact, it may not want to pass one all the data it gets from 
another DPD server, i.e., it may winnow it. In case of DPV, we 
discussed the fact that the client trusts the DPV server it uses, and 
trust is not transitive, so there does not appear to be a need for a 
DPV response to convey another DPV response, although a DPV server 
may log the responses and save them in case they turn out to be wrong 
and the server operator needs to track down the source of the error. 
If a DPV server makes use of a DPD server, or vice versa, I think the 
arguments above apply. So, for now, I see no need to support nested 
responses.

>6.  There exists a need for loop detection.          [Sylvester, 1/11/01]
>     (proposed: amend OCSPv2 and DPV I-Ds)

This still seems like a good requirement, and I'm looking for a 
proposal of how to do it.

>7.  Transitive trust and recursion                   [Covey, 1/10/01]
>     (proposed: amend OCSPv2 and DPV I-Ds)

see recursion discussion and proposed resolution above.

>8.  Should DPD responses be signed?                  [Manger, 1/24/01]
>     (No, DPD responses do not need to be signed.)

signing is an option in my revised spec.

>9.  A signature is not needed for DPV in all cases.  [Kent, 1/24/01]
>     (proposed: OCSPv2 and DPV I-Ds will continue to
>      mandate sigs pending WG discussion and consensus
>      to the contrary.)

I note the phrase "to the contrary" which is not a good sign :-). In 
your detailed response you suggest that NR is a primary motivation 
for DPV. I don't think the WG discussion supports that assertion, 
though I can't argue with you re what may have been your primary 
motivation. My analysis is that we promote the use of DPV for any 
client that is not PKI aware or that wishes to offload cert 
validation processing. That's what the motivation text has said for 
some time. Given that, NR is not implied as a primary rationale for 
DPV.

>10. Support for non-ASN.1-capable clients            [Hanna, 1/17/01]
>     (The OCSPv2, DPV and DPD efforts as authored
>      will not address XML.)

yes, it's dead for now.

>11. Are post-facto queries a requirement?            [Linn, 1/20/01]
>     (Existing support for post-facto queries in
>      RFC 2560 will be enhanced in the OCSPv2
>      and DPV I-Ds.)

my next rev allows a client to request it, but leaves support (or 
support for some time interval) at the discretion of the server.

>12. Updates to I-Ds in response to rqmts             [Pinkas, 1/23/01]
>     (Pending rqmts consensus and list response to
>      proposals. Ad-hoc working session(s) in
>      Minneapolis are likely.)

this is not an input to the requirements spec, but an action item for 
those proposing protocols to meet the spec, right?

>13. Need for validation controls beyond 2459 rules   [Pinkas, 1/23/01]
>     (DPD paths should (shall?) be valid.)

I have picked parameters based on Denis's SMIME ESP example, and 
comments from Russ. But, I don't agree with your conclusion in the 
details. We still do not have consensus on whether a client expects a 
valid path from a DPD server, or only a probably valid path. The 
inclusion of revocation status data in the DPD response is easily 
made into a client-specified option. The real issue is whether we 
require a DPD server to be capable of returning the data whenever it 
claims to return a valid path.

>14. Ability to mandate name forms in DPD responses.  [Housley, 1/24/01]
>     (Name constraints are preferable, esp. wrt to
>      cross certs).

added to the next rev.

the next rev will include a slightly edited motivation discussion. It 
will propose ASN.1 syntax for DPD and DPV client requests and server 
responses, done separately. My ASN.1 will have errors, I am sure, but 
the point of specifying something at this point is to make more 
concrete the data items being exchanged, as well as the processing 
requirements associated with the exchanged data.

I am out at the NDSS this week, so nothing will likely be ready until 
next week. Meanwhile, we have a few open issues that can continue to 
be addressed on the list.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 7 Feb 2001 08:32:50 -0800

To: Stephen Kent
Subject: RE: OCSPv2, DPV and DPD issues summary (long)

Steve,

A few specific responses embedded below.

Mike

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, February 06, 2001 1:28 PM
> To: Michael Myers
> Cc: [email-masked]
> Subject: Re: OCSPv2, DPV and DPD issues summary (long)
>
>
> Mike,
>

OK.

> arguments above apply. So, for now, I see no need to support nested

I think we may be out of sync.  I too see no need to address this issue
given that OCSP-based solutions already exist to address these requirements.
See my prior note on this point.

> proposal of how to do it.

Me too.  It's a very good point Peter brought up.  We'll see what we can do
on the OCSPv2 side.

> signing is an option in my revised spec.

I have no problems on optional signing from an OCSP perspective.

> some time. Given that, NR is not implied as a primary rationale for

True, NR is a subset of PKI-based security needs, but source authentication
needs remain.  Also, response signing is mandated in RFC 2560 (at least for
revocation status requests.)  I'm assuming that our work in updating
editorial issues in 2560 as it moves forward excludes substantive changes.
Perhaps as this relates to OCSP it's better to soften this SHALL to a MAY in
the OCSPv2 work?

> those proposing protocols to meet the spec, right?

Correct.  We held a few in San Diego.

> claims to return a valid path.

The real question is:  "Is a DPD server subject to security architecture
requirements (e.g. Common Criteria), or is it simply an 'untrusted' relay?"
given this requirement.  If the WG can resolve a position to this question,
we'll be quick to closure on the issue.

> be addressed on the list.

I'm confident we share a roughly equivalent facility with ASN.1, but what
I'm concerned about is how this relates to the ASN.1-level work several of
us have been engaged on regarding OCSP-based DPV and DPD I-Ds since
Pittsburg?  I was under the impression that there would ultimately exist a
high-level requirements document that would govern these
implementation-level issues and then the various camps would go off and work
on technical responses to that direction.  In fact, I'm in the process right
now of doing just based on the rough consensus to date in order to get
something out to the OCSPv2, DPD and DPV co-authors for their review and
contributions.

---

From: "Carlin Covey" <[email-masked]>
Date: Wed, 7 Feb 2001 09:46:43 -0700

<snip>

[Carlin]  Steve, I'm afraid that I am the party guilty of the 
          "verbification."  (Now here I have made the noun "verb"
          into the verb "verbify" and then made back the verb back
          into the noun "verbification." ;>} ) As you may recall, the 
          usage of "nonce" as a verb started out in this thread as my 
          tortured play ;>) on the lines from a play, to wit (or perhaps, 
          to half-wit): "to nonce or not to nonce"  [that is the question].
          Perhaps I will later make a verb into a noun to maintain
          verb/noun parity.  ;>)

          Sorry, my tongue sometimes gets wedged in my cheek. Having now 
          pulled it out, I commend with your solution to the relayed nonce 
          problem.

[Carlin}  I agree that we can postpone (perhaps indefinitely) introducing
          nesting into the DPV and DPD response syntax. 

          I am in favor of, or neutral on, the remainder of the issues
          enumerated in Mike's and Steve's emails.  As the perpetrator
          of issues 4 and 5, I felt obligated to aid in their closure.

Regards,
Carlin

---------------------------

- Carlin Covey
  Cylink Corp.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 8 Feb 2001 17:30:21 -0500

Mike,

>See my prior note on this point.

Yes, we may be out of sync. In this thread we're interested only in 
DPD/DPV requirements, so I get confused by references to anything 
else, e.g., OCSP.

>I have no problems on optional signing from an OCSP perspective.

Again, why a reference to OCSP? We're working on DPD/DPV!

>Perhaps as this relates to OCSP it's better to soften this SHALL to a MAY in

An extended version of OCSP is only one candidate for meeting the 
DPD/DPV requirements. Thus I don't want to prejudice these 
requirements by reference to OCSP.

>we'll be quick to closure on the issue.

I think we are way out of sync here. As we have always used the term, 
"trust" in the DPV server is independent of assurance and of any 
formal evaluation criteria, e.g., Common Criteria (although one might 
argue that it should be otherwise). So, Ihave to  reject your 
restatement of this question.

>something out to the OCSPv2, DPD and DPV co-authors for their review and

I don't mean to preempt the work you and others have been doing. As 
the requirements discussion has progressed, it has become clear to me 
that we have to be fairly precise in describing them. So, my ASN.1 
description is not intended to be overly proscriptive, but will be 
used to make the requirements more concrete. However, some syntax 
probably does need to be tightly included into the requirements. For 
example, if we want to transparently carry certs and CRLs as an aid 
to servers, and if these are to be extracted from other protocols, 
then it makes sense to specify the syntax in terms of these, 
pre-existing formats. Nonetheless, don't worry about my strawman 
syntax; it's mostly a means of presenting a more concrete description 
of the requirements and I am not tied to it (in most cases).

Steve

---

From: "Carlin Covey" <[email-masked]>
Date: Fri, 9 Feb 2001 09:56:07 -0700

<snip>

[Carlin]  Just to throw my tuppence in here.....

          Mike's usage of the term "untrusted" is quite
          familiar to those of us who have long been involved
          in computer security work.  This usage simply reflects
          the notion that one should not rely on information unless
          there is good reason to believe that it is correct.
          (But then, there's a sucker born every minute.....)

          It appears to me that both Mike and Steve agree
          (as do I) that the premise of the DPD service is
          that there is no "good reason" (i.e. formal security
          evaluation) for the client to rely on the correctness
          of the response received from a DPD server.  As we
          say in the US, the client is "from Missouri" and has
          to verify this information for himself.

          We have been using the term "trust" in the DPV context
          to mean that the DPV client does accept the response
          from the server as "gospel."  Perhaps we should instead
          have been using the term "rely," because the means by
          which the client or client's organization) makes the
          decision to believe the data is out of scope of the DPV
          specification.  The decision could be consciously made
          without evidence ("faith") or made with evidence
          {"science"), both of which are conscious trust decisions,
          or the decision could be made unconsciously (see sucker
          natal comment above), in which case the reliance is based
          more on negligence than on trust. Once the reliance
          decision is made, the means by which this decision is
          encoded for automated processing is within scope of the
          DPV specification.

          I hope that, modulo a few lexicology debates, we are all in
          agreement that a DPV client relies on a DPV response, but a
          DPD client does not rely on a DPD response.

          (Perhaps not really worth tuppence, but with depreciation ...)

Regards,

Carlin

- Carlin Covey
  Cylink Corp.