Subject: Re: (DVD to DVP ga fajii shisutemu desu ka?)

From: Michael Sierchio <[email-masked]>
Date: Mon, 29 Jan 2001 11:25:43 -0800

Bob Jueneman wrote:
> 
> Back in 1989, I wrote a paper entitled "Integrity Controls for
> Military and Commercial Applications". as a contribution to an
> Invitational Workshop on Data Integrity held at NIST. 

Arrived Saturday, thanks.  More later...

Michael

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 30 Jan 2001 12:25:46 -0800

All,

I've been compiling over the roughly 250 messages posted to PKIX since
10 Nov 00 regarding OCSPv2, DPV and DPD.  I thought others might find
this compilation useful as well.

This is by no means definitive, just a tool I'm using to track issues.
Please accept my apology in advance if I overlooked a concern you
raised or if I overly compressed your position on a point.  You may
email me at [email-masked] with corrections.

A summary is immediately below.  See details section further on for
additional context. Thanks for all for your interest in what I thought
four years ago would be a simple answer to a fundamental problem.

Mike

SUMMARY

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DETAILS

Ambiguity in requirement 2.2 re: single certs [Covey, 1/2/01]
-------------------------------------------------------------
Current text:
"2.2 A server must be able to return one or more sets of certification paths
and associated revocation data as a result of path discovery/validation . .
. ."

Proposed text:
"2.2 A server must be able to return one or more sets of certification paths
and associated revocation data as a result of path discovery/validation
related to a single target certificate."

Resolution/Action:
Kent to update rqmts spec accordingly subject WG consensus re: multiple
certificates [Kent, 1/4/01].

Comment:
RFC 2560 already enables a single message to specify multiple certificates
via  the requestList SEQUENCE OF Request syntax (cf. section 4.1.1  Request
Syntax of 2560).  This syntax is carried forward in the OCSPv2 draft.
Historically, this is the "validate my entire address book in one message"
OCSP requirement.

Lack of specificity in rqmt 2.2 re: sort order [Covey, 1/2/01]
--------------------------------------------------------------
Current text:
"2.2 A server must be able to return one or more sets of certification paths
and associated revocation data as a result of path discovery/validation.
Each set shall consist of an ordered list of certificates and associated
CRLs and/or OCSP responses."

Proposed text:
"Each set shall consist of a list of pairs of certificates and CRLs and/or
OCSP responses, in certificate path order."

Resolution/Action:
Kent is comfortable with proposal, subject to WG objections [Kent, 1/4/01].

Issue: Server usage of data proferred by client [Covey, 1/3/01]
---------------------------------------------------------------
Current text:
"1.1 A client request can contain a single certificate or a certificate
chain terminating in the "target" certificate, to assist the server in path
construction."

"1.2 A client request can contain one or more revocation data items, to
assist the server in path validation."

Proposed text:
[Augment above with]
"The server may use a certificate chain proffered by the client, but is not
obligated to do so. If revocation data proffered by the client indicates
that a certificate is revoked, the server must reject as invalid any
certificate paths containing this certificate. If revocation data proffered
by the client indicates that a certificate is not revoked, the server must
independently verify this data before accepting as valid any certificate
paths containing this certificate."

Resolution/Action:
Kent to incorporate into rqmts doc [Kent, 1/4/01].

Issue: Should a DPD server nonce a DPV server? [Covey, 1/3/01]
--------------------------------------------------------------
Clarification:
Nonces are optional in RFC 2560 and the OCSPv2 I-D.  One OCSPv2 server
servicing a DPD request may nonce a DPV request to a subordinate OCSPv2
server while the client to the first server did not do so.

Resolution/Action:
Rqmt under study [Kent, 1/4/01].
No consensus to mandate nonces [Kent & Williams, 1/15/01 - 1/24/01].

Issue:  Should DPD response syntax enable recursion? [Covey, 1/4/01].
---------------------------------------------------------------------
Clarification:
The DPD I-D is intended to enable clients to acquire certificate path
validation data.  These data may be accumulated from multiple and diverse
sources, including another DPD server.  So the question is, should the DPD
syntax (and, implicitly, the corresponding elements of the OCSPv2 framework
to the extent it's relevant) be amended to accomodate inclusion of DPD
responses within DPD responses?  Among other effects, doing so would
preserve the timestamp(s) (if any) on the embedded DPD response(s).

Discussion:
This is still an R&D topic for now, not yet ready for standardization [Kent,
1/5/01].

Solve the immediate problem then generalize if possible [Kent, 1/5/01].

"A server should have the ability to return in the response a rather limited
set of well-known protocol elements, certs, crls, ocsp response, pkistatus,
DPV response, at least those that he had used to make up its decision or
which it wishes to communicate to the client for whatever reason."
[Sylvester, 1/10/01]

"I second Peter's strawman proposal." [Covey, 1/10/01]

"I thinbk [sic] we are in agreement that the set of data returned by a DPD
or DPV server will be limited in scope and well defined, i.e., sequences of
certs, CRLs, and OCSP responses are the initial set. Whether we allow
recursion and allow DPV responses is still an open question."  [Kent,
1/10/01]

Resolution:
Unresolved; need to push on-list for further clarity re: Kent's 1/10/01 msg
above.

Issue:  There exists a need for loop detection [Sylvester, 1/11/01].
--------------------------------------------------------------------
Proposed text:
"In some environment a DPV server may be operated as a relay/broker to other
services. In order to cover possible misconfigurations in such situations,
the protocols must provide an efficient means to detect request loops. hop
counts or 'Received and relayed by XXX' trace elements are possible means.
It is up to the relaying server how to interprete and transform a response
from another server. In any case a DPV must add apply its own authentication
mecanism, e;g. its own signature. Possible reponses include an encapsulation
of the initial reponse, or simple replacement of the securiy envelope."
[Sylvester, 1/11/01]

Comment:
OCSP servers today are known to be operated in relayed configuration (cf.
the "four corner" model).

Resolution:
(proposed) Since OCSP servers today are known to operate in a relay
configuration (cf. the "four corner" trust model) and further, that prior
system-level architectural practices strongly suggest that this feature is
inevitable (e.g. DNS), the loop detection requirement MUST be addressed on
an OPTIONAL basis.

Issue:  Transitive trust and recursion [Covey, 1/10/01]
-------------------------------------------------------
Clarification:
"If the protocol permits a DPV/DPD response to include embedded DPD/DPD
responses from other servers, then the syntax will be a bit more complex
than it might be otherwise."  [Covey, 1/10/01]

Proposed:
Provide hooks in the protocol to limit the extent of transitive trust.
[Covey, 1/10/01]

Discussion:
(largely via "Recursion Issues" thread)

"A DPV/DPD server could contact another server and repackage the response
that it receives." [Covey, 1/10/01]

" . . . unless OCSP allows for recursion itself, I think we have an inherent
limit in this case, i.e., it's not recursive, just 1-level delegation."
[Kent, 1/11/01].

"My preference is for server 1 to publicize the fact that it trusts
information obtained from certain other servers, and the client can take
that fact into account when deciding whether to trust server 1." [Covey,
1/12/01]

Do OCSP responses carry data that tie a response to a requestor? [Kent,
1/12/01]

"Only if the requestor uses a nonce."  [Salz, 1/12/01]

"It is better to repackage the response instead of using a recursive
approach, because the client should be unaware
of the recursion."  [Jakhar, 1/12/01].

". . . I'm not sure I want the DPV response to be used recursively, yet."
[Kent, 1/12/01]

". . . it seems useful to keep it [a DPV response] as is when used by a
client, even if this client uses the content of the response to create some
other statement or whatever to its type of client."  [Sylvester, 1/14/01].

RFC 2560/OCSP, OCSPv2, DPV and DPD all enable recursion today [Myers, to be
posted].

Proposed Action:
Draft language in OCSPv2, DPV and DPD as appropriate regarding OPTIONAL
constraints on transitive trust, drawing notice to the inherent recursive
capabilities of the protocol as defined, propose updated drafts to the list
for WG consensus.

Issue:  Should DPD responses be signed? [Manger, 1/24/01]
---------------------------------------------------------
Comments:
Since the objects being returned via DPD (certs, CRLs and potentially
recursive OCSP responses) are themselves signed, there exists no integrity
or authentication risks that require signing DPD responses.  Some
environments might wish to architect at the system level a solution that
confirms the identity of approved responders.  [Myers, this note]

"Signing is not required, but some form of authentication and integrity
checking should be employed to detect attacks on the
communications between the client and server, e.g., as a countermeasure for
more subtle DoS attacks." [Kent, 1/24/01].

Resolution:
DPD responses do not need to be signed.

Issue: Should DPV responses be signed?
--------------------------------------
Resolution:
"A signature is not needed for DPV in all cases either. Only if the client
wants NR for the DPV response is it necessary." [Kent, 1/24/01]

Comments:
DPV exists largely to enable NR arguments wrt existing and emerging digital
signature legislation. [Myers, this note]

Resolution:
RFC 2560 requires digital signatures on all "definitive" responses.  OCSPv2
and DPV draft maintains this mandate subject to WG consensus to the
contrary. [Myers, this note]

Issue: "Do we need to support non-PKI aware, non-ASN.1-capable DPV clients?"
[Hanna, 1/17/01]
----------------------------------------------------------------------------
-----------------
Comments:
The OCSPv2/DPV/DPD team concluded in Pittsburg to not address XML issues.
[Myers, this note].

[Such clients should not be supported by PKIX]. "We have not submitted XKMS
to the PKIX list because (amongst other reasons) the group have 20 odd
drafts to clear from the pipeline as it is."  [Hallam-Baker, 1/17/01]

" . . . the consensus answer is "No, we do not need to support non-PKI
aware, non-ASN.1-capable DPV clients.""  [Hanna, 1/19/01]

"I have to concur - ASN.1 decoders can be relatively small.  Steve's
suggestion simplifies this issue and makes it easier for us to move forward
on solutions."  [Cross, 1/19/01]

"We do not need to support non-ASN.1-capable DPV clients."  [Pinkas,
1/22/01].

Resolution:
The OCSPv2, DPV and DPD efforts as authored will not address XML.

Issue:  Are post-facto queries a requirement?  [Linn, 1/20/01]
---------------------------------------------------------------
Discussion:
"I think it'd be useful to be able to support post-facto queries in the DPV
framework." [Linn, 1/20/01]

"I think this is a very good idea.  I strongly encourage us to do it."
[Housley, 1/22/01].

We agree.  [Myers, Pinkas, Scheibelhofer et. al. in various public and
private exchanges over the past several years.  One is Myers, 8/31/00 with
the subject, "OCSP support for historical reference to certificate
suspension".]

Bear in mind the effects of suspension on historial references. [Myers,
Covey and others.]

"1. If such service would exist, then it should be clear that it should only
be optional."  [Pinkas, 1/22/01]

"2.a) Such a service would not work as soon as revocation status would be
obtained through OCSP responses. There is a move to get the revocation
status of the leaf certificate using OCSP. Such service would thus be
unusable in that case."  [Pinkas, 1/22/01]

"2.b) Such a service would work if CRLs and delta CRls were all captured by
a TTP *different* from the CA. The size of the storage might become quite
important."   [Pinkas, 1/22/01]

"2.c) Such a service would degrade the security. Let me explain. If people
can say: "We will check later, since we have a server always giving us the
right answer", then will rely on it and will not ask for the certificatio
path and revocation information at the time of initial verification. What
can happen between initial verification and a later verification ? The
answer is: a key compromise of a CA issuing key."  [Pinkas, 1/22/01]

"I agree with 1, 2a, and 2b. I cannot accept 2c." [Housley, 1/22/01]

"As long as it is understood that a non-repudiation service (whether
technical or a stronger variant) should not rely primarily on post-facto
validation queries, supporting them is IMO not harmful."  [Gindin, 1/22/01]

DPV does not need to specify a 3rd party time stamp on CRLs.  "The STIME
working group is going to provide a straightforward mechanism for [a 3rd
party time stamp on the CRLs]".  [Housley, 1/23/01].

"A DPV server should not be restricted to use an external timestamp. . . .
having TWO signatures seems some overhead to me."  [Sylvester, 1/23/01]

Resolution:
(proposed) The OCSPv2 and DPV drafts will address historical references,
incorporating the concept of suspension, but will NOT mandate support for
CRL-based suspension in order to deliver on OCSP-based suspension.  The
proposed standard will enable non-CRL means of maintaining records
suspension subject assertions regarding the integrity and authenticity of
those records in the Security Considerations section.  Final syntax and
semantics are TBD subject to WG consensus on the amendments to the DPV and
DPD I-Ds entering the next IETF, especially as they relate to a linkage to
timestamping.

Updates to I-Ds in response to rqmts [Pinkas, 1/23/01]
------------------------------------------------------
Denis proposes ASN.1 and implementation-level updates to DPV and DPD I-Ds in
response to requirements consensus.

Resolution:
Pending consensus on rqmts and list-based response to proposals. Ad-hoc
working sessions in Minneapolis are likely although it would be very useful
to get this all resolved on-list.

Need for validation controls beyond 2459 rules [Pinkas, 1/23/01]
----------------------------------------------------------------
Comments:

". . . some validation policies may request some (even private)extensions in
the leaf certificate to be present for a certificate to be "valid" according
to a validation policy. Hence a response "valid", should be interpreted as a
minimum condition to be valid, but not always as a sufficient condition. We
would have to be very careful when explaining what a "valid" status means."
[Pinkas, 1/23/01]

Resolution:
"Good point. . . . I think we have some flexibility here, but we need to
pick a set of parameters and go forward." [Kent, 1/23/01]

DPD paths should be valid.  [Pinkas, 1/23/01]
---------------------------------------------
Clarification:
"DPD only *helps* a PKI-aware client to know whether a certificate is valid.
It is better to return what can be returned as far a revocation information
is concerned rather than nothing. You also noticed that a client may only
request the certification path, without the revocation information."

Resolution:
"I still want DPD paths to be valid." [Kent, 1/23/01]

Comment:
This does not seem to imply a SHALL for inclusion of revocation information.

Ability to mandate name forms in DPD responses. [Housley, 1/24/01]
------------------------------------------------------------------
Clarification:
"One thing that I think we should add to DPD is the ability to mandate the
presence of a particular name form in the end entity certificate.  For
example, and IPsec client might want an IP address or DNS name in the
certificate.  An S/MIME client might want an RFC 822 address in the
certificate."  [Housley, 1/24/01]

Comment:
MUST name constraints in a DPD query force the presence of name constraints
in related certificates?

Resolution:
"I agree with the need for name constraints, and I have been persuaded
that associating them with trust anchors is preferable to creating cross
certs." [Kent, 1/24/01]

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 30 Jan 2001 17:14:01 -0800

Carlin, All:

RFC 2560(OCSP), the OCSPv2 I-D, and the proposed DPV and DPD extensions to
OCSP already enable recursion. That's not to say that the practice is made
explicit enough, nor do the I-Ds full (yet!) take into account issues such
as Peter Sylvester's loop detection observation, but as things stand today
we have the following to build on as we go forward.

DPV RECURSION
-------------
Recall that at the very top level, RFC 2560 defines (and the OCSPv2 I-D
maintains) OCSPResponse as:

OCSPResponse ::= SEQUENCE {
   responseStatus    OCSPResponseStatus,
   responseBytes     [0] EXPLICIT ResponseBytes OPTIONAL }

ResponseBytes ::= SEQUENCE {
   responseType      OBJECT IDENTIFIER,
   response          OCTET STRING }

So basically we have a triplet of (status, OID, data).

The DPV I-D states:

"In the responseBytes field of OCSPResponse, responseType MUST have a value
of  id-pkix-ocsp-valid-rsp and response MUST have a value of
DPVOCSPResponse, where

   DPVOCSPResponse ::= BasicOCSPResponse"

Abbreviating BasicOCSPResponse and it's subordinated elements for the
purpose of this discussion, we have:

BasicOCSPResponse
   tbsResponseData      ResponseData,

ResponseData
   responses            SEQUENCE OF SingleResponse

SingleResponse
   singleExtensions     EXPLICIT Extensions

Note that: 1) there exists no constraints on the value of the
singleExtensions field in any context; and 2) import of Extensions in the
plural from 2459 yields a SEQ OF Extension (i.e. {OID, value} pairs).

Hence a DPV response may contain one or more OCSP extensions, of which DPV
is one.

DPD RECURSION
-------------
DPD recursion is a bit easier to observe.  As with the DPV I-D, the DPD I-D
states:

"In the responseBytes field of OCSPResponse, responseType MUST have a value
of id-pkix-ocsp-path-rsp and response MUST have a value of DPDOCSPResponse.

DPDOCSPResponse ::= SEQUENCE OF PathResponse
   -- one for each certificate included in the requestList field
   -- of TBSRequest

PathResponse ::= SEQUENCE

   retryReference   BIT STRING,
   certificates     SEQUENCE OF Certificate,
   crls             SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL,
   ocspReps         SEQUENCE SIZE (1..MAX) OF OCSPResponse OPTIONAL
}

Note the recursive inclusion of OCSPResponse in PathResponse.

Note also that I failed to include OCSPResponse in the IMPORT statements of
the DPD I-D.  This oversight will be corrected in the next version.

Mike