Subject: OCSPv2 and OCSP extensions drafts

From: Michael Myers <[email-masked]>
Date: Fri, 15 Sep 2000 18:06:02 -0700

All,

Ealier today I sent to IETF three OCSP-related drafts as followup to our
Pittsburg meeting, developed in collaboration with Carlisle Adams and
Stephen Farrell.  I trust these drafts will soon be available for your
consideration.  If you wish a more immediate copy, please let me know
directly.

Two of these drafts propose Internet standard extensions to OCSP.  These are
Delegated Path Validation (DPV) and Delegated Path Discovery (DPD).  The DPV
extension enables offloading of certificate path processing to an OCSP
server while the DPD extension enables acquisition of the PKI data an OCSP
server would otherwise use in meeting the DPV requirements.

The third draft is OCSPv2.  This is the "2560bis" work I referred to
earlier.  It proposes to extend the existing certID structure to more fully
enable the use of OCSP in wireless and other contexts.  The v2 proposal
interoperably subsumes RFC 2560.  There is no technical linkage between the
v2 proposal and the DPV and DPD drafts.  The latter two are specifically
defined to enable their application to existing OCSP implementations.

Mike

---

From: Russ Housley <[email-masked]>
Date: Mon, 18 Sep 2000 11:33:59 -0400

Mike:

This raises a bigger question.  I do not think that PKIX should have more 
than one way to do remove cert path validation.  There seems to be three 
approaches on the table.  Which protocol is the right one (OCSP, SCVP, or DCS)?

Personally, I would rather not spend a lot of time reviewing three 
different approaches.  Rather, I would like to determine the way we are 
going, then review the one.  Maybe each of the proponents could summarize 
how their protocol stacks up against the requirements.  (It might be my 
memory, but I thought we had a requirements discussion on the list.  It is 
not in an Internet-Draft).

Russ

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 19 Sep 2000 13:59:09 +0200 (MET DST)

> approaches on the table.  Which protocol is the right one (OCSP, SCVP, or DCS)?
The name of the last is DVCS. :-)

> not in an Internet-Draft).

I read the OCSP draft-ietf-pkix-ocsp-valid-00.txt and would like to
compare this with what is the corresponding part in DVCS. 

Unless I have misunderstood something, besides the different encoding
of requests and responses, the essential data elements to be compared in a
draft-ietf-pkix-ocsp-valid-00.txt requests and responses are: 

ReqCert  ::= CHOICE {
     certID            CertID,
     issuerSerial      [0] IssuerandSerialNumber,
     pKCert            [1] Certificate,
     name              [2] GeneralName }

and 

DPVOptions  :: = SEQUENCE{
    initialPolicySet [0] EXPLICIT PolicyList OPTIONAL, 
    trustPoints       SEQUENCE OF ReqCert OPTIONAL } 

The corresponding data structures in DVCS    

   TargetEtcChain ::= SEQUENCE {
        target                       CertEtcToken,
        chain                        SEQUENCE SIZE (1..MAX) OF
                                        CertEtcToken OPTIONAL,
        pathProcInput                [0] PathProcInput OPTIONAL
   }

   PathProcInput ::= SEQUENCE {
        acceptablePolicySet          SEQUENCE SIZE (1..MAX) OF
                                        PolicyInformation,
        inhibitPolicyMapping         BOOLEAN DEFAULT FALSE,
        explicitPolicyReqd           BOOLEAN DEFAULT FALSE
   }

   CertEtcToken ::= CHOICE {
        certificate                  [0] IMPLICIT Certificate ,
        esscertid                    [1] ESSCertId ,
        pkistatus                    [2] IMPLICIT PKIStatusInfo ,
        assertion                    [3] ContentInfo ,
        crl                          [4] IMPLICIT CertificateList,
        ocspcertstatus               [5] IMPLICIT CertStatus,
        oscpcertid                   [6] IMPLICIT CertId ,
        oscpresponse                 [7] IMPLICIT OCSPResponse,
        capabilities                 [8] SMIMECapabilities,
        extension                    Extension
   }

The difference in dvcs is that it allows inhibitPolicyMapping, explicitPolicyReqd
That doesn't seem a very big deal, in the ocsp draft this can be easily added
(if considered useful).  

The definition of TargetEtcChain.chain part in DVCS unfortunately says:

     Each certificate to be verified MUST be included in a separate
     instance of TargetEtcChain, and to be verified.  The
     'TargetEtcChain.chain' field, if present, MUST indicate the chain
     of trust to be used when certifying the certificate. 

There are several possibilities: 
One is making several TargetEtcChain, and getting status for ALL the possible trust points.
Another is to modify the text above to give more freedom to the server,
actually the same semantics as in the ocsp extension draft..  

So: 

There is a lot of overlap among the protocols, they can also be regarded
as complementary. 

DVCS allows to return not only a validated path but also all validation information
that come with it, saying basically: 'I think the cert status is X and I have based
my information on that and that information.'  For example there could be an
imbedded ocsp reponse for an intermediate CA.

Peter Sylvester

Is it correct that the other ocsp draft (path) is *already* expired?

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 22 Sep 2000 15:07:33 +0200 (MET DST)

> 
> > Where and how is the state maintained?
> 
> The implementation of the server isn't part of the spec.
True. I stumbled over the word 'state', you examples are clear, it
seems we agree that there is  small need for some clarifications/
explications in the text.  
 
> 
> > One possibility is the cookie that was returned, and not in the server.
> > and a client just may accept the first proposal, and has no way to
> > indicate to the server that the association is terminated.
> 
> I don't follow that sentence (or two sentences, whatever:-). The 
> example above should clarify that the client never needs to close 
> a stateful connection or anything like it.

I used cookie as an alias for retryReference. 

The retryReference could be something that allows a server to start
the next "search" behind. As a simple analogy: Reading a directory
and asking "give me the next entry after the this one". 

The retry reference could for example be some encoding of the result, 
assuming that it can be used in order to determine 'what is the next'.

> > In order to maintain a state on a server, one could also use something
> > like the keep-alive technique of http, or what had been discovered
> > in the direct socket based protocol of cmp.
> 
> That's not needed here. If the server no longer has the retryReference
> it returns an error and the client can process the error.
> I could buy that we'd want a specific error, (say referenceNotFound
> or something), but internalError or tryLater should be ok in this case.
> You're probably right that we should specify which error to send in 
> this case (I'd pick internalError).

Right, in fact, using an open 'connection' with the server wouldn't
probably work, for example when the client interacts with the end user
in order to decide whether to proceed.

tryLater is independant of a reference, it can happen, 
when you have lost connectivity to a directory for example. 

Internalerror sounds sufficient. one might try to explain what
a client can try to do after getting such an error, 
may be not now, this may need some implementation experience.