Internet Draft Denis Pinkas, Integris
draft-ietf-pkix-dpv&dpd-req-01.txt Russ Housley, RSA Laboratories
Target Category: INFORMATIONAL January 2002
Expires in six months
Delegated Path Validation and Delegated Path Discovery
Protocol Requirements (DPV&DPD-REQ)
<draft-ietf-pkix-dpv-dpd-req-01.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies requirements for two main request/response
pairs.
The first one, called Delegated Path Validation (DPV), can be used to
fully delegate a path validation processing to an DPV server,
according to a set of rules, called a validation policy.
The second one, called Delegated Path Discovery (DPD), can be used to
obtain from a DPD server all the information needed (e.g., the end-
entity certificate, the CA certificates, full CRLs, delta-CRLs, OCSP
responses) to locally validate a certificate. The DPD server uses a
set of rules, called a path discovery policy, to determine which
information to return.
A third request/response pair can be used to allow clients to obtain
the references for the policies supported by a server.
This document also defines the requirements for two optional
request/response pairs. The first one is used to establish a
validation policy with a DPV server. The second one is used to
establish a discovery policy with a DPD server. Either
request/response pair provide a reference of an existing policy to
obtain policy details.
Pinkas [Page 1]
Internet Draft DPV&DPD-REQ January 2002
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document (in uppercase, as shown) are to be interpreted as
described in [RFC2119].
1. Rationale and benefits
These delegated processing provides two primary services: delegated
path validation and delegated path discovery. Some clients require
a server to perform path validation and have no need for data
acquisition, while some other clients require only delegated path
discovery in support of local path validation.
2. Rationale and benefits for DPV (Delegated Path Validation)
DPV allows a server to perform a real time certificate validation for
a time T, where T may be the current time or a time in the recent past,
for any certificate in support of any security service.
In order to validate a certificate, a chain of multiple certificates,
called a certification path, may be needed, comprising a certificate
of the public key owner (the end entity) signed by one CA, and zero or
more additional certificates of CAs signed by other CAs.
Offloading path validation to a server may be required by a client
that lacks the processing, and/or communication capabilities to
perform path construction first and then a local path validation.
In constrained execution environments, such as telephones and PDAs,
memory and processing limitations may preclude local implementation of
complete, PKIX-compliant path validation.
In applications where minimum latency is critical, delegating
validation to a trusted server can offer significant advantages.
The time required to send the target certificate to the validation
server, receive the response, and authenticate the response,
can be considerably less than the time required for the client to
perform certification path discovery and validation. Even if a
certification path were readily available to the client, the
processing time associated with signature verification for each
certificate in the path might (especially when validating very long
paths or using very limited processor speed) be greater than the delay
associated with use of a validation server.
Another motivation for offloading path validation is that it allows
validation against validation policies defined by the management in a
consistent fashion across an enterprise. Clients that are able to
do their own path validation may rely on a trusted server to do path
validation if centralized management of validation policies is needed,
or the clients rely on a trusted server to leave centralized traces
of such activities.
Pinkas [Page 2]
Internet Draft DPV&DPD-REQ January 2002
When a client uses this service, it inherently trusts the server as
much as it would its own path validation software (if it contained
such software). Clients can direct the server to perform path
validation in accordance with a particular validation policy.
3. Rationale and benefits for DPD (Delegated Path Discovery)
DPD is valuable for clients that do much of the PKI processing
themselves and simply want a server to collect information for them.
The server is trusted to return the most current information that is
available to it (which may not be the most current information that
has been issued). The client will ultimately perform certification
path validation.
A client that performs path validation for itself may get benefit in
several ways from using a server to acquire certificates, CRLs, and
OCSP responses to aid in the validation process. In this context, the
client is relying on the server to interact with repositories to
acquire the data that the client would otherwise have to acquire using
LDAP [LDAP], HTTP [HTTP], FTP [FTP] or another repository access
protocol. Since these data items are digitally signed, the client need
not trust the server any more than the client would trust the
repositories.
There are several benefits to this approach; for example, a single
query to a server can replace multiple queries to one or more
repositories, and caching 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 with various forms of repositories,
perhaps via different protocols, nor to perform the graph processing
necessary to discover certification paths, separate from making the
queries to acquire path validation data.
4. Validation policy and path discovery policy
Policies MAY be a priori known by the server, or policies MAY be
specified by a client to the server.
Because validation software is controlled by many parameters which,
if incorrectly set, may result in insecure behavior, it is useful
to rely on pre-defined policies that are already known by the servers,
where system security administrators carefully manage them.
Both services (delegated path validation and delegated path discovery)
can be potentially used by an enterprise for enforcing various aspects
of centralized policies.
Alternatively, system security administrators MAY also define policies.
However, such policy definition may be quite complex and only some
forms of policies can be defined in this way, otherwise testing all
the possible variations would lead to non-interoperable implementations
or would increase the time necessary to ensure that two implementations
are interoperable.
Pinkas [Page 3]
Internet Draft DPV&DPD-REQ January 2002
Since policy definitions can be quite long and complex, all the
parameters SHOULD NOT be passed with each individual request; rather,
they SHOULD be defined using a separate policy definition
request/response pair. In response to a successful policy definition
request, the server SHALL return a policy reference (e.g. an OID).
However, some forms of path discovery policy can be simple. In
that case it MAY be acceptable to pass the parameters from the path
discovery policy with each individual request, i.e. a set of trust
anchors and separate revocation status conditions for the end-entity
certificate and for the other certificates (see section 9.2).
The protocol SHALL allow clients to obtain, at any time, the references
for all of the policies supported by the server by using an additional
request/response pair. The response can include references to previously
defined policies or to a priori known policies.
4.1. Validation Policy
A validation policy is a set of rules against which the validation of
the certificate is performed.
A validation policy MAY include several trust anchors. A trust anchor
is defined as one public key, a CA name, a validity time interval, and
optionally additional constrains. The use of a self-signed certificate
is one way to specify together: the public key to be used, the CA
name, and the validity period of the public key.
Additional constrains for each trust anchor MAY be defined. These
constraints might include a set of Certification Policy constraints or
a set of naming constraints. These constrains MAY also be included in
self-signed certificates.
Additional conditions that apply to the certificates in the path MAY
also be specified in the validation policy. For example, specific
values for user-initial-policy-set, initial-policy-mapping-inhibit,
initial-explicit-policy, or initial-any-policy-inhibit could be
provided.
Additional conditions that apply to the end-entity certificate MAY
also be specified in the validation policy. For example, a specific
name form, like an e-mail address either in the rfc822 subject
alternative name or in the emailAddress naming attribute in the
subject name, might be required.
In order to succeed, one valid certification path (i.e., none of the
certificates in the path are expired or revoked) MUST be found between
an end-entity certificate and a trust anchor and all constraints that
apply to the certification path MUST be verified.
Validation policies support security services in two time contexts:
- for immediate use (e.g., to use the public key within a
certificate for symmetric key management), or
Pinkas [Page 4]
Internet Draft DPV&DPD-REQ January 2002
- for a time T in the recent past (e.g., to use the public key
within a certificate to verify data origin authentication and
integrity).
There is an inevitable delay between a compromise of key being noticed
by the end-entity and the report of revocation being made by the CA
(or on behalf of the CA) to the relying parties. This delay exists
even when an OCSP service is used. So, querying the revocation status
of a certificate at a time T never proves that the private key
corresponding to that certificate was not compromised at that time T.
A validation policy MAY support a cautionary period in order to allow
time for:
1) the end-entity to realize that one of its private keys has been
or could possibly be compromised,
2) the end-entity to report the key compromise,
3) the revocation authority to process the revocation request from
the end-entity, and
4) the revocation authority to make available the revocation
status information, e.g. by providing an OCSP service, CRLs,
or delta-CRLs in combination with full CRLs.
When the public key within the certificate is used immediately, it is
not possible to apply a cautionary period, and thus, some risk is
taken, since the corresponding private key might be compromised at the
time of use.
When the public key within the certificate is used to verify some
usage from the recent past, it is possible to apply a cautionary
period to further reduce the risk. In such a case, the policy MAY
indicate a minimum delay to be observed between the time T in the past,
i.e. when the use of the private key took was supposed to take place,
and the time of the current verification.
When the end-entity certificate expires before the cautionary period
terminates, then the end-entity certificate MUST be considered as
invalid. According to section 3.3. Revocation from [PKIX-1] "An entry
may be removed from the CRL after appearing on one regularly scheduled
CRL issued beyond the revoked certificate's validity period", so in
that case the revocation status information is not guaranteed to be
available at the end of the cautionary period. If certificates are
not used close to the end of their validity period, then this
situation will not happen. This means that new certificates should be
issued before the end of the validity period of the current
certificate and with a time interval greater than the cautionary
period.
Pinkas [Page 5]
Internet Draft DPV&DPD-REQ January 2002
4.2. Path discovery policy
A path discovery policy is a set of rules against which the discovery
of a certification path is performed. A path discovery policy is a
subset of a validation policy. A path discovery policy MAY either be
a reference to a validation policy or contain only some major elements
from a validation policy, such as the trust anchors.
Since the client must be "PKI aware", it can locally apply additional
constraints to the certification paths returned by the server. Thus,
a "crude" (i.e. simpler) criteria can be defined and used for DPD.
5. Delegated Path Validation Protocol Requirements
The Delegated Path Validation (DPV) protocol allows a server to
validate one or more certificates according to a validation policy.
A time other than the current time may be used to determine the
validity. The validation policy SHALL be known by the DPV server.
The validation policy MAY be defined using an additional request/
response pair (see section 10) prior to the DPV request. In this way
clients only need to be aware of the reference of the validation
policy to be used by a given application.
The certificate to be validated MUST either be directly provided in
the request or an unambiguous reference MUST be provided, such as
the CA distinguished name, certificate serial number, and the hash
of the certificate, like ESSCertID as defined in [ESS] or
OtherSigningCertificate as defined in [ES-F].
The client MUST be able to provide to the validation server, associated
with each certificate to be validated, "useful certificates", as well
as "useful revocation information". Revocation information includes
OCSP responses, CRLs, and delta-CRLs. As an example, an S/MIME message
might include such information, and the client can simply copy that
information into the DPV request.
In order to obtain the revocation status information of any
certificate from the certification path, the DPV server might use, in
accordance with the validation policy, different sources of revocation
information, e.g. a combination of OCSP responses, CRLs, or delta-CRLs.
If the DPV request does not specify a validation policy, the server
response MUST indicate the one that was used. In such a case, the
client must verify that the one selected by the server is appropriate.
The DPV response MUST indicate one of four status alternatives:
1) the certificate is valid according to the validation policy.
2) the certificate is definitively invalid according to the
validation policy.
Pinkas [Page 6]
Internet Draft DPV&DPD-REQ January 2002
3) the certificate is not yet valid at this time. If another
request could made later on, the certificate could possibly be
determined as valid. This condition will occur before a
certificate validity period has begun, while a certificate is
suspended, or when the validation is made at a time where the
cautionary period has not yet ended.
4) the server cannot determine the validity of the certificate.
This condition will occur when a certification path cannot be
constructed or some revocation information is unavailable.
The DPV request MUST allow the client to request the response to
include the certification path and revocation status information used
by the server to process the request. When requested, the server MUST
include the certification path and revocation status information in
the response when the certificate is valid according to the validation
policy. However, the server MAY omit the certification path and
revocation status information when the certificate is invalid or
when it cannot determine the validity.
In order to be able to be confident that the validation of the
certificate has correctly been done, the client only requires an
authenticated response.
In order for the client to prove to another party that trusts the
same DPV server that the certificate validation was correct, the
client requires a signed response. All the parameters needed to prove
that the response conforms to the request SHALL be copied from the
request into the response, so that a response is self-sufficient proof.
The server may require client authentication. The authentication
method to be used may be dependant upon the transport used, and thus
the client authentication mechanism need not be an integral part of
the DPV request.
6. Delegated Path Discovery Protocol Requirements
The Delegated Path Discovery (DPD) protocol allows the client to use a
single protocol towards a single server to collect at one time all the
data elements that might be collected using different protocols (e.g.
LDAP, DAP, OCSP) or by querying multiple servers, according to a
single path discovery policy. Then returned information can be used to
locally validate one or more certificates for the current time.
Clients MUST be able to specify whether they want, in addition to the
certification path, the revocation information associated with the
path, for the end-entity certificate only, for the CA certificates
only or for both.
The path discovery policy MUST be known by the DPD server. The path
discovery policy MAY defined using an additional request/response pair
(see section 7) prior to the DPD request.
Pinkas [Page 7]
Internet Draft DPV&DPD-REQ January 2002
The server response MUST include zero, one, or several certification
paths. Each path consists of a sequence of certificates, starting with
the certificate to be validated and ending with one issued by a trust
anchor. The trust anchor self-signed certificate, if issued, is not
included. In addition, the revocation information associated with
each certificate in the path MUST also be returned, if it has been
requested.
The client needs to be able to limit the number of paths returned.
Therefore the client MUST be able to indicate the maximum number of
certification paths that SHOULD be returned (provided that they can be
found). If the number is not specified, that number defaults to one.
The paths that are returned may need to match some additional local
controls done by the client, e.g. verifying some certificate
extensions. The returned paths may not be appropriate to the client
when it locally applies additional tests. Instead of asking one by
one the paths (which would require state information at the server),
the client specifies with every request the maximum number of paths
to be returned.
If that number cannot be reached by the server, an indication SHOULD
be returned by the server showing that an additional query will not
return more paths.
If the paths that are returned do not match the local conditions, then
the number of number of certification paths to be returned can be
extended, by augmenting this value. Previously found paths will likely
be returned, but the client can easily discard them. This avoids
requirements for state information at the server, but does not prevent
a server from maintaining a cache of previous responses.
The goal is to avoid the maintenance of state information for previous
requests: if this is done, it minimizes potential denial of service
attacks or other problems associated with server crashes.
Path discovery MUST be performed according to the path discovery policy.
The DPD response MUST indicate one of four status alternatives:
1) one or more certification paths was found according to the
path discovery policy, with all of the requested revocation
information present.
2) one or more certification paths was found according to the
path discovery policy, with a subset of the requested revocation
information present.
3) one or more certification paths was found according to the
path discovery policy, with none of the requested revocation
information present.
4) no certification path was found according to the path
discovery criteria.
Pinkas [Page 8]
Internet Draft DPV&DPD-REQ January 2002
The information that is returned consists of one or more certification
paths and optionally its associated revocation status information for
each element from the path.
To provide confidence that the response originates from the DPD server,
the server MAY provide an authenticated response. For example, the
server might sign the response.
7. Policy definition protocol (PDP) requirements
The support of these request/response pairs is OPTIONAL, or they might
be implemented in a separate protocol from DPD or DPV.
These request/response pairs allow the client to define a policy,
i.e. a validation policy and/or a path discovery policy, and to
receive back a reference for that policy. The server may provide a
reference to a previously defined policy, if it fulfills the request
requirements.
The policies locally defined at the server may be more precise than
the policies defined using these request/response pairs, since such an
exchange will not have all the flexibility necessary to describe any
kind of policy. So, in practice, these request/response pairs will be
restricted to the definition of relatively simple policies.
Usually, these request/response pairs will be used by managers to
register the policies to be used by ordinary clients, such as those
within an organization for use with various applications.
Policy definition requests SHALL be able to be authenticated so that
only authorized clients can register policies.
Policy definition response, if successful, SHALL return a policy
reference. The policy reference MAY be specific to the request, or
it MAY be a reference to a policy that has already been established
and fulfills the request requirements.
It is up to server to decide how long a temporary defined policy will
be maintained.
When a obtaining a policy reference from the server, it would be
interesting to consider providing natural language information about
the purpose of the policy, rather than the technical description of
the policy.
When using DPV, there are two possibilities:
a) The client is a little bit PKI-aware, in the sense that it is
only able to parse the end-entity certificate to check some
properties of a certificate, and delegates the validation of the
rest of the path to the server. It appears easier to remotely
define such "partial policies" since some tests on the end-
entity certificate are left to the client.
Pinkas [Page 9]
Internet Draft DPV&DPD-REQ January 2002
b) The client is fully PKI-unaware, and thus fully delegates the
validation to the server. It appears more difficult to remotely
define such "complete policies" since the tests on the end-
certificate are made by the server and may be quite complex.
When using DPD, simpler validation policies may be defined since
all DPD clients are fully PKI-aware.
8. Components for a validation policy
A validation policy is build from four components:
1. Certification path requirements,
2. Revocation requirements,
3. End-entity certificate specific requirements,
4. optionally, cautionary period requirements.
Note: [ES-P] defines ASN.1 data elements that may be useful while
defining the components of a validation policy.
8.1. Certificate chain requirements
The PDP protocol MUST allow the client to specify certification path
requirements. The path requirements identify a sequence of trust
anchors used to start certification path processing and initial
conditions for certification path validation as defined in [PKIX-1].
8.2. Revocation Requirements
The PDP protocol MUST allow the client to specify revocation checking
requirements. Revocation information may be obtained through CRLs,
delta-CRLs or OCSP responses. Certificate revocation requirements are
specified both in terms of checks required on the end-entity
certificate (i.e. the certificate for which a path is required) and on
checks required on CA certificates.
Revocation requirements for the end-entity certificate may not be the
same as the requirements for the CA certificates. For example, an OCSP
response may be needed for the end-entity certificate while CRLs may
be sufficient for the CA certificates. Therefore, the PDP protocol
MUST allow the client to specify separate requirements for the
end-entity certificate and for the CA certificates.
The PDP protocol MUST allow the client to specify the source of revocation
information, in particular if :
- full CRLs (or full Authority revocation lists) have to be
collected,
- OCSP responses, using [OCSP], have to be collected,
- delta-CRLs and the relevant associated full CRLs (or full
Authority revocation lists) are to be collected.
Pinkas [Page 10]
Internet Draft DPV&DPD-REQ January 2002
- any available revocation information has to be collected.
8.3. End-entity certificate specific requirements
The PDP protocol MUST allow the client to specify requirements that
apply only to the end-entity certificate (i.e. the certificate that
is the object of the query).
The client might require the end-entity certificate to contain
specific extensions with specific types or values (it does not matter
whether they are critical or non-critical).
For example, the client might need an end-entity certificate that
contains an electronic mail address (either in the rfc822 subject alt
name or in the emailAddress naming attribute in the subject name).
8.4. Cautionary period requirements
The PDP protocol SHALL allow the client to specify a cautionary period
for a validation policy. The cautionary period specifies a minimum
delay to be observed between a time T in the recent past, where the
use of the private key or the public key is supposed to take place,
and the time of the current validation.
9. Components for a path discovery policy
The PDP protocol SHALL be able to support certification path
requirements and revocation requirements. It MAY support end-entity
certificate specific requirements. These requirements are specified in
sections 8.1, 8.2, and 8.3, respectively.
10. DPV versus DSV
DPV performs the validation of a certificate against a policy, but
does not necessarily provide all the information needed to prove to
someone else that is not trusting the same DPV server that a digital
signature from a signer was produced while the signer's certificate
was valid.
A Delegated Signature Validation (DSV) service could be specified to
allow to prove later on to someone else, not trusting the same DSV
server, that a digital signature was applied while the certificate
was valid. Requirements for a Delegated Signature Validation (DSV)
service that allows to fully delegate the validation of a digital
signature to a DSV server might be addressed in a separate document at
a future time.
11. Security considerations
A client must trust a DPV server to provide the correct answer.
However, this does not mean that all clients will trust the same
servers. While a positive answer might be sufficient for one client,
that positive answer will not necessarily convince another client.
Pinkas [Page 11]
Internet Draft DPV&DPD-REQ January 2002
Other clients may trust their own servers, or they might perform
certification path validation themselves. Clients operating under
an organizational policy must ensure that each of the servers they
trust is operating under that organizational policy.
12. Acknowledgments
These requirements have been refined after some valuable inputs from
Ambarish Malpani and Paul Hoffman.
13. References
[PKIX-1]
Internet X.509 Public Key Infrastructure.
Certificate and CRL Profile. RFC 2459
R. Housley, W. Ford, W. Polk, D. Solo.
or its successor as soon as it can be referenced.
[OCSP]
X.509 Internet Public Key Infrastructure.
Online Certificate Status Protocol - OCSP. RFC 2560
M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams.
[ES-F]
Electronic Signature Formats for long term electronic signatures
RFC 3126. D. Pinkas, J. Ross, N. Pope. September 2001.
[ES-P]
Electronic Signature Policies. RFC 3125.
D. Pinkas, J. Ross, N. Pope. September 2001.
[CMS]
Cryptographic Message Syntax. RFC 2630. R. Housley June 1999.
or its successor as soon as it can be referenced.
[ESS]
Enhanced Security Services for S/MIME. RFC 2634. P. Hoffman.
RFC 2634, June 1999.
[ISO-X509]
ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information
Technology - Open Systems Interconnection: The Directory:
Authentication Framework," 1997 edition. (Pending publication
of 1997 edition, use 1993 edition with the following amendment
applied: Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8
on Certificate Extensions, June 1996.)
Pinkas [Page 12]
Internet Draft DPV&DPD-REQ January 2002
[FTP]
Internet X.509 Public Key Infrastructure. Operational Protocols:
FTP and HTTP. RFC 2585. R. Housley, P. Hoffman. May 1999.
[HTTP]
Internet X.509 Public Key Infrastructure. Operational Protocols:
FTP and HTTP. RFC 2585. R. Housley, P. Hoffman. May 1999.
[LDAP]
Internet X.509 Public Key Infrastructure Operational Protocols
LDAPv2. RFC 2559. S. Boeyen, T. Howes, P. Richard. April 1999.
14. Authors' addresses
Denis Pinkas
Integris, Bull.
68, Route de Versailles
78434 Louveciennes CEDEX
FRANCE
e-mail: Denis.Pinkas@bull.net
Russell Housley
RSA Laboratories
918 Spring Knoll Drive
Herndon, VA 20170
USA
rhousley@rsasecurity.com
15. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Pinkas [Page 13]
Internet Draft DPV&DPD-REQ January 2002
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Pinkas [Page 14]