[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Integration of OCPv2 , DPV & DPD
- To: <ietf-pkix@xxxxxxx>
- Subject: Integration of OCPv2 , DPV & DPD
- From: "Michael Myers" <myers@xxxxxxxxxxxxx>
- Date: Fri, 2 Mar 2001 16:43:20 -0800
- Importance: Normal
- In-reply-to: <>
All,
I've submitted a new OCSPv2 draft (-02) based on the WG's efforts in San
Diego. This version incorporates the technical content of the OCSP-based
DPD and DPV I-Ds; those I-Ds will be allowed to expire in favor of this
unified specification. Many thanks to all for your support in refining
those concepts. A draft document defining the OCSP state machine was also
submitted. If you wish to receive a copy of either prior to their eventual
appearance on the official IETF web site, please contact me offlist at
myers@xxxxxxxxxxxxxx
Otherwise, here's a precis:
Pulled in core of the OCSP-based DPV and DPD I-Ds and moved around some
elements of the -01 text to more accurately reflect the
framework+service_type approach the prior three I-Ds and RFC2560 had already
defined. I made what I hope are useful editorial (i.e. non-normative)
corrections along the way. I also worked in the minor editorial corrections
we've made to RFC 2560 as it progresses along the standards track.
Accordingly, the Protocol Overview section is totally rewritten. The only
potential surprise in this section is the abstract definition of Online
Revocation Status (ORS) service as a peer service to DPV and DPD. ORS
service is simply what's currently in RFC 2560. So basically we have ORS,
DPV and DPD as standardized OCSP services and a handful of potentially
useful but ancillary extensions (e.g. Archive Cutoff).
The technical definition of the DPV and DPD services were substantially
augmented to conform to the Dec 29 draft requirements definition as well as
the input received from the ad-hoc OCSPv2 working sessions conducted in San
Diego. I wasn't able to work in all perspectives (some were mutually
exclusive of others) but at present the following is proposed in response to
those inputs:
DPVOptions :: = SEQUENCE{
pathParams PathParameters OPTIONAL,
validAt [2] GeneralizedTime OPTIONAL,
revInfo [3] SEQUENCE OF RevocationInfo OPTIONAL,
dPVFLags [4] DPVFlags OPTIONAL }
PathParameters ::= SEQUENCE {
initialPolicySet [0] PolicyList OPTIONAL,
trustPoints [1] SEQUENCE OF ReqCert OPTIONAL }
DPVFlags ::= BIT STRING {
returnpath (0),
returnrevinfo (1),
returntsp (2),
returnpolicy (3) }
RevocationInfo ::= CHOICE {
cRL CertificateList,
oCSP OCSPResponse }
DPDOptions :: = SEQUENCE{
retryReference OCTET STRING,
initialPolicySet [0] EXPLICIT PolicyList OPTIONAL,
trustPoints [1] SEQUENCE OF ReqCert OPTIONAL,
validAt [2] GeneralizedTime OPTIONAL,
dDPFlags [3] DPDFlags OPTIONAL}
DPDFlags ::= BIT STRING {
returnTSP (0),
returnpolicy (1),
crlonly (2),
ocsponly (3),
either (4) }
SUBSTANTIAL context and additional technical content omitted for the sake of
brevity. See the I-D for full details. Specification subject to change.
Fasten seatbelts prior to takeoff.
Mike