Subject: RE: DPV vs SCVP

From: Michael Myers <[email-masked]>
Date: Fri, 10 Nov 2000 12:55:04 -0800

Russ, thanks for getting this debate kicked off.  After all the work various
of us have put into this issue, I was beginning to think no one cared.

All, as to the debate:

Let's hear from everybody before we make a decision.
----------------------------------------------------
Thanks to all who have read the IDs and provided comments (especially Denis
Pinkas).  But since active WG members have taken time out of their busy
schedules to improve the IDs, I think it only fair that final judgement be
witheld until those contributions are folded into a revised version for our
consideration in San Diego.  At that time it might be more appropriate to
decide between the two.

It's DPV vs. SCVP
-----------------
OCSP-X has expired; DPV and DPD replace that initial work.  The requirement
we're all most concerned about is delegated path validation (although
delegated path discovery has it's use). So it really comes down to DPV+DPD
vs. SCVP since OCSP is already RFC 2560.  DPV is little more than an OID and
a corresponding semantic; it simply puts more meat behind 2560's notion of
"good".  DPD is only a bit more along these same lines of design.

They're going to do it anyway.
------------------------------
DPV and DPD are nothing more than proposed standard extensions to the
already existing extension hooks in 2560.  Given the availablility of those
hooks, there's nothing to stop any environment from doing precisely this, if
only to establish a closed system-level solution.  Given that, it's better
that we take responsible action to promote Internet interoperability via a
standard means of doing so in the event that such closed environments may
someday find it useful to interoperate.

OCSPv2 is separable to the DPV vs. SCVP question
------------------------------------------------
Carlisle, Rich Ankney and I separately proposed OCSPv2.  At its core, this
is simply an expansion of certificate identification syntax to accomodate
well-known use cases of the existing RFC 2560. It's really nothing more
than:

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

where in 2560 we simply have:

CertID    ::=     SEQUENCE {
     hashAlgorithm       AlgorithmIdentifier,
     issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
     issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
     serialNumber        CertificateSerialNumber }

There's also a version number delta and corresponding guidance when to use a
given version number.

The lack of these alternatives is a long-standing criticism of 2560 and will
be fixed regardless of the outcome of the DPV vs. SCVP debate.  Again, many
thanks to Denis Pinkas for his detailed, thoughtful and constructive
commentary on the OCSPv2 ID.  I'll be bringing this up in a totally separate
thread from the DPV vs. SCVP discussion to resolve the MUSTs related to
supporting these various identification schemes.

XML is a whole new ballgame
---------------------------
It's true that the OCSPv2, DPV and DPD IDs don't address XML.  There are two
reasons for this.  First, there can be no doubt that XML can be an useful
PKI delivery platform.  Khaja Ahmed's recent analysis said it well.  But
there's probably going to be many competeting proposals addressing this
need.  Secondly, considering XML only in the context of delegated path
validation ignores the full set of certificate lifecycle needs (e.g.
enrollment, renewal and revocation) that must be met to fully deliver on the
XML+PKI "vision".

In sum, it's quite possible that XML-based status needs are better met by a
tighter integration with business practices than is currently enabled by
ASN.1 based solutions.  We can however predict with a reliable degree of
accuracy how an ASN.1-based solution integrates at least to existing
PKI-related protocols.  Hence the DPV/DPD proposals chose to define a very
simple means by which a solution to these pressing certificate status needs
can be met with maximal reuse of existing ASN.1 investments, leaving the way
clear for XML+PKI to take its own course.

Best regards to all,

Mike

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 15 Nov 2000 13:47:29 +0100

Mike,

A few, but important comments on this E-mail sent last week.

> "good". 

I disagree with this last statement. Extensions allows to request new
services. The request for each every new service may fail or succeed. This
means that each extension will have to carry the result of the request for
the new service. This also means that the current status will only carry the
response to a *status revocation request*, but will not carry any additional
meaning. "Good" is not the appropriate term to be used: "not revoked" is the
right term and should be used instead, when we revised OCSP.

>  DPD is only a bit more along these same lines of design.
> 

The real advantage to add DPV and DPD to OCSP is to be able to support both
a revocation status request and DPV or DPV+DPD in a single request. It
should however be noticed that a response to a status revocation request is
not mandatory since the server may well return a "revocation status unknown"
response, but still respond to a DPD (Delegated Path Discovery) for the
certificate. 

> OCSPv2 is separable to the DPV vs. SCVP question

I am not convinced it is the right way to do, because we loose backward
compatibily with OCSP v1. I have sent privately a proposal to you and the
co-editors where compatibility can be preserved, and where more syntax
options can be supported without using ReqCert. Here it is:

   Request         ::=     SEQUENCE {
       reqCert                         CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber,
       certHash            OCTET STRING     OPTIONAL,
       pKCert              Certificate      OPTIONAL }

> XML is a whole new ballgame

I have sent yesterday a message to Ambarish on that topic. I am awaiting for
his response.

Regards,

Denis