< draft-ietf-pkix-dpv-dpd-req-03.txt   draft-ietf-pkix-dpv-dpd-req-04.txt >
Internet Draft Denis Pinkas, Bull Internet Draft Denis Pinkas, Bull
draft-ietf-pkix-dpv-dpd-req-03.txt Russ Housley, RSA Laboratories draft-ietf-pkix-dpv-dpd-req-04.txt Russ Housley, RSA Laboratories
Target Category: INFORMATIONAL April 2002 Target Category: INFORMATIONAL April 2002
Expires in six months Expires in six months
Delegated Path Validation and Delegated Path Discovery Delegated Path Validation and Delegated Path Discovery
Protocol Requirements (DPV&DPD-REQ) Protocol Requirements (DPV&DPD-REQ)
<draft-ietf-pkix-dpv-dpd-req-03.txt> <draft-ietf-pkix-dpv-dpd-req-04.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 3, line 34 skipping to change at page 3, line 34
There are several benefits to this approach; for example, a single There are several benefits to this approach; for example, a single
query to a server can replace multiple repository queries, and caching query to a server can replace multiple repository queries, and caching
by the server can reduce latency. Another benefit to the client system by the server can reduce latency. Another benefit to the client system
is that it need not incorporate a diverse set of software to interact is that it need not incorporate a diverse set of software to interact
with various forms of repositories, perhaps via different protocols, with various forms of repositories, perhaps via different protocols,
nor to perform the graph processing necessary to discover certification nor to perform the graph processing necessary to discover certification
paths, separate from making the queries to acquire path validation data. paths, separate from making the queries to acquire path validation data.
4. Delegated Path Validation Protocol Requirements 4. Delegated Path Validation Protocol Requirements
4.1. Basic protocol
The Delegated Path Validation (DPV) protocol allows a server to The Delegated Path Validation (DPV) protocol allows a server to
validate one or more public key certificates according to a validation validate one or more public key certificates according to a validation
policy. policy.
If the DPV server does not support the client requested validation If the DPV server does not support the client requested validation
policy, then the DPV server MUST return an error. policy, then the DPV server MUST return an error.
If the DPV request does not specify a validation policy, the server If the DPV request does not specify a validation policy, the server
response MUST indicate the one that was used. response MUST indicate the one that was used.
skipping to change at page 4, line 22 skipping to change at page 4, line 26
like ESSCertID as defined in [ESS] or OtherSigningCertificate as like ESSCertID as defined in [ESS] or OtherSigningCertificate as
defined in [ES-F]. defined in [ES-F].
The DPV client MUST be able to provide to the validation server, The DPV client MUST be able to provide to the validation server,
associated with each certificate to be validated, "useful associated with each certificate to be validated, "useful
certificates", as well as "useful revocation information". Revocation certificates", as well as "useful revocation information". Revocation
information includes OCSP responses, CRLs, and delta-CRLs. As an information includes OCSP responses, CRLs, and delta-CRLs. As an
example, an S/MIME message might include such information, and the example, an S/MIME message might include such information, and the
client can simply copy that information into the DPV request. client can simply copy that information into the DPV request.
The DPV server MUST have the full certificate. If not provided in the The DPV server MUST have the full certificate to be validated. When
request, the server MUST use the unambiguous reference provided in the the certificate is not provided in the request, the server MUST verify
request to obtain it. The DPV server MUST include either the full that the certificate is indeed the one being unambiguous referenced by
certificate or an unambiguous reference to the certificate (in case of the client. The DPV server MUST include either the full certificate or
a CA key compromise) in the DPV response. an unambiguous reference to the certificate (in case of a CA key
compromise) in the DPV response.
The DPV response MUST indicate one of the following two status alternatives: Unless an error is reported, the DPV response MUST indicate one of the
following two status alternatives:
1) the certificate is valid according to the validation policy. 1) the certificate is valid according to the validation policy.
2) the certificate is not valid according to the validation policy. 2) the certificate is not valid according to the validation policy.
3) the validity of the certificate is unknown according to the
validation policy.
When the certificate is not valid according to the validation policy, When the certificate is not valid according to the validation policy,
then the reason MUST also be indicated. Invalidity reasons include: then the reason MUST also be indicated. Invalidity reasons include:
a) the DPV server cannot determine the validity of the certificate a) the DPV server cannot determine the validity of the certificate
because a certification path cannot be constructed. because a certification path cannot be constructed.
b) the DPV server successfully constructed a certification path, but b) the DPV server successfully constructed a certification path, but
it was not valid according to the validation algorithm in it was not valid according to the validation algorithm in
[PKIX-1]. [PKIX-1].
c) the certificate is not yet valid at this time. If another c) the certificate is not yet valid at this time. If another
request could made later on, the certificate could possibly be request could be made later on, the certificate could possibly
determined as valid. This condition may occur before a be determined as valid. This condition may occur before a
certificate validity period has begun or while a certificate is certificate validity period has begun or while a certificate is
suspended. suspended.
In order to prevent replay attacks, the DPV client MUST be able to The protocol MUST prevent replay attacks, and the replay prevention
include a nonce in the DPV request. When the nonce is present in the mechanism employed by the protocol MUST NOT rely on clocks being
request, then the DPV server MUST include the same nonce in the synchronized with UTC.
response.
The DPV request MUST allow the client to request that the response The DPV request MUST allow the client to request the server to include
include the certification path and revocation status information used in its response additional information which will allow relying parties
by the DPV server to process the request. When requested, the DPV not trusting the requested DPV server to be confident that the
server MUST include the certification path and revocation status certificate validation has correctly been performed. Such information
information in the response when the certificate is valid according to may (not necessarily exclusively) consist of a certification path,
the validation policy. However, the server MAY omit the certification revocation status information from authorised CRL issuers or
path and revocation status information when the certificate is invalid. authorised OCSP responders, revocation status information from CRL
issuers or OCSP responders trusted under the validation policy,
time-stamp tokens from TSAs responders trusted under the validation
policy, or a DPV response from a DPV server that is trusted under the
validation policy. When the certificate is valid according to the
validation policy, the server MUST, upon request, include that
information in the response. However, the server MAY omit that
information when the certificate is invalid or when it cannot
determine the validity.
The DPV response MUST be bound to the DPV request. This can be The DPV response MUST be bound to the DPV request. This can be
accomplished by repeating the important components from the request in accomplished by repeating the important components from the request in
the response or by including a one-way hash of the request in the the response or by including a one-way hash of the request in the
response. response.
For the client to be confident that the certificate validation was For the client to be confident that the certificate validation was
handled by the expected DPV server, the DPV response MUST be handled by the expected DPV server, the DPV response MUST be
authenticated. authenticated, unless an error is reported (e.g. a badly formatted
request, etc.).
For the client to be able prove to a third party that trusts the For the client to be able prove to a third party that trusts the
same DPV server that the certificate validation was handled correctly, same DPV server that the certificate validation was handled correctly,
the DPV response MUST be digitally signed. the DPV response MUST be digitally signed, unless an error is reported
(e.g. a badly formatted request, etc.). The certificate from the DPV
server SHALL be used to identify the DPV server.
The DPV server MAY require client authentication, therefore, the DPV The DPV server MAY require client authentication, therefore, the DPV
request MUST be able to be authenticated. request MUST be able to be authenticated.
There are no specific confidentiality requirement within this
application layer protocol. However, when confidentiality is needed,
it can be achieved with a lower-layer security protocol.
4.2. Relaying, re-direction and multicasting.
In some network environments, especially ones that include firewalls,
a DPV server might not be able to obtain all of the information that
it needs to process a request. However, the DPV server might be
configured to use the services of one or more other DPV servers to
fulfill all requests. In such cases, the client is unaware that the
queried DPV server is using the services of other DPV servers. In such
environments, the client-queried DPV server acts as a DPV client to
another DPV server. Unlike the original client, the DPV server is
expected to have moderate computing and memory resources, enabling the
use of relay, re-direct or multicasting mechanisms. The requirements
in this section support such mechanisms for DPV server-to-DPV server
exchanges without imposing them on DPV client-to-DPV client exchanges.
Protocols designed to satisfy these requirements MAY include optional
fields and/or extensions to support relaying, re-direction or
multicasting. However, DPV clients are not expected to support relay,
re-direct or multicast. If the protocol supports such features, the
protocol MUST include provisions for DPV clients and DPV servers that
do not support such features, allowing them to conform to the basic
set of requirements.
1. When a server supports a relay mechanism, a mechanism to detect
loops or repetition MUST be provided.
2. When a protocol provides the capability for a DPV server to
re-direct a request to another DPV server (i.e. the protocol
chooses to provide a referral mechanism), a mechanism to provide
information to be used for the re-direction SHOULD be supported.
If such re-direction information is sent back to clients, then
the protocol MUST allow conforming clients to ignore it.
3. Optional parameters in the protocol request and/or response MAY
be provide support for relaying, re-direction or multicasting.
DPV clients that ignore any such optional parameters MUST still
be able to use the DPV service. DPV servers that ignore any such
optional parameters MUST still be able to offer the DPV service,
although they might not be able to overcome the limitations
imposed by the network topology. In this way, protocol
implementors need not understand the syntax or semantics of any
such optional parameters.
5. Delegated Path Discovery Protocol Requirements 5. Delegated Path Discovery Protocol Requirements
The Delegated Path Discovery (DPD) protocol allows the client to use The Delegated Path Discovery (DPD) protocol allows the client to use
a single request to collect at one time from a single server the data a single request to collect at one time from a single server the data
elements available at the current time that might be collected using elements available at the current time that might be collected using
different protocols (e.g. LDAP, HTTP, FTP, OCSP) or by querying different protocols (e.g. LDAP, HTTP, FTP, OCSP) or by querying
multiple servers, to locally validate a public key certificate multiple servers, to locally validate a public key certificate
according to a single path discovery policy. The returned information according to a single path discovery policy. The returned information
can be used to locally validate one or more certificates for the can be used to locally validate one or more certificates for the
current time. current time.
Clients MUST be able to specify whether they want, in addition to the Clients MUST be able to specify whether they want, in addition to the
certification path, the revocation information associated with the certification path, the revocation information associated with the
path, for the end-entity certificate, for the CA certificates, path, for the end-entity certificate, for the CA certificates, or for
or for both. both.
If the DPD server does not support the client requested path If the DPD server does not support the client requested path
discovery policy, the DPD server MUST return an error. Some forms discovery policy, the DPD server MUST return an error. Some forms
of path discovery policy can be simple. In that case it is acceptable of path discovery policy can be simple. In that case it is acceptable
to pass the parameters from the path discovery policy with each to pass the parameters from the path discovery policy with each
individual request. For example, the client might provide a set of individual request. For example, the client might provide a set of
trust anchors and separate revocation status conditions for the trust anchors and separate revocation status conditions for the
end-entity certificate and for the other certificates. The DPD request end-entity certificate and for the other certificates. The DPD request
MUST allow more elaborated path discovery policies to be referenced. MUST allow more elaborated path discovery policies to be referenced.
It is expected that most of the time clients will only be aware of It is expected that most of the time clients will only be aware of
the referenced path discovery policy for a given application. the referenced path discovery policy for a given application.
The DPD server response includes zero, one, or several certification The DPD server response includes zero, one, or several certification
paths. Each path consists of a sequence of certificates, starting with paths. Each path consists of a sequence of certificates, starting with
the certificate to be validated and ending with one issued by a trust the certificate to be validated and ending with a trust anchor. If the
anchor. The trust anchor self-signed certificate, if issued, is not trust anchor is a self-signed certificate, that self-signed certificate
included. In addition, if requested, the revocation information is not included. In addition, if requested, the revocation information
associated with each certificate in the path MUST also be returned. associated with each certificate in the path MUST also be returned.
The DPD client needs to be able to limit the number of paths returned. The DPD client needs to be able to limit the number of paths returned.
Therefore the client MUST be able to indicate the maximum number of Therefore the client MUST be able to indicate the maximum number of
certification paths to be returned (provided that they can be certification paths to be returned (provided that they can be found).
found). If the client does not specify a maximum number, then If the client does not specify a maximum number, then the DPD server
the DPD server MUST return a single certification path. MUST return a single certification path.
The paths that are returned may need to match some additional local The paths that are returned may need to match some additional local
criteria known only to the client. For example, the client criteria known only to the client. For example, the client might
might require the presence of a particular certificate require the presence of a particular certificate extension.
extension.
If that number cannot be reached by the server, an indication SHOULD If that number cannot be reached by the server, an indication SHOULD
be returned by the DPD server showing that an additional query will not be returned by the DPD server showing that an additional query will not
return more paths. return more paths.
If the paths that are returned do not match the clientĘs local If the paths that are returned do not match the clientĘs local
criteria, then the number of number of certification paths to be criteria, then the number of number of certification paths to be
returned can be extended by increasing this value. Previously found returned can be extended by increasing this value. Previously found
paths will likely be returned, but the client can easily discard them. paths will likely be returned, but the client can easily discard them.
This avoids requirements for state information at the server, but does This avoids requirements for state information at the server, but does
skipping to change at page 7, line 8 skipping to change at page 8, line 19
paths and, if requested, its associated revocation status information paths and, if requested, its associated revocation status information
for each element from the path. for each element from the path.
For the client to be confident that the response originates from the For the client to be confident that the response originates from the
expected DPD server, the server MAY provide an authenticated response. expected DPD server, the server MAY provide an authenticated response.
For example, the server might sign the response. For example, the server might sign the response.
The DPD server MAY require client authentication, therefore, the DPD The DPD server MAY require client authentication, therefore, the DPD
request MUST be able to be authenticated. request MUST be able to be authenticated.
There are no specific confidentiality requirement within the
application layer protocol. However, when confidentiality is needed,
it can be achieved with a lower-layer security protocol.
6. Requirements common both to DPV and DPD 6. Requirements common both to DPV and DPD
The client MUST be able to obtain references for the default policy The client MUST be able to obtain references for the default policy
or for all of the policies supported by the server by using an or for all of the policies supported by the server by using an
additional request/response pair. The response can include references additional request/response pair. The response can include references
to previously defined policies or to a priori known policies. to previously defined policies or to a priori known policies.
7. Validation Policy 7. Validation Policy
A validation policy is a set of rules against which the validation of A validation policy is a set of rules against which the validation of
the certificate is performed. the certificate is performed.
A validation policy MAY include several trust anchors. A trust anchor A validation policy MAY include several trust anchors. A trust anchor
is defined as one public key, a CA name, and a validity time interval; is defined as one public key, a CA name, and a validity time interval;
a trust anchor optionally includes additional constrains. The use of a a trust anchor optionally includes additional constraints. The use of a
self-signed certificate is one way to specify the public key to be self-signed certificate is one way to specify the public key to be
used, the CA name, and the validity period of the public key. used, the CA name, and the validity period of the public key.
Additional constrains for each trust anchor MAY be defined. These Additional constraints for each trust anchor MAY be defined. These
constraints might include a set of certification policy constraints or constraints might include a set of certification policy constraints or
a set of naming constraints. These constrains MAY also be included in a set of naming constraints. These constraints MAY also be included in
self-signed certificates. self-signed certificates.
Additional conditions that apply to the certificates in the path MAY Additional conditions that apply to the certificates in the path MAY
also be specified in the validation policy. For example, specific also be specified in the validation policy. For example, specific
values could be provided for the inputs to the certification path values could be provided for the inputs to the certification path
validation algorithm in [PKIX-1], such as user-initial-policy-set, validation algorithm in [PKIX-1], such as user-initial-policy-set,
initial-policy-mapping-inhibit, initial-explicit-policy, or initial-policy-mapping-inhibit, initial-explicit-policy, or
initial-any-policy-inhibit. initial-any-policy-inhibit.
Additional conditions that apply to the end-entity certificate MAY Additional conditions that apply to the end-entity certificate MAY
skipping to change at page 7, line 51 skipping to change at page 9, line 12
alternative name or in the emailAddress naming attribute in the alternative name or in the emailAddress naming attribute in the
subject name, might be required. subject name, might be required.
In order to succeed, one valid certification path (none of the In order to succeed, one valid certification path (none of the
certificates in the path are expired or revoked) MUST be found between certificates in the path are expired or revoked) MUST be found between
an end-entity certificate and a trust anchor and all constraints that an end-entity certificate and a trust anchor and all constraints that
apply to the certification path MUST be verified. apply to the certification path MUST be verified.
7.1. Components for a validation policy 7.1. Components for a validation policy
A validation policy is build from three components: A validation policy is built from three components:
1. Certification path requirements, 1. Certification path requirements,
2. Revocation requirements, 2. Revocation requirements,
3. End-entity certificate specific requirements. 3. End-entity certificate specific requirements.
Note: [ES-P] defines ASN.1 data elements that may be useful while Note: [ES-P] defines ASN.1 data elements that may be useful while
defining the components of a validation policy. defining the components of a validation policy.
7.2. Certificate path requirements 7.2. Certificate path requirements
skipping to change at page 9, line 34 skipping to change at page 10, line 49
When no policy reference is present in the DPV request, the DPV client When no policy reference is present in the DPV request, the DPV client
should verify that the policy selected by the DPV server is appropriate. should verify that the policy selected by the DPV server is appropriate.
The revocation status information is obtained for the validation time. The revocation status information is obtained for the validation time.
In case of a digital signature, it is not necessarily identical to the In case of a digital signature, it is not necessarily identical to the
time when the private key was used. The validation time should be time when the private key was used. The validation time should be
adjusted by the DPV client to compensate for: adjusted by the DPV client to compensate for:
1) time for the end-entity to realize that its private key has 1) time for the end-entity to realize that its private key has
been or could possibly be compromised, been or could possibly be compromised, and/or
2) time for the end-entity to report the key compromise, 2) time for the end-entity to report the key compromise, and/or
3) time for the revocation authority to process the revocation 3) time for the revocation authority to process the revocation
request from the end-entity, or request from the end-entity, and/or
4) time for the revocation authority to update and distribute the 4) time for the revocation authority to update and distribute the
revocation status information. revocation status information.
10. Acknowledgments 10. Acknowledgments
These requirements have been refined after some valuable inputs from These requirements have been refined after some valuable inputs from
Ambarish Malpani, Tim Polk, and Paul Hoffman. Ambarish Malpani, Tim Polk, and Paul Hoffman.
11. References 11. References
 End of changes. 26 change blocks. 
41 lines changed or deleted 110 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/