[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DPV vs SCVP
Mike,
A few, but important comments on this E-mail sent last week.
> 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".
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.
>
> 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.
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
> ------------------------------------------------
> 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 }
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 }
> 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.
I have sent yesterday a message to Ambarish on that topic. I am awaiting for
his response.
Regards,
Denis
> Best regards to all,
>
> Mike