Re: OCSP I-Ds going forward

["Tom Gindin" <tgindin@xxxxxxxxxx>]

      Mike:

      If the purpose of CertIdWithSignature is to extend IssuerSerial in a
way which is both unambiguous and compact, why are both the signatureValue
field and tbsCertificateHash present?  Either the signatureValue field or
the signatureAlgorithm/tbsCertificateHash combination should be unique.
IMHO there isn't much point in doing a signature validation based on an
asserted hash without access to the base certificate.

            Tom Gindin

"Michael Myers" <myers@xxxxxxxxxxxxx>@mail.imc.org on 11/25/2002 01:51:41
PM

Sent by:    owner-ietf-pkix@xxxxxxxxxxxx


To:    <ietf-pkix@xxxxxxx>
cc:
Subject:    OCSP I-Ds going forward



FYI all,

As many of you know, in March 2001 Carlisle, Stephen and I
proposed two OCSP-based services.  We called them Delegated Path
Validation (DPV) and Delegated Path Discovery (DPD).  That I-D
was allowed to lapse pending WG resolution of the DPV/DPD
requirements.  In Atlanta, I committed to the chairs to refresh
that I-D.

However, that I-D also addressed the separable need to expand
the certificate identification mechanisms.  This changed changed
core syntax, hence a v2 version number (i.e. OCSPv2).  To
complicate matters further, given that the original OCSPv2 I-D
was allowed to lapse, the certID/v2 issue has recently been
refreshed with yet another OCSP-based I-D that once more speaks
to v2-ness but also introduced yet another proposed
extension--the CRL Locator.

So to simplify matters for all of those in the WG that continue
to have the patience to review and comment on these things, two
new, unifying I-Ds are being produced and will be available
shortly.  This work will enable parallel and non-conflicting
consideration of the cert identification and DPV/DPD issues.

The first working document will be the "core".  It's primary
purpose is to enable consideration of alternative certificate
identification mechanisms.  It will propose a ReqCert syntax
that provides a CHOICE of: legacy-interoperable support for
2560's certID; full certificate (including ACs); the
CertIdWithSignature syntax as recently proposed; and
issuerAndSerialNumber as recently advocated by Peter Gutman.

The second working document will be a "Services and Extensions"
document.  It will include: the basic service of revocation
checking; all extensions as currently documented in 2560; the
new proposed CRL Locator extension; and the definition of DPV
and DPD services as originally proposed.  Thus, for OCSPv2, the
upcoming DPV/DPD question reduces to whether or not to retain
that related text in the S&E working document.

Following resolution of the DPV/DPD issue, both these working
documents will be reintegrated into a final I-D for WG last call
on what we want to call OCSPv2.

Mike