RE: DPV vs SCVP

[Michael Myers <MMyers@xxxxxxxxxxxx>]

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