draft-ietf-pkix-ocsp-dpvdpd-00.txt

来自「PKIX的RFC英文文档」· 文本 代码 · 共 418 行 · 第 1/2 页

The CertStatus field of BasicOCSPResponse SHALL be interpreted as follows when 
the value of responseType is id-pkix-ocsp-valid.

DPVCertStatus ::= CHOICE {
    valid       [0]     IMPLICIT NULL,
    invalid     [1]     IMPLICIT OCTET STRING Reasons,
    unknown     [2]     IMPLICIT NULL }

The valid state SHALL be interpreted as indicating that the certificate at a 
minimum satisfies the path validation rules defined in [RFC3280].  Responders 
MAY further predicate production of a valid response on additional criteria.



Myers                                                                   [Page 4]
Internet Draft                 DPV&DPD Over OCSP                    January 2003

The invalid state SHALL be interpreted as indicating that the certificate does 
not satisfy one or more conditions necessary to the production of a valid state.  
Responders MAY indicate in Reasons the relevant condition(s).

The unknown state SHALL be interpreted as indicating that the responder has in-
sufficient knowledge of the certificate's status.

5.2.2	Use of Extended OCSP Response

If a request does not indicate a validation policy, responders SHALL include Ex-
tendedOCSPResponse in BasicOCSPResponse and SHALL identify in the policy field 
of ExtendedOCSPResponse syntax the OID identifying the policy in effect when the 
response was produced.  In the event that the organization operating the re-
sponder has not acquired an OID for this purpose a NULL value SHALL  be used.

If Flags is present in RequestOptions, responders SHALL produce ExtendedOCSPRe-
sponse as follows:

a. if the returnPath bit is set, responders SHALL return in the path field all 
   certificates used to validate the subject certificate;

b. if the returnEERevInfo bit is set, responders SHALL return those data used 
   to establish the subject certificate's validity in the revInfo field;

c. if the returnTSP bit is set, responders SHALL return a time stamp in the 
   timeStamp field.

d. if the returnPolicy bit is set, responders SHALL return in the policy field 
   the OID identifying the policy in effect when the response was produced.

e. if the returnReq bit is set, responders SHALL return in reqContents field
   the contents of the received DPVOptions in order to present to another 
   relying party the important components of the request.

Responders SHALL otherwise include ExtendedOCSPResponse as follows:

If a value for token is present in the params field of DPVOptions, responders 
SHALL copy the token value into the token field of the ExtendedOCSPResponse.

If a value for requestExtensions is present in the DPV request (thus indicating 
the presence of requestor-specified parameters), responders shall perform a hash 
across this value using the SHA-1 algorithm and include this resulting value in 
the paramHash field.

If requestorName is included the TBSRequest element of OCSPRequest (see 
[RFC2560]), responders SHALL include this value in the reqID field of Extende-
dOCSPResponse.  Where client authentication is important to the responder's pol-
icy (e.g. authorization to access the service), a lower-layer protocol may be 
used to establish this authentication.  If used, responders SHOULD copy the cli-
ent-auth identity into the reqID field of ExtendedOCSPResponse.


Myers                                                                   [Page 5]
Internet Draft                 DPV&DPD Over OCSP                    January 2003

6.	Delegated Path Discovery (DPD)

[RFC3280] requires certificate-processing systems to accumulate the set of cer-
tificates from which certificate chains may be constructed as well as revocation 
data for each such certificate.  These data may originate from diverse sources 
using diverse technologies. Delegating this aggregation simplifies relying party 
certificate validation.  This section defines means by which OCSP can be used to 
integrate PKI information acquisition across these diverse technology platforms.

6.1	DPD Request

A DPD request SHALL be identified by the id-pkix-ocsp-path-req OID in the re-
questExtensions field of TBSRequest.

id-pkix-ocsp-path-req   OBJECT IDENTIFIER ::= { id-pkix-ocsp X }

A NULL value SHALL be included as the value of the extension in the event no 
other parameters are to be included in the request.  Otherwise, requestors SHALL 
use the ExtendedOCSPRequest syntax to specify such parameters.

It may be useful for requestors to acquire a given path from among several.  In 
this case requestors SHALL indicate in the numPaths field of ExtendedOCSPRequest 
the maximum number of paths to be included in the response.  Requestors then ap-
ply local path selection logic to determine if the intended path is among that 
set.  In the event a target path is not delivered, requestors can increase the 
value of numPaths and try again.  Requestors should note that two successive re-
sponses bearing the same number of paths indicates that the responder has no 
more candidate paths.

6.2	DPD Response

A DPD response SHALL be identified by the id-pkix-ocsp-path-rsp OID in the Re-
sponseType field of the ResponseBytes syntax.

An authoritative DPD response (that is, no errors) SHALL consist of ExtendedOC-
SPResponse which SHALL, at a minimum, contain a value for the pathInfo field 
UNLESS no paths are available in which case an error SHALL be returned. Respond-
ers SHALL present ExtendedOCSPResponse as the value of response in the response-
Bytes syntax of ResponseBytes (see [RFC2560]).

Responders SHALL develop a path or paths correspondent to a requestor-specified 
path discovery policy when such is indicated in the request.  If a request does 
not indicate a path discovery policy, responders SHALL include ExtendedOCSPRe-
sponse in BasicOCSPResponse and SHALL identify in the policy field of Extende-
dOCSPResponse syntax the OID identifying the policy in effect when the response 
was produced.  In the event that the organization operating the responder has 
not acquired an OID for this purpose a NULL value SHALL be used.

Responders aware of multiple candidate paths that satisfy requestor-specified 
parameters SHALL respond with the lesser of the number of qualified paths or the 
number of paths specified by the requestor in numPaths.



Myers                                                                   [Page 6]
Internet Draft                 DPV&DPD Over OCSP                    January 2003

If the requestor did not specify numPaths then, by default, the responder MUST 
return a single certification path for each end-entity certificate in the DPD 
request.

The returned path (or paths), if any, SHALL be in serial order from end-entity 
certificate up to and including the trust anchor UNLESS the trust anchor is a 
self-signed certificate in which case that certificate SHALL NOT be included in 
the path.  If no paths are discoverable, this state SHALL be indicated by a NULL 
value for the pathInfo field of ExtendedOCSPResponse.

If Flags is present in ExtendedOCSPRequest, responders SHALL further produce Ex-
tendedOCSPResponse as follows:

a. setting returnPath is redundant for a DPD request;

b. if the returnEERevInfo bit is set, responders SHALL return those data used 
   to establish the subject certificate's validity in the revInfo field of 
   ExtendedOCSPResponse.

c. if the returnCARevInfo bit is set, responders SHALL return those data used 
   to establish the validity of the path in the revInfo field of 
   ExtendedOCSPResponse.

d. revocation information MAY be either CRLs, OCSP responses or both according 
   to the settings of the returnCRL and returnOCSP bits.  If neither of these 
   bits is set when either returnEERevInfo or returnCARevInfo is set, responders
   SHALL include CRLs and MAY include OCSP responses.

If requestorName is included the TBSRequest element of OCSPRequest (see 
[RFC2560]), responders SHALL include this value in the reqID field of Extende-
dOCSPResponse.  Where client authentication is important to the responder's pol-
icy (e.g. authorization to access the service), a lower-layer protocol may be 
used to establish this authentication.  If used, responders SHOULD copy the cli-
ent-auth identity into the reqID field of ExtendedOCSPResponse.

6.3	Determination of Response States

[RFC3379] defines five closely related DPD response states that requestors must 
be able to discern from a DPD response.  In abbreviated form, these are:

1. one or more policy-compliant paths, all  requested revInfo present;

2. one or more policy-compliant paths, some requested revInfo present;

3. one or more policy-compliant paths, no   requested revInfo present;

4. no policy-compliant paths were discovered; and

5. an error occurred in path construction.

Requestors can derive these states from a DPD response as follows.  


Myers                                                                   [Page 7]
Internet Draft                 DPV&DPD Over OCSP                    January 2003

Errors are reported as OCSPResponseStatus (see [RFC2560]) in which case no path 
data is present in the response.  A value of successful in OCSPResponseStatus 
indicates the presence of pathInfo in ExtendedOCSPResponse.  This value may be 
NULL, indicating that no paths were discovered.  Requestors that did not request 
revInfo will not receive revInfo.  Else each certificate in each path returned 
via the pathInfo structure may or may not have revInfo associated with it.  Ab-
sence of revInfo for a given certificate in the pathInfo structure enables re-
questor determination of the first three states noted above.

7.	Security Considerations

This protocol enables the projection of trust across diverse domains.  It can 
only be as reliable as the key management foundation upon which it is deployed.  
Implementers and integrators are strongly encouraged to consider the principles 
of sound key management prior to deploying this protocol.

8.	References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C.,
             "Online Certificate Status Protocol -