Internet Draft Denis Pinkas, Integris
draft-ietf-pkix-dsv-dpv-dpd-req-00.txt October 2001
Target Category: INFORMATIONAL
Expires in six months
Delegated Signature Validation
Delegated Path Validation and
Delegated Path Discovery
Protocol Requirements
<draft-ietf-pkix-dsv-dpv-dpd-req-00.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.
1. Abstract
This document specifies requirements for three main request/response
pairs.
The first one, called Delegated Signature Validation (DSV), can be used
to fully delegate signature validation processing to an DSV server,
according to a set of rules, called a signature policy.
The second 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 third one, called Delegated Path Discovery (DPD), can be used to
obtain from a DPD server all the information needed (e.g. leaf
certificates, CA certificates, full CRLs, delta-CRLs, OCSP responses)
to locally validate a certificate according to a set of rules, called a
path discovery policy.
It also defines the requirements for two optional request/response
pairs, either for allowing to indicate to a signature validation server
a signature policy, to a validation server a validation policy, or to a
path discovery server a path discovery policy; or giving the reference
of a policy to get the details of an already defined policy.
Pinkas [Page 1]
Internet Draft DSV-DPV&DPD October 2001
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].
2. Rational and benefits
These delegated processing provides three primary services: delegated
signature validation, delegated path validation and delegated path
discovery. Not all clients require all services in all scenarios.
Some clients have requirements for offloaded signature validation
since signature validation rules may be quite complex.
Some clients have requirements for offloaded path validation and have
no need for data acquisition, while some other clients require only
delegated path discovery to help them perform their own path
validation.
2.1. Rational and benefits for DSV (Delegated Signature Validation)
Offloading signature validation to a server may be required by a
client that lacks the processing, and/or communication capabilities to
perform signature validation by himself. In constrained execution
environments such as telephones and PDAs, memory and processing
limitations may preclude implementation of complete, PKIX-compliant
signature validation.
In applications where minimum latency is critical, delegating
validation to a trusted server can offer significant advantages. The
time required by the server for the processing can be considerably
less than the time required by the client to perform the same thing.
Even if a signature validation capabilities were readily available to
the client, the delay associated with processing the signatures for
each certificate in the path might (under some circumstances such as
very long paths or very limited processor speed) be greater than the
delay associated with use of a validation server.
Another motivation for offloading signature validation is that it
allows validation against signature policies defined by the management
in a consistent fashion across an enterprise.
Even clients able to do their own signature validation may rely on a
trusted server to do signature validation if clients are in an
environment where centralized management of signature policies is
needed for some applications.
When a client uses this service, it inherently trusts the server as
much as it would its own signature validation software (if it
contained such software). When there is no need to prove later on to
someone else that the signature was indeed valid, the positive or
negative answer from the DSV is sufficient.
Pinkas [Page 2]
Internet Draft DSV-DPV&DPD October 2001
However, there are cases where clients will need to prove later on to
someone not trusting the same DSV server that the signature was indeed
valid. So they need to get back from the DSV server the validation data
that has been used by their server so that this information can be
tested again by a different DSV server or a local software.
In these cases, it is fundamental to be able to prove that the
signature was indeed generated while the signer's certificate was
valid, otherwise, should the private key be compromised, faked
signatures could be recognized later on as valid.
The end of validity of a certificate is determined either by the end
of the validity period of the certificate or by the revocation date of
the certificate, should the certificate be revoked. Since it is not
possible to know for sure when the signature was generated, it is
necessary to be able to prove that the signature was generated before
a given time and then to compare that given time with either the date
of the end of the validity of the certificate or with the date of
revocation of the certificate, whichever is the sooner.
The proof that the signature was generated before a given time may be
obtained in two ways:
1) by using a time-stamp token applied to the signature.
This proves that the signature was generated before the
time/date included in the time-stamp token,
2) by using a time-mark applied to the signature.
A time-mark is an audit record kept in a secure audit trail
from a trusted third party which attaches a date to
a signature value. This also proves that the signature was
generated before the time/date from the time-mark.
2.2. Rational and benefits for DPV (Delegated Path Validation)
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 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 verify the signature on the response,
can be considerably less than the time required by the client to
perform path discovery and validation. Even if a certificate path were
readily available to the client, the delay associated with processing
the signatures for each certificate in the path might (under some
circumstances such as very long paths or very limited processor speed)
be greater than the delay associated with use of a validation server.
Pinkas [Page 3]
Internet Draft DSV-DPV&DPD October 2001
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.
Even clients that are able to do their own path validation may rely on
a trusted server to do path validation if clients are in an
environment where centralized management of validation policies is
needed for some applications.
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).
Servers can also take directions from the client about how path
validation should be done (such as which validation policy shall be
used).
In all these cases, the client will delegate path validation to a
fully-trusted server.
2.3. Rational 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 need not even be trusted, because the client will
ultimately perform 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, HTTP, and so on. Since these data items are digitally signed,
the client need not trust the server to return the "right" data any
more than the client would have to 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 directories 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 paths, separate from making the queries to acquire path
validation data.
In these cases, the client will delegate path discovery to an untrusted
server.
3. Signature policy, validation policy and path discovery policy
Policies may be a priori known by the server or may be specified by
the client to the server.
Because validation software is controlled by many parameters which,
if incorrectly set, may result in insecure behavior, it is often
Pinkas [Page 4]
Internet Draft DSV-DPV&DPD October 2001
important to be able rely on pre-defined policies that are already
known by the servers, where system security administrators can
carefully manage them. Both services (delegated path validation and
delegated path discovery) can be potentially used by the enterprise
for enforcing various aspects of centralized policy.
Alternatively, clients may also define policies. However, such policy
definition may be quite complex and only simple forms of policies can
be defined in this way.
Since policy definitions can be quite long and complex, all the
parameters should not be passed with each individual request but a
reference to either an a priori known policy (e.g. an OID) or an
already pre-defined policy (e.g. a reference returned by the server)
should be used.
Some forms of path discovery policy can be simple enough, e.g. a set
of self-signed certificates. In that case it may be acceptable to pass
all the parameters from the path discovery policy with each individual
request.
3.1. Signature Policy
A signature policy is a set of rules against which the validation of a
digital signature is performed.
A signature policy may include several trust anchors. A trust anchor
is defined as one public key value (root key) for a given CA name,
valid during some time interval. The use of a self-signed certificate
allows to specify such a trust anchor: the public key to be used, the
CA name and the validity period of the root key.
Additional constrains for each trust anchor MAY be defined, such as a
set of Certification Policy constraints and a set of naming
constraints. In some cases, these constrains MAY also be included in
self-signed certificates.
Additional conditions that apply to the certificates from the chain,
(e.g. user-initial-policy-set, initial-policy-mapping-inhibit, initial-
explicit-policy, or initial-any-policy-inhibit) or to the end-
certificate (e.g. a name form that must be present in the end-
certificate, like an e-mail address either in the rfc822 subject alt
name or in the emailAddress attribute in the subject name) MAY also be
specified in the signature policy.
In order to succeed, one valid path (i.e. none of the certificates
from the path must be revoked) must be found between a leaf
certificate and a trust anchor and all constraints that apply to the
certificate chain must be verified.
However, if signature validation is made in the context of a non-
repudiation service (instead of a data origin authentication service)
the above conditions are not sufficient. The signature policy has to
define whether time-stamping or time marking shall be used as well as
Pinkas [Page 5]
Internet Draft DSV-DPV&DPD October 2001
the delay that may exist between the date included in the time-stamp or
the time-mark and the delay until a possible revocation will be
advertised. This delay may be necessary so that legitimate signers that
have had their private key compromised have some time to report the
compromise, and then that the revocation status information may be made
available.
When time-stamping is mandated by the signature policy, the policy
must indicate the names or the characteristics of the TSA(s) to be
used.
3.2. 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 value (root key) for a given CA name,
valid during some time interval. The use of a self-signed certificate
allows to specify at the same time: the public key to be used, the CA
name and the validity period of the root key.
Additional constrains for each trust anchor MAY be defined, such as a
set of Certification Policy constraints and a set of naming
constraints. In some cases, these constrains MAY also be included in
self-signed certificates.
Additional conditions that apply to the certificates from the chain,
(e.g. user-initial-policy-set, initial-policy-mapping-inhibit, initial-
explicit-policy, or initial-any-policy-inhibit) or to the end-
certificate (e.g. a name form that must be present in the end-
certificate, like an e-mail address either in the rfc822 subject alt
name or in the emailAddress attribute in the subject name) MAY also be
specified in the validation policy.
In order to succeed, one valid path (i.e. none of the certificates
from the path must be revoked) must be found between a leaf certificate
and a trust anchor and all constraints that apply to the certificate
chain must be verified.
3.3. 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 may either be a reference to a validation
policy or contain only some major elements from a validation policy,
e.g. the root keys to be used to construct the path.
Since the client MUST be "PKI aware", it shall be able to locally
apply additional constraints on the certification paths that may be
returned. Thus "crude" (i.e. simpler) criteria can be defined and used
in that case.
Pinkas [Page 6]
Internet Draft DSV-DPV&DPD October 2001
The client needs to be able to limit the number of paths to be returned
so that the server does not loose time to find out more paths than
requested. While making that limitation, the returned paths may not be
appropriate to the client when it then locally applies additional
tests. Instead of asking one by one the paths (which would mandate to
manage state information at the server), the client will specify with
every request the maximum number of paths that may 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.
When that number is reached, and when more paths are needed, that
number can be increased. Previously found paths will likely be
returned, but the client can easily discard them. This avoids to
mandate the management of state information at the server, but does
not prevent a server to maintain a cache of previous responses.
4. Delegated Signature Validation Protocol Requirements
The Delegated Signature Validation (DSV) protocol allows to validate
one digital signature for a time T and according to a single set of
rules, called a signature policy. The signature policy shall be known
by the DSV server. When it isn't, it may defined using an additional
protocol (see section 10). In this way clients only need to be aware
of the reference of the signature policy to be used by a given
application.
The digital signature to be validated must be provided in the request.
In addition, the certificate to be used to validate the signature must
either be directly provided in the request or alternatively an
unambiguous reference must be provided, e.g. the CA name and
certificate serial number together with the hash of the certificate
like ESSCertID as defined in RFC 2634.
In order to help the server, the client MAY provide to the validation
server "useful certificates", as well as "useful revocation
information" that MAY be used by the validation server (e.g. of OCSP
requests, CRLs or delta-CRLs). As an example, an S/MIME message may
include such information and the client can simply copy and paste that
information.
When time-stamping is required by the signature policy, the DSV server
must provide the time-stamp token, unless it is already provided by
the client.
When time-marking is required by the signature policy, the client must
provide the date of the time-mark so that the server can compare it
either to the date for the end of the validity of the certificate or
to the date of revocation of the certificate, whichever is the sooner.
That date must be returned in the response.
The time T may be close to the present time or a time in the past.
When it is a time close to the present time, the server MUST do its
Pinkas [Page 7]
Internet Draft DSV-DPV&DPD October 2001
best efforts to perform the signature validation (signature validation
in the past may not be possible if the required data may not be
collected).
When it is a time in the past, the signature policy must include
provisions to support non repudiation by using either time-stamping or
time-marking.
The support of revalidation, i.e. validation in the past using some
data previously obtained at the time of an initial signature
verification, which does not require the server to keep validation
data from the past is optional. Revalidation is useful when there is a
dispute and when the signature validation originally performed by a
given signature validation server is not trusted by the other party.
Revalidation, can be done either by the same DSV server or by another
DSV server. Presenting the data captured at the time of a previous
validation is required to get that service.
The support of signature validation in the past without presenting some
validation data previously obtained (and which thus requires the server
to keep validation data from the past) is optional.
In order to obtain the revocation status information of any
certificate from the certification path, the DSV server MAY use, in
accordance with the validation policy, different sources of revocation
information, e.g. a combination of OCSP requests, CRLs or delta-CRLs.
If the client does not specify in its request the signature validation
policy to be used, the server MUST indicate in the response the one
that has been used. In such a case, the client MUST verify that the
one that has been selected is appropriate for its use.
The status of the response may be one out of four types:
1) the signature is valid according to the signature policy,
2) the signature is definitively invalid according to the
signature policy,
3) the signature is not yet valid at this time according to the
signature policy. A path has been able to be constructed,
however one or more revocation status information are missing
or one or more certificates are currently suspended.
If another request could made later on, all the certificates
could possibly be determined as not revoked. In some cases, it
may be indicated when another request should be attempted.
4) the server cannot determine the validity of the signature
(e.g. a path cannot be constructed).
In most instances, in order to be able to be confident that signature
validation has correctly be done, the client will only require an
authenticated response.
Pinkas [Page 8]
Internet Draft DSV-DPV&DPD October 2001
However, there are cases when the client needs to prove to another
party that he got a response from the right responder. In that case a
non repudiation service has to be supported.
Both the data origin authentication service and the non-repudiation
service may be obtained using signed responses.
Finally, there are cases when that response cannot be trusted by the
disputing parties, in particular by a judge when trying to solve the
dispute. In that case the validation data that has been effectively be
used during the validation process must be reused, so that the same
validation data can be re-checked again either locally or by another
validation server.
If that validation data was directly part of the signed response, then
the signed positive response could be rather long, if needed to be
stored. For that reason, since the validation data still needs to be
integrity protected, the protection should be obtained using a hash of
the validation data included in the signed response instead of
protecting directly the validation data itself by the signature.
Validation data needed for non-repudiation has been defined in [ES-F].
In order to be able to directly copy and paste that validation data,
the same data elements as defined in [ES-F] should be supported.
[ES-F] mandates to keep the references of the path with the signature,
while the actual values of the path (which are for more voluminous)
may be stored elsewhere. This means that in this case, two hashes for
the validation data should be supported: one for the path references
and one for the path values.
Provisions should also exist in the protocol so that other validation
data structures can be supported in the future.
[ES-F] also allows to protect the path in case any key from the path
is compromised after the validation time. This is provided by using
one or more time-stamps tokens. The signature policy must indicate
whether or not time-stamping is required and, when required, will
indicate the TSA(s) to be used.
When doing a re-validation, the client may need to send back the
validation data that it originally received: either the references
only or both the references and the actual values of the path.
5. Delegated Path Validation Protocol Requirements
The Delegated Path Validation (DPV) protocol allows to validate one or
more certificate for the current time and according to a single set of
rules, called a validation policy. The validation policy shall be
known by the DPV server. When it isn't, it may defined using an
additional protocol (see section 8). In this way clients only need to
be aware of the reference of the validation policy to be used by a
given application.
Pinkas [Page 9]
Internet Draft DSV-DPV&DPD October 2001
The certificate to be validated may either be directly provided in the
request or alternatively an unambiguous reference may be provided,
e.g. the CA name and certificate serial number together with the hash
of the certificate like ESSCertID as defined in RFC 2634.
In order to help the server, the client MAY provide to the validation
server "useful certificates", as well as "useful revocation
information" that MAY be used by the validation server (e.g. of OCSP
requests, CRLs or delta-CRLs). As an example, an S/MIME message may
include such information and the client can simply copy and paste that
information.
In order to obtain the revocation status information of any
certificate from the certification path, the DPV server MAY use, in
accordance with the validation policy, different sources of revocation
information, e.g. a combination of OCSP requests, CRLs or delta-CRLs.
If the client does not specify in its request the validation policy to
be used, the server MUST indicate in the response the one that has
been used. In such a case, the client MUST verify that the one that
has been selected selected is appropriate for its use.
The status of the response may be one out of three types:
1) the certificate is valid according to the validation policy,
2) the certificate is invalid according to the validation policy,
3) the server cannot determine the validity of the certificate
(e.g. a path cannot be constructed).
In order to be able to be confident that the validation of the
certificate has correctly be done, the client will only require an
authenticated response.
6. Delegated Path Discovery Protocol Requirements
The Delegated Path Discovery (DPD) protocol allows 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. Then this information can
locally be used to validate one or more certificates for the current
time and according to a single path discovery policy.
The path discovery policy may be known a priori by the DPD server.
When it isn't, it may defined using an additional protocol
(see section 8).
None, one or several certification paths may be returned. Each path
consists of a sequence of certificates, starting after the certificate
to validate and ending with one self-signed certificate. In addition,
the revocation information associated with each path may also be
returned.
Pinkas [Page 10]
Internet Draft DSV-DPV&DPD October 2001
The paths that are returned may need to match some additional local
controls done by the client, e.g. verifying some certificate
extensions.
The client may indicate the maximum number of certification paths that
MUST be returned (provided that they may be found). If the number is
not specified, that number is defaulted to one.
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.
The server may use a local cache to avoid to search again the same
elements, but is not mandated to maintain any local state information
from any previous request. The goal is to avoid to maintain state
information on previous requests: if this is done, it optimizes the
response time.
Path discovery is performed according to the path discovery policy.
The status of the response may be one out of three types:
1) one or more certification paths could be found according to the
path discovery policy, with partial or full revocation
information present.
2) one or more certification paths could be found according to the
path discovery policy, with no revocation information present.
3) no certification path could be found according to the path
validation criteria,
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.
In order to be able to be confident that the values returned are coming
from the DPV server, the client will only require an authenticated
response.
7. Components for a validation policy
A validation policy is build from four components:
1. Certificate chain requirements,
2. Revocation requirements,
3. End-certificate specific requirements
7.1. Certificate chain requirements
The certificate requirements identifies a sequence of trust anchors
used to start (or end) certificate path processing and the initial
conditions for certificate path validation as defined in [PKIX-1].
Pinkas [Page 11]
Internet Draft DSV-DPV&DPD October 2001
7.2. Revocation 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-certificate (i.e. the
certificate for which a path is required) and on checks required on CA
certificates.
It can then specified if :
- full CRLs (or full Authority revocation lists) have to be
collected,
- OCSP responses, using RFC 2560, have to be collected,
- delta-CRLs and the relevant associated full CRLs (or full
Authority revocation lists) are to be collected.
None, one or more of the above conditions may apply.
7.3. End-certificate specific requirements
There may be requirements that apply only to the end-certificate (i.e.
the certificate that is the object of the query).
For example, the end-certificate must contain specific extensions with
specific types or values (it does not matter whether they are critical
or non critical). As an example, the end-certificate must contain a
name form like an e-mail address either in the rfc822 subject alt name
or in the emailAddress attribute in the subject name.
Another more difficult example, is to make sure that the certificate
is a Qualified Certificate, as meant by the European Directive on
Electronic Signatures. There are two ways to check that property:
1) the OID of the Certification Policy contains a specific value,
2) a QC-Statement extension is present and contains a specific
value.
While defining the end-certificate requirements, these examples should
be taken into consideration.
8. Components for a signature policy
A signature policy is build from the same three elements of a
validation policy and may include additional Time-Stamping requirements
to support a non-repudiation service.
The Time-Stamping Requirements identify both the number of time-stamps
to be used over the signer's digital signature as well as the names or
the types of TSAs to be used. Additional Time-Stamping requirements
may be specified over the references of the paths in order to protect
against a compromission of a private key of any Authority (CAs, CRL
Issuer or OCSP responder) from the path.
Pinkas [Page 12]
Internet Draft DSV-DPV&DPD October 2001
9. Components for a path discovery policy
A path discovery must include certificate chain requirements, and may
include revocation requirements, and end-certificate specific
requirements.
10. Policy definition protocol (PDP)requirements
The support of this request/response pair (and its dual
request/response pair) is optional. It allows to define signature
policies, validation policies and/or path discovery policies.
Policies locally predefined at the server may be more precise than
policies defined using this optional protocol.
Thus this optional protocol will never have all the flexibility to
describe any kind of policy. So in practice it will be restricted to
define relatively simple policies.
Usually, this protocol will be used by managers to register the
policies to be used, e.g. within an organization for various
applications. As a result of the registration, managers will receive a
reference of the policy.
These requests shall be able to be authenticated so that only
authorized clients can register policies (and thus avoid denial of
service attacks by registering useless policies).
These request/response pairs allow either to define a policy and to
receive back a reference for that policy or to provide a reference to a
previously defined policy and to receive back the definition of that
policy.
The reference of the policy may be specific to the request or may be a
reference that has already been provided as the result of a previous
request with an identical definition.
It is up to server to decide how long a temporary defined policy will
be kept.
In case the policy is locally defined at the server, when querying a
policy reference, it would be interesting to consider to provide back
information about the purpose of the policy in a natural language.
Should that functionality be supported, then it would be beneficial to
enable such information to be defined while remotely defining the
technical parts of a validation policy. See [ES-P] for more details on
this topic.
When using DSV or 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-certificate to check some properties
Pinkas [Page 13]
Internet Draft DSV-DPV&DPD October 2001
in that certificate, and delegates the validation of the rest
of the path to the server. It appears easier to remotely define
such "partial policies" since the tests on the end-certificate
are left to the client.
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
anyway clients need to be fully PKI-aware to do other tests.
11. Security considerations
A client may trust a DSV or a DCV server to provide the right answer.
However, this does not mean that all clients will trust the same
servers. Thus while a positive answer may be sufficient for a client,
that positive answer will not necessarily be able to convince another
client. That other clients will trust their own servers and will query
them. Queries relative to the current time can easily be done to
another server.
12. Acknowledgments
These requirements have been refined after some valuable inputs from
Ambarish Malpani, Russ Housley 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.
[TSP]
Internet X.509 Public Key Infrastructure
Time-Stamp Protocol (TSP). RFC 3161
C. Adams, P. Cain, D. Pinkas, R. Zuccherato.
Pinkas [Page 14]
Internet Draft DSV-DPV&DPD October 2001
[ES-F]
Electronic Signature Formats for long term electronic signatures
<draft-ietf-smime-esformats-04.txt>
D. Pinkas, J. Ross, N. Pope. RFC 3126.
[ES-P]
Electronic Signature Policies
<draft-ietf-smime-espolicies-01.txt>
D. Pinkas, J. Ross, N. Pope. RFC 3125.
[CMS]
Cryptographic Message Syntax. RFC 2630. R. Housley 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.)
14. Authors' address
Denis Pinkas
Integris, Bull.
68, Route de Versailles
78434 Louveciennes CEDEX
FRANCE
e-mail: Denis.Pinkas@bull.net
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.
Pinkas [Page 15]
Internet Draft DSV-DPV&DPD October 2001
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
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 16]
