Subject: RE: OCSPv2 and OCSP extensions drafts

From: Michael Myers <[email-masked]>
Date: Tue, 19 Sep 2000 09:58:37 -0700

Peter,

Maybe I'm the only one who thinks this way, but I view DVCS as more related
to the validation of signatures on documents and consequently a higher-order
(i.e. more application-level) protocol than OCSP.  Validation of those
signatures inherently involves validation of the relevant certificate(s).
This could be facilitated in part by reference to CRLs or an online
mechanism (i.e. OCSP).

The draft that expired was the original "OCSP-X" draft. The DPV and DPD
drafts draw from and build on that.

Mike

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Tuesday, September 19, 2000 4:59 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: OCSPv2 and OCSP extensions drafts
> 
> 
> > 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)?
> The name of the last is DVCS. :-)
> 
> > 
> > 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).
> 
> 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: Matjaz Ostroversnik <[email-masked]>
Date: Wed, 20 Sep 2000 07:55:59 +0200

Could someone get me off the list please.