GWD-I
Category: Informational
CAOPS-WG
Olle Mulmo, KTH
Michael Helm, ESnet/LBL
Jesus Luna, UPC
Oscar Manso, CertiVer
Milan Sova, CESNET
March 2016
1
2
OCSP Requirements for Grids
3
Edit: OCSP_Requirements_for_Grids-06-08
4
Status of This Memo
5
6
7
This memo provides information to the Grid community on the use and applicability of using the
Online Certificate Status Protocol (OCSP) for X.509 public-key and attribute certificates. It does
not define any standards or technical recommendations. Distribution is unlimited.
8
Copyright Notice
9
Copyright © Global Grid Forum (2016). All Rights Reserved.
10
Abstract
11
12
13
14
15
16
17
18
19
20
21
22
23
Grids use X.509 certificates for authentication and authorization. While certificates have built-in
lifetimes, this is insufficient: lists of revoked certificates are required by many relying parties, and
should be used by every relying party, in order to eliminate lost, compromised, or otherwiseinvalid certificates from use. Commercial credit and debit cards are managed in an analogous
fashion. The Online Certificate Status Protocol (OCSP) is a protocol that can be used to provide
this service for Grid stakeholders. OCSP is a simple query protocol, relieving its clients of the
burden of managing lists of revoked certificates. The OCSP protocol is flexible and extensible,
allowing certificate validation services beyond the simple reporting of contents of certificate
revocation lists (CRLs). The Grid presents considerable challenges for such a service, however.
To be suitable for Grid use, OCSP services must be discoverable, fault tolerant and low latency.
Grid administrators need to develop interoperability methods, “chaining” methods from one OCSP
responder to another, authorized OCSP responder mechanisms for multiple CAs, and replication
techniques.
24
helm@es.net
1
GWD-I
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
March 2016
Table of Contents
Abstract ............................................................................................................................................ 1
Table of Contents ............................................................................................................................ 2
1 Introduction ............................................................................................................................... 4
2 Practical Considerations and Expectations .............................................................................. 4
3 Protocol Overview .................................................................................................................... 5
3.1
OCSP Characteristics ....................................................................................................... 5
3.2
Certificate Revocation Lists............................................................................................... 6
3.3
OCSP Latency and Cautionary Period ............................................................................. 7
4 OCSP Relying Party Requirements ......................................................................................... 8
4.1
Network Requirements...................................................................................................... 8
4.2
Revocation Source Requirements .................................................................................... 8
4.3
Caching OCSP Responses ............................................................................................... 8
4.4
Responder Discovery ........................................................................................................ 9
4.5
Nonce ................................................................................................................................ 9
4.6
AuthorityInfoAccess Extension........................................................................................ 10
4.7
Error Handling and the Unknown Status Code ............................................................... 10
4.8
OCSP Request Signing. .................................................................................................. 10
5 OCSP Responder Requirements ........................................................................................... 10
5.1
Performance, Key Protection .......................................................................................... 10
5.2
Responder Certificate ..................................................................................................... 11
5.3
Revocation Information Sources ..................................................................................... 11
5.4
Transponder Mode .......................................................................................................... 11
6 Proxy Certificates and OCSP Proxy Responders .................................................................. 12
6.1
Proxy Certificate Characteristics ..................................................................................... 12
6.2
Proxy Certificate Revocation ........................................................................................... 12
6.3
Requirements for Proxy Certificate Revocation Services ............................................... 13
6.3.1
OCSP Authorized Proxy Cert Responder ................................................................ 14
6.3.2
OCSP Trusted Proxy Cert Responder ..................................................................... 14
6.4
MyProxy Certificate Store ............................................................................................... 14
7 Certificate Authority Requirements ........................................................................................ 14
7.1
Certificates ...................................................................................................................... 14
7.1.1
End Entity Certificates.............................................................................................. 14
7.1.2
Certifying Authorized Responders ........................................................................... 14
7.2
Certificate Revocation Lists............................................................................................. 15
7.2.1
Delta CRLs ............................................................................................................... 15
7.2.2
CRL Latency ............................................................................................................ 16
8 OCSP Service Architecture .................................................................................................... 16
8.1
Service Organization ....................................................................................................... 16
8.1.1
OCSP Client ............................................................................................................. 16
8.1.2
Caching Responder ................................................................................................. 16
8.1.3
Site or Organizational Responders .......................................................................... 16
8.1.4
CA Related Responders (Authorized Responders) ................................................. 17
8.1.5
Clearinghouse – High Level Responders ................................................................ 17
8.1.6
OCSP High Level Responders ................................................................................ 17
8.2
Service Components ....................................................................................................... 17
8.2.1
Authorized Responders ........................................................................................... 19
8.2.2
Trusted Responders and Transponders .................................................................. 19
8.2.3
OCSP Clients ........................................................................................................... 19
9 Security Considerations ......................................................................................................... 19
10
Other Considerations .......................................................................................................... 19
11
Author Information .............................................................................................................. 20
12
Glossary .............................................................................................................................. 20
13
Intellectual Property Statement........................................................................................... 21
14
Full Copyright Notice .......................................................................................................... 21
15
References.......................................................................................................................... 21
16
Revision History .................................................................................................................. 23
helm@es.net
2
GWD-I
1
2
3
4
5
6
7
8
9
March 2016
17
Note for next revision .......................................................................................................... 23
17.1
06-06............................................................................................................................ 23
17.2
06-05............................................................................................................................ 24
17.3
06-04............................................................................................................................ 24
Appendix A
OCSP Responder Examples ................................................................................ 24
A.1
Simple Client – Server Example ..................................................................................... 24
A.2
Grid Application Interaction with Site OCSP Responder ................................................ 25
A.3
MyProxy Example ........................................................................................................... 25
helm@es.net
3
GWD-I
March 2016
1
2
1
Introduction
3
4
5
6
7
8
9
10
11
12
13
Grids use X.509 [X509] certificates for authentication and as a basis for authorization. A reliable,
secure Grid infrastructure depends on the integrity and validity of these certificates. While X.509
certificates have built-in lifetimes, this is not adequate to deal with every aspect of certificate life
cycle and management. Certificates can be lost by their owners, can be “compromised”, or the
justification for holding the certificate may no longer apply. These certificates need to be revoked
before the certificate expiration date is reached. Distribution of certificate revocation lists (CRLs)
supports this need. CRL distribution and maintenance in the Grid has proven difficult for practical
reasons. The Online Certificate Status Protocol (OCSP) provides a simple query protocol for
clients to perform revocation check lookups on certificates, without the need to maintain up-todate sets of CRLs from a number of different certification authorities, at each and every computer
that is part of the Grid.
14
15
OCSP is a product of the IETF PKIX working group, and the current version is described in
[RFC2560].
16
2
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
The evolution of security concerns in Grids provides a number of scenarios for OCSP usage.
The increasingly large number of Grid CAs, and the attendant need for every end point in every
Grid PKI to manage a relationship with each CA in order to obtain revocation information,
presents a scaling problem for designers and an implementation problem for security and system
administrators. A comprehensive design with careful use of OCSP responders can address this
problem.
Various security-related “blacklisting” use cases might employ OCSP (or a combination of OCSP
and other techniques). For instance, an OCSP responder, providing status information to relying
parties for a given site, could return a REVOKED status for a single unwanted user, or all
certificates with a given quality or characteristic. This might be useful in controlling access during
an on-going security incident. Or, the OCSP responder could apply policy rules such as tests
against key size, key usage, or other qualities, and prevent inappropriate use of certificates.
These tests are difficult to deploy in current clients.
Grids make extensive use of proxy certificates (see section 6). While intended originally to be
non-revocable, their usage scenarios have evolved considerably over the years, and some
revocation capability might be useful. Selective proxy certificates might be revoked as part of a
security response. Proxy revocation may be part of a more general authorization certificate
management service. Completed jobs might revoke still valid but unneeded proxy certificates.
35
36
37
While OCSP has been around as a standard for several years, support for it in open source
software stacks is emerging only now. While the list below is in no way meant to be complete, it
highlights issues to consider before deploying OCSP services in a Grid.
Practical Considerations and Expectations
38
39
40
41
42
43

Generators/processors for creating and validating OCSP messages can be found in
recent versions of OpenSSL [OPENSSL] and BouncyCastle [BCASTLE], both commonly
used crypto providers in the open-source market. In both cases, however, a couple of
lines of code is necessary to enable OCSP as part of the certificate validation (registering
the necessary callbacks). Sun’s Java 2 Platform Standard Edition (J2SE) 5.0 [J2SE5]
also supports OCSP.
44
45

Built-in support for OCSP can be found in the Mozilla-based series of browsers
[MOZILLA], e.g. Netscape and Firefox.
46
47
48
49

OCSP is supported in Windows by way of third-party revocation provider plug-ins to the
Windows CryptoAPI, which offers cryptographic operations for most Microsoft products
(including browsers and email clients). Several such plug-ins exist in the commercial
marketplace.
helm@es.net
4
GWD-I
March 2016
1
2

Grid PKIs distribute their revocation information in several ways, usually in CRLs
accessible via HTTP, some provide LDAP access to CRLs and/or even OCSP.
3
4

Due to the distributed nature of Grids, any supporting OCSP service should be fault
tolerant, efficient, and resilient under load.
5
3
Protocol Overview
6
In this section, we provide an overview of the OCSP protocol and its different modes of operation.
7
3.1
OCSP Characteristics
8
9
10
11
12
13
14
OCSP is a simple query protocol based on a client-server model. A “client” can be any
application, service, or device needing to validate X.509 certificates; we prefer to use the term
“relying party” for clarity, but both “relying party” and “OCSP client” are used below
interchangeably. The “server” is the OCSP responder. The relying party packages up one or
more X.509 certificates, and sends them to the OCSP responder. The OCSP responder
evaluates the status of the certificates, and for each one returns to the relying party one of three
values: Good, Revoked, or Unknown.
15
The “issuer” is the certification authority that signed the issued X.509 certificate.
16
17
In OCSP, a relying party (the client) identifies the location of an OCSP responder (the server) in
one of two ways:
18
19
1. Local configuration: a table associating issuers (distinguished name, or hash of the public
key) with one or many URLs of OCSP responders to contact.
20
21
22
2. Self-described: the URL(s) of the OCSP responder(s) knowing the status of a
subscriber’s certificate is specified in the certificate itself, as an AuthorityInfoAccess (AIA)
certificate extension.
23
24
25
26
27
28
We note that RFC2560 is underspecified in the case that multiple responder URLs are specified
in an AIA extension; The relying party could query one responder at a time from the list, and stop
after a Good or Revoked status has been returned; it could query several of the responders and
verify that all or a majority of them report Good; it could contact the responders in the same
sequence as specified in the AIA extension (primary/secondary/…), or simply query one of them
at random.
29
30
31
32
33
34
35
36
37
38
39
The relying party sends an OCSP request message to the identified OCSP responder, normally
carried over HTTP or HTTPS using HTTP POST1 operations. The request identifies one or
several certificates, identified by issuer name (hashed), issuer key (hashed), certificate serial
number, and possible AIA information. The request may be signed (mainly intended for
authorization and billing purposes), in which case the signing certificate is attached. In addition,
the request may also contain a “nonce”, a random sequence of bytes that renders the request
unique. While OCSP supports packaging of multiple certificates in a single query request, it is
rarely used in practice or even supported in common off-the-shelf implementations. A multiple
certificate query may be a useful technique for dealing with End Entity and Proxy Certificate path
validation, where more than one certificate status must be retrieved from the same OCSP
responder.
40
41
42
43
The OCSP responder in turn provides a signed response that contains the timestamp of the
signature and current status of the certificate(s) identified in the request. Any nonce is copied ad
verbatim to the request. The responder typically also includes its signing certificate, and
certification path.
1
HTTP GET is supported as well but not as common and only suitable for trivial use of OCSP
due to the message size limitation.
helm@es.net
5
GWD-I
March 2016
1
2
3
4
5
6
The possible certificate status codes returned by the OCSP responder are Good, Revoked, and
Unknown. The precise semantics of these status codes are important: Good indicates that as far
as the responder can tell, the certificate is not revoked or suspended. The Unknown state
indicates that the responder is unable to answer the request for some reason: it might not know of
the CA that issued the certificate, a local copy of the revocation information database is not up-todate, and so on.
7
8
In case of an error, OCSP defines a set of common error codes, which are sent back to the
relying party unsigned.
9
The OCSP RFC specifies three cases for when a relying party may accept an OCSP response:
10
11
1. The response is signed by the CA that issued the subscriber certificate(s). This is
specified by the RFC, but is rarely used in practice.
12
13
14
2. The response is signed by an Authorized responder, with a direct delegated authority
from the CA. This delegation of authority is identified by inclusion of OCSPSigning in the
extendedKeyUsage extension of the responder’s signing certificate.
15
16
17
3. The response is signed by a Trusted responder, i.e. a responder explicitly trusted by the
relying party through local configuration. Relying parties must know about potential
Trusted responders ahead of time.
18
19
20
21
22
23
The Authorized responder, type two above, is the most typical OCSP configuration, and arguably
the most scalable and maintainable. The CA delegating this authority is directly responsible for
providing timely updates to the Authorized responder. The Trusted responder, type three above,
is one that may be particularly useful in scenarios requiring additional controls and capabilities, as
described in Section 8 below. Combinations of Authorized and Trusted responders will be
deployed in Grids.
24
25
26
27
28
The Authorized responder creates a circular dependency problem in that relying parties may wish
to know whether the responder certificate itself has been revoked or not, before accepting the
signature of the OCSP response2. To address this and other similar problems, a certificate can be
marked with the ocsp-nocheck extension, indicating to relying parties not to attempt to verify the
revocation status of the certificate (at least not using OCSP).
29
30
31
32
33
34
35
The ocsp-nocheck extension is typically combined with relatively short-lived certificates and close
supervision of the issuer. The use of hardware key protection can mitigate some, but not all, of
the concerns with the responder key-pair, since the fundamental question of its revocation is
being side-stepped. Ocsp-nocheck can also be used to mitigate anticipated load problems: for
instance, the TLS certificate of a popular (but low-risk) server may be stamped with the ocspnocheck extension (and necessary operational security improvements to mitigate the associated
risks) to eliminate OCSP queries otherwise triggered by all clients connecting to that server.
36
3.2
37
38
39
40
41
42
43
44
45
Certificate Revocation Lists (CRLs) are an essential component in the model of OCSP operation
we are describing; we need to explain some essential CRL features and terminology that will be
used throughout this document. CRLs are defined by the [X509] and [RFC3280] standards.
CRLs are usually associated with a particular CA (sometimes a subset of its certificates, and
sometimes a family of CAs). CRLs consist of lists of certificate serial numbers, revocation times,
and optional revocation reason codes, time and date information describing when the CRL was
issued, and when the next one will be issued, other parameters, and a digital signature from the
authorized CRL issuer. The authorized CRL issuer is usually the Certification Authority and
usually the CAs signing key signs the CRL.
Certificate Revocation Lists
2
Or, in the case of OCSP over HTTPS, the client wants to validate the TLS certificate of the
server hosting the OCSP responder, and whose revocation status can only be obtained by
connecting to the OCSP responder using TLS…
helm@es.net
6
GWD-I
1
2
3
4
5
6
7
8
9
March 2016
There are several kinds of CRLs. The Base, or Full, CRL, contains all the serial numbers of all
the revoked certificates in the CAs domain of operation. This is the only kind of CRL directly
usable in Grids today. Delta CRLs are incremental CRLs from a given Base CRL. A Delta CRL
is smaller than the base CRL and can be published, transmitted, and installed faster than a reissue of a large full CRL. An Indirect CRL is a variant in signer strategy (somewhat like Trusted
responder) applied to other types of CRL; it is a CRL produced by an authorized certificate other
than the CAs (see [RFC3280] 5.3.4 for a complete discussion of the technical details). Neither
Delta or Indirect CRLs are usable in current Grid software, but both may be used by OCSP
responders serving Grid customers.
10
11
12
13
14
15
16
17
18
19
Reason codes and their usage are largely outside the scope of this document. (Presumably, they
are described in certification practices documents, or other policy documents provided by CAs.)
However, one code needs to be discussed: certificateHold. certificateHold was provided in the
X.509 and RFC3280 with little guidance in how it was to be used. Grid applicability has been
suggested in a couple of use cases where temporary blacklisting is needed. We suggest, on an
experimental basis, the use of certificateHold to suspend a given certificate for a time; the
manager of the CRL may later decide to remove the certificateHold status, or change the
revocation status to another recognized revoked status. This constitutes a Grid-only usage. The
policies that govern how certificateHold status is applied or how its status is changed are outside
of the scope of this document.
20
21
22
23
24
25
26
27
28
Of all the reason codes, certificateHold appears to have the unique property of impermanence. It
can be applied to a certificate, and then withdrawn, unlike the other reason codes
(keyCompromise, &c), for which no such behavior could be considered reasonable. As a result,
on removal of certificateHold status, the prior CRLs become invalid. While CRL policy is outside
the scope of this document, it seems desirable to limit the certificateHold reason code to OCSP
usage, or limit its appearance to Delta CRLs if possible (see the Delta CRL usage strategy
below). This may not be possible in a scenario that requires blacklisting a certificate for use with
a legacy service unable to use OCSP, but such scenarios should take into account the possibility
of stale CRLs.
29
We will address other complications that result from certificateHold in later sections.
30
3.3
31
32
33
Latency is inherent in network transactions, and revocation has a built in quality of uncertainty:
Given an answer of Good, the client knows the certificate was Good the last time somebody
created a CRL. But will the certificate still be good the next time the CRL is updated?
34
35
36
37
38
39
For trust evaluation purposes, the responder may want to quantify an upper bound and/or
approximation of the current latency, and convey that to the relying party. To date, there is no
well-defined technical means of augmenting an OCSP response with such “cautionary period”
information, to borrow language from Appendix B in [RFC3125]. Specifying such an OCSP
response extension is out of scope for this document. It may be necessary to characterize this
problem further in a local policy document.
40
41
OCSP currently can provide three timestamps characterizing the revocation response. (See
[RFC2560], section 2.4.) These are:
42
43
44
45
46
47
48
49
50
51
52
OCSP Latency and Cautionary Period


thisUpdate: The time at which the status being indicated is known to be correct
nextUpdate: The time at or before which newer information will be available about the
status of the certificate. If nextUpdate is not set, the responder is indicating that newer
revocation information is available all the time. Whenever such field is set, it is an
indicator that the revocation information has been retrieved from a CRL being released
only at certain intervals of time. In certain cases, such interval may be quite large - even
in the order of days These two are from the underlying CRL timestamps. The bigger the difference between both of
them, the longer the maximum cautionary period of the OCSP Response may become.
A third timestamp from the OCSP Response could be useful for relying parties to determine a
“cautionary period”:
helm@es.net
7
GWD-I
March 2016
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 producedAt: The time at which the OCSP responder signed this response.
It should be noted that an OCSP server producing pre-signed responses (which fixes a
producedAt date for that response) has the potential to make client interpretation of the
cautionary period particularly difficult, and this is exacerbated the management of Delta CRL
updates. To solve this problem relying parties would like to take into account the time at which
the OCSP Response is being received (receivedAt); in such cases, the cautionary period should
be computed as the interval:
[thisUpdate, receivedAt]
The longer such cautionary period interval is, the less precision resulted in the OCSP response
being provided. Such precision factor is an indicator of the level of risk that the relying party is
willing to take when accepting the result status coming from an OCSP Response as is. The
relying party's policy SHOULD take into account such precision factor before accepting or
rejecting the response.
Finally, it is also interesting to note the interval:
[receivedAt, nextUpdate]
which may be very so short that the relying party may decide to i) discard the response and ii)
contact again the OCSP Responder as soon as the new revocation information has been
generated.
A good certificate may have a pre-signed OCSP response that is very old, and not meet client
freshness expectations. It is not yet clear how this should be interpreted, what requirements
Grids have in this area, and it may yet be clarified by additional work in the IETF.
22
4
23
24
For OCSP to be used in multi-organizational Grid environments, support for it MUST be
integrated in any path validation software used according to the following recommendations.
25
4.1
26
27
OCSP clients MUST be able to send OCSP requests over HTTP or HTTPS. This may affect the
network and firewall policies of a site.
28
4.2
29
30
31
32
33
34
35
36
In some scenarios, CRLs provide better a better means of processing revocation than OCSP; for
instance, in offline environments, or in the case of a server validating many different client
certificates, it is better from a performance point of view to have all revocation information cached
locally. In other scenarios, CRLs may be used as a backup source of revocation information in
case the OCSP service fails, e. g. due to temporary network outage. As OCSP is deployed, and
becomes a production service in Grids, not all CAs will be capable of providing Authorized
responder service immediately. Relying parties and security managers will see a gradual
transition from CRL to OCSP as the primary source of revocation information.
37
38
39
In light of the issues listed above, clients MUST be capable of handling both CRLs and OCSP,
and it MUST be a configurable option which source of revocation to prefer and which to use as a
backup, on a per-issuer basis.
40
4.3
41
42
43
44
45
46
47
It is often the case that an application interacts with some other system component on a frequent
basis. Instead of each interaction triggering a new OCSP request, causing unnecessary load and
system latency, caching of responses SHOULD be allowed and MAY be supported by the client
software. Client-side caching is recommended to reduce the number of queries made to the
OCSP infrastructure, thus optimizing available resources (also consider that some OCSP
providers sell their service on a per-request basis). In general we note that while OCSP
responses reporting a permanently revoked certificate status 3 can be cached indefinitely, it MUST
OCSP Relying Party Requirements
Network Requirements
Revocation Source Requirements
Caching OCSP Responses
3
The OCSP Revoked status does not necessarily mean a permanently revoked certificate. It may
also be on hold (suspended) – known as certificateHold in [X509], section 8.5.2.2.
helm@es.net
8
GWD-I
March 2016
1
2
3
4
be possible to configure the maximum size and lifetime/freshness of the entries in an OCSP
response cache (for a client-side cache it is advisable to use the Cautionary Period parameter as
defined in 3.3); this is especially important when dealing with suspended certificates
(“certificateHold”)
5
6
It may be more useful in general to provide a busy application a local caching-only OCSP
responder as described in Section 8 below.
7
4.4
Responder Discovery
8
9
10
11
At a minimum, the OCSP MUST be able to locate the OCSP responder using the methods
specified in Section 3. Local configuration MUST have precedence over any service locator
information located in the certificate’s AIA extension. A default responder for “all other” issuers
SHOULD be configurable as well.
12
13
14
15
To allow for high-availability and load balancing, it SHOULD be possible to associate each issuer
name with more than one responder URL. When the OCSP client is provided with more than one
responder URL, it SHOULD try querying one responder at a time from the list until a Good or
Revoked status is retrieved, or until the list of available responders is exhausted.
16
17
18
19
20
21
22
23
24
DNS SRV [RFC2782] might provide an attractive low-level “configuration free” method for an
OCSP client application to discover a local Trusted responder. However, OCSP and DNS SRV
are poorly suited to one another at this time. OCSP responders use HTTP and HTTPS as
transport protocol, and might be confused with other HTTP resources in DNS SRV. Therefore, in
order to use DNS SRV, the following would be needed: (1) Define _ocsp as the symbolic service
name (problematic because of http); (2) Define a URL naming convention for OCSP responders
in clients. This convention might be “append the string /ocsp to the host:port construct”, so that
the client builds a string http://somehost.example.com:8080/ocsp from an _ocsp lookup in the
example.com domain, that returns the above A record and port.
25
26
27
28
More practical discovery methods are available in more recent Globus middleware incorporating
Web services, such as WS-Resources [WSREF]. We RECOMMEND a standardized OCSP
discovery interface be developed and provided in Grid middleware distributions (we are not aware
of any interface yet available in Web services).
29
4.5
30
31
32
A nonce is used to bind a specific query to a specific response, preventing replay attacks (see
[RFC2560], section 4.4.1). In practice it has been used to force an OCSP responder to issue a
fresh response.
33
34
Large-scale OCSP responder implementations, such as the ones deployed by VeriSign,
continuously pre-produce OCSP responses in the background, for maximum throughput.
35
36
37
38
39
Pre-produced OCSP responses cannot be used to service nonced requests. Nonced requests
require a signed answer from the responder, including the transaction-unique nonce. Therefore,
for efficiency reasons, OCSP clients MAY decide not to make use of nonce in the requests. This
decision should balance efficiency, availability of dynamic information and replay attacks
prevention.
40
41
42
43
44
45
Forcing a fresh response at first glance seems like a good way for a relying party to insure an upto-date, real-time validation check. However, OCSP does not specify responder behavior in
sufficient detail to guarantee this behavior; the nonce requires it to do additional work, including
an expensive digital signing that adds to the latency of the response. Nonce SHOULD NOT be
used in Grid configurations, except where circumstances and replay vulnerability are a particular
concern.
Nonce
helm@es.net
9
GWD-I
March 2016
1
4.6
AuthorityInfoAccess Extension
2
3
4
OCSP clients SHOULD include any information about an Authorized responder location (as
indicated by OCSP service locator URLs in the AIA extension of the subscriber certificate) in its
OCSP request.
5
4.7
Error Handling and the Unknown Status Code
6
7
8
9
10
11
12
13
14
15
16
17
18
OCSP clients will occasionally encounter errors from the client network stack, errors returned
from the OCSP responder, or the Unknown status code: in most cases, such a failure means “try
somewhere else” or “try later”, indicating to the client to probe other possible sources (including
other OCSP responders) for revocation information, possibly a bit later in time. In case the
resulting status after an exhausted search is still an error or status Unknown, the client SHOULD
interpret that as Revoked with revocationReason certificateHold (that is, a non-definite revocation
state), unless otherwise configured. If, after an exhaustive search of all available sources of
revocation information, the status of a certificate is still Unknown, the client will have to choose
between three unpalatable alternatives: interpret “network error or Unknown” as either Good, or
Revoked, or wait and start the whole search process over again. Revoked is the choice of most
security experts. In practice, this policy leads to unnecessary denial-of-service. Interpretation as
Good leads to worry and conflict with security policy. Proxy certificates can be expected to have
Unknown status in most cases (see Section 6, below).
19
20
21
22
In light of these issues, clients MUST be provided with a configuration option to allow local rules
and security policies to be applied in circumstances where revocation status is undetermined. An
example of such rules is provided in Appendix XX, which is taken from the Grid Validation Policy
implemented by the Open GRid Ocsp API [OGRO].
23
24
Clients MUST NOT interpret Unknown as Revoked when evaluating proxy certificates, unless
their OCSP Responder implements a Proxy Certificate Revocation mechanism.
25
26
27
28
29
30
The relying party SHOULD perform additional checks before accepting an OCSP response; these
include: verifying the nonce returned against the nonce sent (if a nonce was used), validating the
response signature (notice the use of the ocsp-nocheck extension – see Section 3 above) and
verifying the freshness of the OCSP response (checking that OCSP response’s producedAt
timestamp is within the allowed lifetime or cautionary period – this is especially important in the
case of cached or preproduced responses)..
31
4.8
32
33
34
35
The relying party MAY choose to sign the OCSP Request, in which case performance and
security implications must be considered. In Section 10 we recommend using an OCSP
configuration file that may include rules relating to OCSP Request signatures (see also Appendix
XXX for a related example).
36
5
37
38
39
40
Our experience with OCSP servers has been with commercial products with considerable
capabilities (and in some cases, considerable limitations). A server based on open-source
software such as OpenSSL or a Java implementation is being developed in tandem with this
requirements definition, to better understand the issues at hand.
41
5.1
42
43
44
Most OCSP responder implementations easily handle up to ~100 requests per second on a
commodity desktop workstation4. Use of cryptographic hardware may accelerate that further, and
also provide additional protection of the signature keys.
4
OCSP Request Signing.
OCSP Responder Requirements
Performance, Key Protection
Personal communication between the authors – based on experiment
helm@es.net
10
GWD-I
March 2016
1
2
3
4
The OCSP signing key is the second-most important key in a PKI (some consider it to be the
most important), since it is used to assert the current status of an issued certificate. Moreover, by
its very nature, OCSP responders are exposed to network connectivity, while the corresponding
CA issuing keys often are not.
5
6
While we do not require the use of hardware protection, we RECOMMEND that the security of the
OCSP responder key be in parity with the CA issuing key.
7
5.2
Responder Certificate
8
9
10
11
An OCSP responder implementation MUST support live updates of the responder signature key
material. (Use case: short-lived certificates signed with the ocsp-nocheck extension – see Section
3 above). Because of the sensitivity of relying parties to network errors, service outages and
disruptions to responses MUST be avoided.
12
13
14
15
Authorized Responder scenarios MAY be implemented by enabling the responder to employ
multiple signing certificates simultaneously, but with the same key pair: one for each issuer for
which the responder provides revocation information. (Use case: an Authorized responder
servicing more than one CA.) This configuration is expected in Grids.
16
5.3
17
18
19
20
21
22
23
24
An OCSP responder must consider several sources and formats of revocation information. These
include CRLs, databases, revoked proxy certificate records, and simple files (blacklisted users or
Grid services); it may also include several retrieving protocols (i.e. LDAP, HTTP, HTTPS, FTP,
etc.). The sources must be secure and trustable sources of information. Disclosure of access
controls and roles for such services is expected as part of the policy disclosure for OCSP
services. It is expected that revocation or blacklisting events in such services will be
authenticated, authorized, and logged with the same care and detail expected in CRL update
operations in Certification Authorities.
25
26
27
28
29
Information on revocation from CRL and non-CRL information sources must be made available to
the OCSP responder in a timely and reliable way. Errors from external services must be avoided,
and when this is not possible, they must be carefully logged, and in some cases they may need to
trigger alarms. A suppressed error from a failed local blacklist service might inadvertently permit
a security breach.
30
31
32
33
34
35
Non-CRL databases such as blacklists MUST provide revocation information in accordance with
OCSP [RFC2560] expectations and requirements. In particular, these databases MUST include
a thisUpdate attribute value assertion; SHOULD include a nextUpdate assertion (except for proxy
certificates, see section 6.3 below); and SHOULD provide the equivalent to CRL Entry
Extensions (also known as CRL reason codes) as defined in [RFC3280]. This is necessary in
order to provide a uniform presentation to the relying party.
36
37
38
OCSP Responders SHOULD support Delta CRLs (particularly when operated in one of the
Trusted Responder configurations). If for any reason a Delta CRL does not arrive on time, then
the last good known CRL update should be considered.
39
5.4
40
41
42
43
44
45
46
47
48
While not part of the OCSP standard, it is common in real-world deployments that an OCSP
responder act in Transponder mode, that is it will act as a proxy/gateway, and forward any client
requests as-is to other, more authoritative, responders, and likewise transparently forward the
response back without re-signing the response with its own key. Transponder mode is useful for
organizations that want to control the outbound OCSP traffic originating from within their own
administrative domain(s). When combined with an OCSP response cache, a local responder in
Transponder mode can be useful to cut response latencies, reduce network traffic, and minimize
load on external responders. In addition, responder in Transponder mode can be used for load
balancing, to route the OCSP request according to specified parameters (i.e. OCSP load, network
Revocation Information Sources
Transponder Mode
helm@es.net
11
GWD-I
March 2016
1
2
traffic, availability, etc.), or as a central “redirector”, thus consolidating configuration and
management issues.
3
6
4
5
Grids make extensive use of proxy certificates, both in format based on the IETF PKIX standard
[RFC3820], and in various formats predating this RFC.
6
6.1
7
8
9
10
Proxy Certificates and OCSP Proxy Responders
Proxy Certificate Characteristics
Proxy certificates are used by Grid users (and sometimes by services) to delegate rights from the
user (or service) to another service, so that service can effectively act with the rights or identity of
that user. Other important features of Proxy certificates are explained next (see [RFC3820] for a
more complete discussion):
11
12
13

Proxy certificates were designed to eliminate the need to make insecure and unprotected
copies of a user’s personal credentials for use by autonomous processes, across
different domain boundaries.
14
15
16
17

They are typically created “on the spot” by a Grid user in order to prevent movement of a
private key across domain boundaries; a key pair is generated by a remote site or
different application, and the Grid user uses his personal certificate (an X.509 end entity
certificate) to sign the proxy public key.
18

Can also create subordinate proxies in the same fashion.
19
20
21

Proxy certificates are typically stored in local file-based “softwarecrypto stores”, with file
security protection based on local user file system rights, and unsecured private keys (no
password protection).
22
23
24

Are usually intended to be used in a particular place, for a particular action, but they are
file-based and are very similar to the user’s end entity certificate – they are also portable,
whether intended to be or not.
25
26

Often carry attributes, access control information, and other delegated rights payload, but
enforcement of these restrictions is typically the responsibility of the receiving application.
27
28
29
30
31
32

Proxy certificates were designed to be “short term” certificates, with validity times
measured in a few minutes or hours, but deployments vary and many long running jobs
need either very long-lived proxies or the right to continually renew proxies as needed.
In general, however, once an application uses a proxy, the application can run forever,
there is little operating system or Grid job management support for the idea of rechecking
the lifetime validity of a proxy certificate once a job is underway.
33
6.2
34
35
36
Proxy certificates were intended to be short term certificates, and for the most part that has
remained true. But as noted there are use cases where proxy certificates can have long lifetimes,
or where proxy certificates can be created for future use in batch queues.
37
38
Security and system administrators have discussed a number of scenarios where revocation of
proxy certificates might be useful:
39
40
41
42
43
44
Proxy Certificate Revocation

A long-running job, that in turn creates many jobs on other domains (perhaps a file fetchanalysis-report process, gathering data from many sources), needs to be cancelled. Its
results are not good, it exceeds resource limits, or other problems identified by the job
owner or the resource manager warrant termination. Part of job clean-up and recovery
would include revoking proxy certificates in use to prevent orphaned processes from
running across domain boundaries.
helm@es.net
12
GWD-I
March 2016
1
2
3

A system that is used as one component of a complex job is compromised. Instead of
aborting the whole job, and losing all the results, only the components affected by the
compromised system are stopped.
4
5
6

A resource owner does not want a particular process to be run by a particular right now.
Rather than blacklisting the user or damaging the application, the resource owner can
blacklist the proxy certificate.
7
8

A busy system is compromised, and large numbers of proxy certificates that could have
been captured by the hacker for use here or elsewhere need to be revoked.
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
From the point of view of local management of proxy revocation, a local or VO-based OCSP
responder (see below) is ideal for management of proxy revocation. The proxy certificate, if
known, MAY be registered in the local responder’s database, with appropriate revocation status
(based on X.509 CRL Revocation reason codes). Local administrators and users MUST have
permission to make these revocations. In particular, the user’s end entity certificate SHOULD
always have permission to revoke any and all of his own proxy certificates. In this way a local
fine-grained blacklist service, based on proxy certificate revocation, can be built on top of a local
OCSP Trusted Responder. Resource owners may be able to revoke authorization attributes, and
identity providers (or other stakeholders) may be able to revoke authentication credentials (the
proxy certificate itself). The end entity certificate holder (or a sub task) can manage submitted
jobs by revoking subordinate proxy certificates. The more general problem involves
communication of proxy revocation information to other domains. Since proxies are typically
used to cross domain boundaries – including boundaries into other resource domains, or other
VO’s – these other domains will either need access to local revocation information, or will miss
out on important revocation information. Direct communication across domain boundaries is
likely to be impractical.
25
26
27
28
29
30
31
32
33
34
In order to make proxy revocation generally useful across the Grid, we recommend that
conforming CAs add a proxy revocation registry capability to their CA-associated OCSP
responder. This would allow even a minimally-configured OCSP client, reading and using the
locator information in the end entity certificate, to find a proxy revocation. A similar registry
capability could be added to “clearinghouse” or well-known OCSP responders. In addition to
authorizing the end entity certificate holder to register proxy revocations, OCSP responders MAY
also provide the capability for other authorized parties to register revoked proxy certificates. The
possibility of abuse or unnecessary denial of service raised by such a capability must be carefully
addressed. The ability to control proxy use more directly may help address security needs and
reduce affects of the typical security incident response.
35
36
37
38
39
40
41
42
43
44
45
In addition, consideration should be given to careful logging any notification associated with proxy
revocation, whether the revocation occurs locally, or is published to a CA-related responder or
clearinghouse. The end-entity certificate holder should be notified as rapidly as possible. This in
turn indirectly supports the suggestion that proxy revocations be published to the end-entity’s CArelated responder, which should have complete contact information for the end user. In addition,
it suggests that CAs should provide some direct contact information in end-entity certificates.
Many, but not all, provide email addresses in the form of RFC822names in certificate
subjectaltname extensions. Revocation decisions performed by the relying party system
administrator must be logged with time, reason, and revoker identity information. All proxy
revocation registrations MUST be completely logged with the same attention and security
accorded to revocations managed by a certification authority.
46
6.3
47
48
49
OCSP clients MUST be able to submit the entire chain of certificates, including all proxies, to
OCSP responders for evaluation. We recommend that full chain validation be used; if not, the
OCSP responder may become overloaded with the proxy path validation process.
50
51
We can expect most proxy certificates will never be registered anywhere. OCSP responders
could be expected to return “Unknown” for the status of most such proxies. Thus
Requirements for Proxy Certificate Revocation Services
helm@es.net
13
GWD-I
March 2016
1
2
recommendations stated in section 4.7 for managing such status MUST be followed by relying
parties.
3
4
5
6
The nextUpdate field has no real meaning for proxy certificate revocation. It is possible that
some services or configurations (such as MyProxy or a delegation service) may be capable of
doing this, but there is no evident requirement. We recommend nextUpdate be set to 0 for
queries about proxy certificates.
7
We RECOMMEND the development of two alternative approaches to OCSP Proxy responders:
8
6.3.1
9
[David – Olle’s proposal about delegated responder cert to ocsp resp – need text]
OCSP Authorized Proxy Cert Responder
10
6.3.2
OCSP Trusted Proxy Cert Responder
11
12
13
14
15
16
17
18
19
20
21
Conforming CAs MUST [?] stamp end entity certificates with OCSP locator information (AIA
reference above). We propose that this be the basis of a proxy revocation registry. OCSP
provides no standard support for submission of data, so this service requires its own secure
protocol. Conforming CAs SHOULD provide this interface, and a database similar to that in use
in local OCSP responders for user and proxy blacklisting. If this proxy revocation interface is
provided, users MUST be allowed to register revoked proxies. CAs SHOULD allow
authenticated access by authorized VO administrators to register proxy revocations. We
recognize the inherent difficulties in these recommendations; the details of such an experimental
protocol are outside the scope of this document. We RECOMMEND that subordinate proxy
certificates inherit the locator information of their issuer, in order to maintain a tie to the CA of
origin. Note that also an OCSP configuration file for the relying party could specify such rules.
22
6.4
23
24
25
26
The MyProxy certificate store [GFD54, MYPROXY] has emerged as an important alternative
crypto store and certificate management tool in Grids. Evolving from a personal service to aid
access to web-based Grid portals, to a departmental solution, MyProxy is now deployed as an
enterprise and virtual organization Grid credential management system.
27
28
29
30
31
32
A typical usage scenario for MyProxy has a Grid user delegating a proxy certificate to the
MyProxy server, authenticating once with his long-term Grid credential. Access to applications
and other delegations in Grid jobs then take place with the MyProxy credential store serving as
intermediary. This may include the capability to create additional proxy delegations, renew proxy
certificates for some period, and other capabilities. Another scenario requires MyProxy and a
certification authority to cooperate in management of the user’s long-term credential.
33
34
35
36
37
38
We RECOMMEND that conforming MyProxy servers stand up an OCSP responder associated
with the credential store. If such a responder is available, the MyProxy store MUST stamp proxy
certificates created with this store with this responder. The responder database MUST conform
to local database requirements expressed [somewhere], and MUST be capable of dealing with
multi-certificate queries. Both the user and the authorized OCSP administrator MUST have
permission to register proxy revocations.
39
7
40
41
7.1
Certificates
7.1.1 End Entity Certificates
42
43
44
45
46
The service locator (URL) of the appropiate OCSP responder MUST be included in all certificates
issued by all CAs. The service locator is encoded in an AuthorityInfoAccess certificate extension,
as specified in [RFC2560]. Note however that the proof of authority is indicated by information in
the responder’s signing certificate: no such conclusions can be drawn from the fact that a
responder’s URL is encoded in a certificate.
47
7.1.2
48
49
A CAs Authorized responder SHOULD be issued a certificate with the ocsp-nocheck extension as
well as OCSPSigning in the extendedKeyUsage extension, as described in [RFC2560]. Direct
MyProxy Certificate Store
Certificate Authority Requirements
Certifying Authorized Responders
helm@es.net
14
GWD-I
March 2016
1
2
3
4
5
use of the CAs private key for OCSP response signing is not recommended. As a result, the
Authorized responder certificate is not subject to revocation check through OCSP. In order to
reduce the risk associated with the responder certificate, it is suggested that the Authorized
responder certificate have a very short lifetime. (It is expected that policy documents will address
the specific validity lifetime limits.)
6
7
8
9
10
11
12
13
14
15
Current CA practice in Grid PKIs suggests that Authorized responders will be difficult for many
CA providers to operate. Many Grid CAs are offline services, run on an as-needed basis
(perhaps once a day to produce a CRL). Very short lived certificates, with lifetimes in minutes,
and an always-available OCSP server, may be quite difficult for some CA providers to deploy. In
the case of an infrequently-operated offline CA, we recommend that the CA produce a large
number of signed OCSP certificates, whose key pairs are securely managed, in order to cover
the gap in time between CA operation. This is an ideal scenario for secure key storage devices.
CA providers who cannot easily operate an OCSP responder service with practically zero
downtime can sign an OCSP responder certificate for another OCSP responder, with the
desirable reliability characteristics.
16
7.2
17
18
19
It is recommended that CRLs be type CRLv2, in order that revocation reason codes can be made
available for use in OCSP responses. The use and management of these reason codes is
outside the scope of this document.
20
21
22
If a CA provides or supports OCSP services (such as providing an OCSP locator reference in end
entity certificates), the CA MUST continue to provide at least a full CRL at regular intervals, in
order to provide OCSP clients a reasonable fallback strategy.
23
7.2.1
24
25
26
CAs SHOULD provide Delta CRLs (see [RFC3280], section 5, for a full discussion of CRL
issues). Delta CRLs provide two benefits that can greatly enhance the quality of an OCSP
service.
27
28
29
30
The smaller size of a delta CRL reduces the network load, and the amount of processing time
required by the OCSP responder to integrate the new revocation information into an existing
database. Both of these features, while relatively unimportant in current Grid PKIs, will improve
the responsiveness and minimize latency in Grid deployed OCSP responders.
31
32
33
34
Delta CRLs can also greatly enhance the timeliness of revocation information based on CRLs.
Delta CRLs come with their own nextUpdate field. OCSP responders capable of managing Delta
CRLs will be able to assemble a new effective CRL, and report a new effective nextUpdate from
information provided in the Delta CRL.
Certificate Revocation Lists
Delta CRLs
Base CRL
t0
All
consumers
Δ CRL
t1
OCSP
Responder
Δ CRL
t2
OCSP
Responder
Δ CRL
t3
OCSP
Responder
Δ CRL
t4
OCSP
Responder
Δ CRL
t5
OCSP
Responder
Base CRL
t6
All
consumers
Table 1 Full and Base CRL Issuance
35
36
37
38
39
40
41
42
43
A CA capable of producing Delta CRLs can adopt a strategy similar to that shown in Table 1.
1. Issue a Full CRL at time t0, with nextUpdate time t6.
2. Post the Full CRL to all relying parties (including non-OCSP capable services).
3. The Full CRL becomes a Base CRL when used with Delta CRLs. Issue a Delta CRL at
time t1 with a nextUpdate time t2. Time t1 should be immediately after t0, to minimize large
swings in the clients’ view of the confidence window. The OCSP responder will now be
able to report t2 as the nextUpdate time in query responses.
4. Issue new Delta CRLs as shown.
5. At time t6, reissue a Base/Full CRL and restart the sequence.
44
45
The number of intervals shown is purely illustrative; given Grid CRL intervals it is expected the
frequency and number of Delta CRLs could be very large. In Grid PKIs today, CRLs are issued
helm@es.net
15
GWD-I
March 2016
1
2
3
4
5
6
7
with fairly large nextUpdate periods – 15 – 30 days are not uncommon. This is extraordinary, but
the client “pull” CRL distribution model in use in Grids is subject to various failure modes and
errors. If a new CRL does not appear before the old one’s nextUpdate time is exceeded, openssl
invalidates all certificates related to this CA. A nextUpdate field set far in the future allows
sufficient time for most temporary network or host problems to be resolved before Grid end users
are affected. This resolution of the problem does not meet current security requirements very
well (see also the recommendation for defining a cautionary period in section 3.2)
8
9
Delta CRL-like mechanisms using this client “push” model could be easily implemented even on
CA software not supporting [RFC3280].
10
11
12
Careful production of delta CRLs and base CRLs will provide better quality, lower latency
revocation information to OCSP responders (and sophisticated clients), while shielding legacy
CRL users and lightweight clients from the additional complexity.
13
7.2.2
14
15
16
17
18
19
In order to minimize latency affects and provide the most current information possible to OCSP
clients, it is recommended that CAs push (publish) CRL information immediately to clients as
soon as a revocation takes place. CAs of course will not know about the existence of every
responder in the world. OCSP Responders acting as Authorized responders for the CA should
be updated in this fashion. The CA should also develop a relationship with one or more
clearinghouse or large VO Trusted Responders, where possible.
20
8
21
22
23
24
OCSP responder deployments suitable for Grids can be viewed from client expectations about
the OCSP service, or from the OCSP RFC viewpoint. Let us consider common client viewpoints,
and how they might be interpreted in OCSP responder capabilities. This viewpoint is similar in
some respects to DNS.
25
26
8.1
Service Organization
8.1.1 OCSP Client
27
28
29
30
31
32
33
A client may keep a list of trusted OCSP Responders, provided to it through a configuration file, a
discovery service, or by other means. The client may cache responses for a given period,
perhaps to cover periods of offline operation or network outages. The client may discover OCSP
responders through AIA extensions in the certificate, and may also keep CRLs as a fallback.
The client SHOULD have a configuration capability sufficiently rich to enable it to take advantage
of the diversity of revocation information sources available, as well as implement appropriate Grid
and site policies. However, the client may have built-in patterns or search algorithms.
34
Caching Responder
35
36
37
38
39
40
An OCSP client might query a local, fast responding OCSP responder; this responder manages a
database of cached responses from previous queries; responses are cached based on lifetimes
supplied in those queries, perhaps with a pre-set time-to-live (i.e. computed from a cautionary
period). The expectation is that this responder is acting in Trusted mode. This responder MUST
be configured with a default service locator (superior responder). This responder may poll CAs
for CRL information, but this is not recommended.
41
OCSP responders that cache responses may pre-sign those responses for future use.
42
8.1.2
43
44
45
46
47
48
Local responders, or clients, may contact a site or Virtual Organization responder. This
responder will contain a full range of policy rules, path validation rules, and certificate validation
rules appropriate to the site or organization. This responder MAY be configured with one or more
default service locators. This responder SHOULD be acting in Trusted mode, but MAY act in
Transponder mode (see below). VO and Site responders SHOULD poll and retrieve CRL
information from CAs, if the CAs do not directly publish CRLs to these responders.
CRL Latency
OCSP Service Architecture
Site or Organizational Responders
helm@es.net
16
GWD-I
March 2016
1
8.1.3
CA Related Responders (Authorized Responders)
2
3
Clients or VO responders may contact CA-related responders. The expectation is that these are
CA Authorized responders (but see discussion below).
4
8.1.4
Clearinghouse – High Level Responders
5
6
7
8
9
10
11
12
13
14
Based on current operations, we RECOMMEND the emerging regional Grid PMAs and the IGTF
[IGTF] consider creating several well-known OCSP “clearing house” responders. Middleware
discovery software SHOULD look for these well-known responders when no other discovery
methods succeed. Since the operational and financial issues of such services are considerable,
the details must be determined elsewhere; but without such services the viability of revocation
services in Grids is in doubt. These clearing house responders will operate in Trusted mode. It is
expected that these clearinghouse responders will gather CRL information from every known CA
in use in Grid PKIs, and perhaps other PKIs. In order for such a service to be trustable by Grid
clients, signer certificates may have to be publicly and securely distributed in a fashion similar to
that provided for Grid CAs; or some other secure means might be used, such as Secure DNS.
15
8.1.5
16
17
18
19
20
21
22
23
OCSP responders must provide the best quality revocation information to their clients.
Responders, above the level of a local caching service, will have access to a variety of sources of
revocation information about each certificate. Responders acting as intermediaries must adjust
their search strategies on a case-by-case basis to provide the best quality information. For
example, some CAs may provide up-to-date information from their associated Authorized
responder, but only issue CRLs on a daily or weekly basis. Other sources may produce regular
CRLs and Delta CRL updates, but the associated responder provides old pre-signed responses
or doesn’t take into account Delta CRL updates.
24
8.2
OCSP High Level Responders
Service Components
25
helm@es.net
17
GWD-I
March 2016
1
2
3
4
Figure 1. An Overall OCSP Service Architecture
An overall OCSP service architecture suitable for Grids is depicted in Figure 1. It consists of four
classes of components:




5
6
7
8
Authorized OCSP responders
Trusted OCSP responders
OCSP Transponders
OCSP clients
9
10
All of the components may appear in multiple instances and should be configurable according to
the needs of their operators.
11
12
13
14
15
16
17
A typical site5 configuration includes at least two (for fault tolerance) Trusted responders,
configured to serve certificate status information for every CA accepted by the site, either by
downloading the appropriate CRLs, or by OCSP requests to an external responder whenever
such exists (indicated by local configuration or presence of a service locator URL in the incoming
OCSP request, in turn copied by the OCSP client from the subscriber certificate that is currently
being validated). In the latter case, the Trusted responders may act in transponder mode, and
CRL information may be used as a fallback source of revocation information (as indicated by #1).
18
19
20
21
22
As indicated by #2 in the figure, we foresee that “related CAs”, for instance subordinate CAs or
CAs that are part of a PMA, may join efforts and set up a shared Trusted responder that serves
requests on behalf of all of the CAs. (Note: That responder can be Authorized only if every
member of the PMA provides the responder with an OCSP signing certificate.) To alleviate the
need for complex configuration at each site, or allow for load balancing, an OCSP Transponder
5
With “site” we mean an organization or other administrative domain.
helm@es.net
18
GWD-I
March 2016
1
2
may act as a redirector for some CAs as indicated by #3. (Note that an OCSP Transponder does
not re-sign the response.)
3
8.2.1
4
5
6
Conforming CAs make use of Authorized responders to provide a primary source of certificate
status information. The CA is responsible for keeping the Authorized responder’s revocation
information updated at all times, as described in section 3.1.
7
8
9
The operator of an Authorized responder SHOULD ensure high availability of the OCSP service,
for instance by operating several responder independent instances6 or make use of fault-tolerant
or mirrored systems.
Authorized Responders
10
8.2.2
Trusted Responders and Transponders
11
12
13
Trusted responders are usually operated by sites or at an organizational level, to provide OCSP
service to local OCSP clients, thus centralizing the complexity of the OCSP/CRL configuration,
and minimizing the need for / providing means to control outgoing network connectivity.
14
15
Trusted responders SHOULD enable caching of OCSP responses, to reduce the load on the
Authorized responders (and themselves).
16
17
18
19
Trusted responders MAY operate in transponder mode, as described in Section 5.4. However,
this requires that the OCSP clients are configured to trust the responders whose OCSP
responses are forwarded to the client. (Rule of thumb: only act as transponder when contacting
an Authorized responder.)
20
8.2.3
21
22
23
24
25
26
27
28
29
30
31
32
It is RECOMMENDED that OCSP clients are configured to use the local Trusted responder(s) as
the primary source of certificate status information. In case the Trusted responders are
unavailable, an external responder may be requested directly, or a CRL may be obtained and
consulted, unless such actions would conflict with local site policy (outbound network
connectivity). OCSP Clients SHOULD NOT make use of nonce in their requests. Clients must be
provided with configuration capability (like in [OGRO]) sufficient to take advantage of the detail of
responder locator information available, and meet local security and reliability requirements. It
can be expected that some security software may impose some behavior or preclude others; for
instance, [JRSE5] provides a built-in CRL fallback strategy. Deployers and developers of
software for end users and for non-security applications need to be aware of these issues. It is
expected that deployers of security applications, acting as OCSP clients, will require flexible
access and complete control over revocation information.
33
9
34
Security considerations and OCSP threat model can be found in [RFC2560].
35
36
37
38
39
40
41
The use of OCSP must not degrade any current level of security enforced by way of operations
and policy. Rather, it is meant as a complement to the current authentication infrastructure,
primarily solving the deployment problem of CRL distribution. The services mentioned in this
document will be critical, and therefore utmost care needs to be taken before a wide-scale
deployment is to take place. For instance, use of publicly available, well-known, and scrutinized
source code, is recommended. Operations guidelines for CAs, OCSP responder administrators,
and the incident response teams, need to be carefully evaluated and (re-)written.
42
10
43
44
45
While OCSP as a technology has been around for several years, its existence and operational
implications if used is not reflected in many of the current existing CA certificate practice
statements or other operational policy documents of interest to a Grid. Special policies related to
OCSP Clients
Security Considerations
Other Considerations
6
Note: An high availability solution is ideally also network independent, i.e. the independent
responders should not be connected to the same network segment or network provider.
helm@es.net
19
GWD-I
March 2016
1
2
3
4
OCSP behavior as explained in this document may need to be written. Such policies may include
rules for dealing with OCSP requests and responses (i.e. required signatures, required
extensions, preferred OCSP responders, validation of OCSP response freshness, response
caching lifetimes, etc.).
5
6
7
Finally, service providers implementing OCSP architectures based on Grid Services features
such as discovery and notification should also be considered, as they may bring interesting
advantages to this field.
8
11
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Author Information
Olle Mulmo
NADA/KTH
SE-100 44 Stockholm
Sweden
email: mulmo@pdc.kth.se
Michael Helm
M/S 50A-3111
Lawrence Berkeley National Laboratory
1 Cyclotron Rd, Berkeley, CA 94720
USA
Email: helm@es.net
Jesus Luna
UPC/DAC
Jordi Girona 1-3
Barcelona 08065
Spain
Email: jluna@ac.upc.edu
Oscar Manso
CertiVeR S.L.
Diputación 238
Barcelona 08007
Spain
Email: o.manso@certiver.com
Milan Sova
ADDRESS TO BE FILLED IN
38
39
12
Glossary
40
41
42
43
44
45
46
47
48
49
50
AIA
Authorized responder
CA
CRL
Issuer
OCSP
PMA
Relying party
Responder
RFC
Trusted responder
helm@es.net
AuthorityInfoAccess (X.509 certificate extension)
A CA designated (“authorized”) OCSP responder
Certification Authority
Certificate Revocation List
Certification Authority (typically)
Online Certificate Status Protocol
Policy Management Authority
The “client” in an OCSP scenario
The “server” in an OCSP scenario
Request For Comment (IETF standards-track document)
An OCSP responder explicitly trusted by the relying party
20
GWD-I
March 2016
1
13
Intellectual Property Statement
2
3
4
5
6
7
8
9
The GGF takes no position regarding the validity or scope of any intellectual property or other
rights that might be claimed to pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights might or might not be
available; neither does it represent that it has made any effort to identify any such rights. Copies
of claims of rights made available for publication and any assurances of licenses to be made
available, or the result of an attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification can be obtained from the
GGF Secretariat.
10
11
12
The GGF invites any interested party to bring to its attention any copyrights, patents or patent
applications, or other proprietary rights which may cover technology that may be required to
practice this recommendation. Please address the information to the GGF Executive Director.
13
14
14
Copyright (C) Global Grid Forum (2016). All Rights Reserved.
15
16
17
18
19
20
21
22
23
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 GGF or other organizations, except as needed for the purpose of
developing Grid Recommendations in which case the procedures for copyrights defined in the
GGF Document process must be followed, or as required to translate it into languages other than
English.
24
25
The limited permissions granted above are perpetual and will not be revoked by the GGF or its
successors or assigns.
26
27
28
29
30
This document and the information contained herein is provided on an "AS IS" basis and THE
GLOBAL GRID FORUM 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."
31
15
32
[BCASTLE] “The Legion of the Bouncy Castle”, http://www.bouncycastle.org/.
33
34
[GFD54] J. Basney. MyProxy Protocol. Global Grid Forum Experimental Document GFD-E.54,
November 26, 2005.
35
36
[J2SE5] Java 2 Platform Standard Edition (J2SE),
http://java.sun.com/j2se/1.5.0/docs/guide/security/pki-tiger.html
37
[MYPROXY] “MyProxy Credential Management Service”. http://grid.ncsa.uiuc.edu/myproxy/.
38
[MOZILLA] “Mozilla Project”, http://www.mozilla.org/.
39
[OPENSSL] “OpenSSL Project”, http://www.openssl.org/.
40
41
[RFC2560] Myers et al, X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol – OCSP. RFC2560, IETF, June 1999.
42
43
[RFC2782] Gulbrandsen et al, X. A DNS RR for specifying the location of services
(DNS SRV), RFC2782, IETF, February 2000.
Full Copyright Notice
References
helm@es.net
21
GWD-I
March 2016
1
[RFC3125] Ross et al, Electronic Signature Policies. RFC3125, IETF, September 2001.
2
3
[RFC3280] Housley et al, Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile. RFC3280, IETF, April 2002.
4
5
[RFC3820] Tuecke et al, Internet X.509 Public Key Infrastructure Proxy Certificate Profile.
RFC3820, IETF, June 2004.
6
7
[X509] ITU-T Recommendation X.509 | ISE/IET 9594-8 Information Technology – Open Systems
Interconnections – The Directory Public-Key and Attribute Certificate Frameworks, ITU, 2003
8
9
[WSREF] “OASIS Web Services Resource Framework (WSRF) TC”, http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wsrf
10
[OGRO] “The Open GRid Ocsp API”. http://globus-grid.certiver.com/info/ogro/
11
helm@es.net
22
GWD-I
March 2016
1
16
Revision History
2
[These sections following to be removed at final edit]
Date
Version
Who
Summary
2006-02-03
06-01
mwh
Readability; X509; ss 3 – OCSP core; Interpretation of Unknown status;
about delta CRLs; discovery methods; responder types
2006-02-04
06-02
mwh
Formatting uglies; notes for next readability pass
2006-02-04
06-03
Mike
Proxy
New Proxy handling section; authors
2006-02-07
06-04
mwh
Mostly: Clean up formatting, delete old proxy section, add refs openssl,
bouncycastle, myproxy, &c
2006-02-10
06-05
mwh
Title file name; CRL info; certificatehold; ocsp client discussion; disperse
other sections; added most of pros-cons paper, tried to address other iss
corrections from O & J; trying to address Chadwick;s objection about non
revocation of proxies; see section 17 06-05 below
2006-02-11
06-06
mwh
Table of delta CRLs; clearinghouse discovery (8.5); see section 17 06-06
2006-02-11
06-07
mwh
Accept all changes in 06 (for GGF / CAOPS re-posting)
2006-02-12
06-08
mwh
Formatting; note on cached responses in 8.1.1; Appendix example
3
4
17
5
Proxy sections – rewrite for clarity; pros-cons format? Also some missing text
6
Note: wait until more proxy feedback occurs
7
17.1 06-06
8
9
10
11
12
13
14
15
16
17
18
19
Notes for next revision

Beginning sections – reframe, add material relating to new directions/material
Added some to practical considerations. Abstract & Intro MAY need updating – need another
opinion on this.

Databases &c characteristics in local OCSP Responder, blacklist &c
Added text to 5.3
 Paradoxical behavior – may want midlevel responders (VO espec) to use CRL’s from
CAs 1st, because of above behavior, then or also OCP, because true Auth responders
rare as above
8.1.6
 Client reqs – add config & discovery requirements? Move?
Sort of – see 8.1.1
20

21
This was really certificate hold & CRL as well
Certificatehold and nextupdate
22
23

Proxy certs and nextupdate
helm@es.net
23
GWD-I
1
2
3
March 2016
In proxy rev requirements, 6.3
17.2 06-05
4
5
6
7

In practice Auth responders nearly useless because of offline CAs, small, not used much
in Grids; probably Trusted responders, even for CAs, more likely? Express this paradox
somewhere (CA rqmts?) . Also what issues w/ trusted responder cert – discuss,
investigate – 7.2
8

Explain certificatehold in same place, why it causes probs, what to do
9

Summarize responder deployments from client pt of view
10
11

Should mention indirect CRLs – this is usable with OCSP as an intermediary (what about
lifetime stamping)?
12

Or delta-crls – what lifetime stamping do deltas have?
13
14

Discuss Blacklisting use case eg as expounded orig by Steve Lau & Genovese –
probably in section justifying – explaining local database usage and management more.
15

CA –requirements – really CRL requirements instead
16

Pull together all the delta CRL discussion
17

Add J & O’s pro-cons discussion
18
Partly – some still thinking about, some couldn’t fit, some lost context

19
20
21
May want CAs to provide 2 kinds of CRLs, recent, or “Grid Long” – 30 day; and short
lifetime, for OCSP – use terminology Olle picked up from rfc3125 for assurance.
Addressed this with delta CRLs
22
23
24
17.3 06-04

25
Make table of authors
26
Appendix A OCSP Responder Examples
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
A.1
Simple Client – Server Example
1. Application receives certificate from an end user.
2. (Optional) The application checks its OCSP responses cache for a recent evaluation of
this certificate.
3. Application applies revocation policy for the issuer of this certificate: in this case, the
policy is to use OCSP service locator information in a certificate, if available.
4. The application queries the OCSP responder found in the certificate service locator,
sending in the certificate.
5. The OCSP responder returns a signed response.
6. The application evaluates the signing certificate. For this issuer’s OCSP responder, the
application has a policy of implicit trust and no CRL checking, because the signing
certificate has a lifetime of 5 minutes.
7. (Optional) The application logs the response.
8. (Optional) The application caches the response.
9. The application acts on the “Good” or “Revoked” status received in the response.
helm@es.net
24
GWD-I
March 2016
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
A.2
Grid Application Interaction with Site OCSP Responder
1. The site OCSP responder checks its response cache. It has a cached “GOOD” response
for the End-Entity certificate, but nothing for the proxy certificate.
2. Site policy is evaluate revocation for proxy certificates where possible. For this issuer,
the responder policy is to submit proxy certificates to the responder found at the endentity certificate service locator. The responder assembles a complete certificate chain
from Issuer information in its local cache.
3. The site responder queries the Issuer’s OCSP responder
4. The Issuer OCSP Responder returns a signed response.
5. The site responder checks the Issuer Responder’s certificate against the Issuer’s CRL,
which the site responder keeps as a backup.
6. The site responder caches the response.
7. The site responder signs and returns the response to the application.
8. The application evaluates the signing certificate. For this site’s OCSP responder, the
application checks it against the issuer’s CRL, which in this case is the site’s own CA.
9. (Optional) The application logs the response.
10. (Optional) The application caches the response.
11. The application acts on the status received in the response. In this case, the proxy
certificate has status “Unknown” and the superior certificates all have status “Good”.
Local policy is to ignore “Unknown” status from proxy certificates.
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
A.3
MyProxy Example
In this case, an End-Entity has created and delegated a proxy certificate to a MyProxy service.
The user has used this proxy certificate as the founding authenticator for a complex job. This job
has created another proxy certificate to use a resource in another domain, and has delegated the
right to renew this proxy certificate to the remote resource. The remote resource in turn needs to
use this proxy certificate as the basis for access to a set of files it needs to retrieve.
1. The file storage application receives a chain of proxy certificates and end-entity certificate
from another application.
2. (Optional) The application checks its OCSP responses cache for a recent evaluation of
any of these certificates. If any are revoked, the interaction is rejected.
3. The application passes the certificate chain it received to a local OCSP responder for
evaluation.
4. The local responder searches up the chain of certificates received, attempting to retrieve
a service locator for an OCSP responder. It finds one in the first proxy certificate.
5. The local responder assembles a complete certificate chain from Issuer information in its
cache.
6. The local responder passes the complete chain to the discovered responder. In this
case, it is a responder associated with a MyProxy service.
7. The MyProxy OCSP responder only returns OCSP responses for its managed proxy
certificates. But this case, the end entity has terminated the job and deleted the head
proxy certificate from the MyProxy store. The result is that MyProxy OCSP responder
marks this proxy certificate as revoked.
8. The local responder checks the OCSP responder certificate, and assembles a partial
response.
9. The local responder continues up the chain of certificates, trying to find additional AIA
extensions. There are none.
10. The local responder checks each certificate in the chain against its issuer’s cached CRL
information, completing the set of responses.
11. (Optional, recommended) The local responder caches responses.
12. The local responder returns a signed response to the file storage application. .
helm@es.net
25
GWD-I
March 2016
1
Appendix B OCSP Client Configuration Examples
2
3
4
5
6
B.1
The Open GRid Ocsp API (OGRO)
The Open GRid Ocsp –OGRO- is a Java API that implements OCSP validation for Grid environments.
It is configured through a set of rules -written in XML- called the Grid Validation Policy, which customizes
relying parties’ certificate validation behavior. Figure 1 shows the DTD of such policy.
1 <?xml version="1.0" encoding="UTF-8" ?>
2 <!ELEMENT ocsppolicy ( issuerdn+ ) >
3 <!ELEMENT issuerdn ( source?,unknownstatus?,
errorhandler?,request?,proxycert? ) >
4 <!ATTLIST issuerdn dn CDATA #REQUIRED>
5 <!ATTLIST issuerdn name CDATA #REQUIRED >
6 <!ATTLIST issuerdn hash CDATA #REQUIRED >
7 <!ELEMENT revsources ( source+ ) >
8 <!ELEMENT source EMPTY >
9 <!ATTLIST source order CDATA #REQUIRED >
10 <!ATTLIST source signingcert CDATA #IMPLIED >
11 <!ATTLIST source location CDATA #REQUIRED >
12 <!ATTLIST source type (trusted|authorized) "trusted" >
13 <!ATTLIST source timeout CDATA #IMPLIED >
14 <!ELEMENT unknownstatus EMPTY >
15 <!ATTLIST unknownstatus action (good|revoked) "revoked">
16 <!ELEMENT errorhandler ( action+ ) >
17 <!ELEMENT action EMPTY >
18 <!ATTLIST action order CDATA #REQUIRED >
19 <!ATTLIST action type
(tryLater|setFinalResp)"setFinalResp">
20 <!ATTLIST action value (good|revoked) "revoked" >
21 <!ATTLIST action maxRetries CDATA #IMPLIED >
22 <!ELEMENT request ( signreq?, usenonce?, prot?, ext* ) >
23 <!ELEMENT signreq EMPTY >
24 <!ATTLIST signreq value (true|false) "false" >
25 <!ELEMENT usenonce EMPTY >
26 <!ATTLIST usenonce value (true|false) "true" >
27 <!ELEMENT prot EMPTY >
28 <!ATTLIST prot value (http|https) "http" >
29 <!ELEMENT ext EMPTY >
30 <!ATTLIST ext order CDATA #REQUIRED >
31 <!ATTLIST ext oid CDATA #REQUIRED >
32 <!ATTLIST ext value CDATA #REQUIRED >
33 <!ELEMENT proxycert ( unknownstatus ) >
Figure 0-1
Fig. 1. DTD of OGRO’s Grid Validation Policy.
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
From previous figure we can observe at line 2 that the OGRO’s policy allows per issuer validation rules
customization or even the option to configure a default issuer, that is, rules applying to any user whose
issuer is not referenced anywhere else in the policy.
A set of revocation sources (lines 8-13) can be also defined as an ordered list, which means that the relying
party may be able to consult more than one OCSP Responder thus providing fault tolerance and high
availability.
To support Proxy revocation features, a customizable meaning of the “Unknown” OCSP status –line 15can be defined for any certificate on the path (Proxy or even non-Proxy).
At lines 16-19, error handling mechanisms may be declared to take a certain action if for example an OCSP
Responder could not be contacted. The current set of error handlers can be extended to fulfill special
requirements of VOs. Customization of OCSP Requests (i.e. use of signatures and nonces) is provided also
by OGRO –lines 22 to 32- .
More than being a set of configuration directives, OGRO’s Grid Validation Policy represents a mechanism
to tailor validation process’ security level. For example a VO may decide to use only a defined set of
helm@es.net
26
GWD-I
1
2
3
4
5
6
March 2016
internal OCSP Trusted Responders benefiting performance (i.e. not using digital signatures, nonces nor
HTTPS), while other VO may use external OCSP Authorized Responders but compelling its clients to use
strong OCSP Requests (i.e. digitally signed, using a nonce and HTTPS).
Future extensions to OGRO’s Grid Validation Policy may support different types of revocation
sources (i.e. CRLs) and OCSP Response’s related options (i.e. caching).
7
8
helm@es.net
27