One document matched: draft-ietf-pkix-ipki2opp-00.txt
Expires in 6 months March 1997
S. Boeyen (Entrust Technologies)
R. Housley (SPYRUS)
T. Howes (Netscape)
M. Myers (Verisign)
P. Richard (Xcert)
Internet Public Key Infrastructure
Part 2: Operational Protocols
<draft-ietf-pkix-ipki2opp-00.txt>
Status of this Memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This is the first draft of the Internet Public Key Infrastructure
X.509 Operational Protocols. This document identifies candidate
protocols for retrieval of X.509 v3 certificates and v2 CRLs as
well as a candidate protocol for online status checking of X.509 v3
certificates. It is proposed that this document serve as the basis
for the PKIX Part 2 standardization effort. Please send comments on
this document to the ietf-pkix@tandem.com mail list.
1. Introduction
This specification is Part 2 of a multi-part standard for development
of a Public Key Infrastructure (PKI) for the Internet. This
specification addresses the requirements to provide retrieval of
certificates and CRLs from an information repository. Two
protocol profiles are provided to satisfy this requirement. One is
[Page 1]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
based on the Lightweight Directory Access Protocol (LDAP) and the
other on the File Transfer Protocol (FTP). In addition, the
requirement for a user to validate the status of a certificate
online, directly from a CA is addressed and supporting protocol is
specified.
1.1 Model
The PKI components, as defined in PKIX Part 1, which are involved
in PKIX operational protocol interactions include:
- End Entities
- Certification Authorities (CA)
- Repository
End entities and CAs retrieve certificates and/or CRLs from the
repository using either the Lightweight Directory Access Protocol
(LDAP) profile defined in section 2 or the File Transfer Protocol
(FTP) profile defined in section 3 of this specification.
Otherwise, entities validate the status of a certificate, by
communicating directly with a CA, using the Online Certificate
Status Protocol (OCSP) defined in section 4 of this specification.
2. Lightweight Directory Access Protocol (LDAP)
This section examines the retrieval of information from the
certificate/CRL repository and defines a subset of the LDAPv2
protocol for providing this retrieval mechanism. Two scenarios,
satisfying different sets of requirements are provided in 2.1 and
2.2 below. Section 2.1 satisfies the requirement to retrieve
information (a certificate, CRL, or other information of interest)
from an entry in the repository, where the retrieving entity
(either an end entity or a CA) has knowledge of the name of the
entry. This is termed "repository read". Section 2.2 satisfies the
same requirement as 2.1 for the situation where the name of the
entry is not known, but some other related information which can be
used as a filter against candidate entries in the repository, is
known. This is termed "repository search".
The subset of LDAPv2 needed to support each of these functions is
described below. Note that the repository search service is a
superset of the repository read service in terms of the LDAPv2
functionality needed.
Note also that all tags are implicit by default in the ASN.1
definitions that follow.
2.1 LDAP Repository Read
To retrieve information from an entry corresponding to the subject
or issuer name of a certificate, requires a subset of the following
[Page 2]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
three LDAP operations:
BindRequest (and BindResponse)
SearchRequest (and SearchResponse)
UnbindRequest
The subset of each operation is given below.
2.1.1 Bind
2.1.1.1 Bind Request
The full LDAP v2 Bind Request is defined in RFC 1777.
An application providing a LDAP repository read service MUST
implement the following subset of this operation:
BindRequest ::=
[APPLICATION 0] SEQUENCE {
version INTEGER (2),
name LDAPDN, -- MUST accept NULL LDAPDN
simpleauth [0] OCTET STRING -- MUST accept NULL simple
}
An application providing a LDAP repository read service MAY
implement other aspects of the BindRequest as well.
Different services may have different security requirements. Some
services may allow anonymous search, others may require
authentication. Those services allowing anonymous search may only
allow search based on certain criteria and not others.
A LDAP repository read service SHOULD implement some level of
anonymous search access. A Public-Key Search service MAY implement
authenticated search access.
2.1.1.2 BindResponse
The full LDAPv2 BindResponse is described in RFC 1777.
An application providing a LDAP repository read service MUST
implement this entire protocol element, though only the following
errors codes may be returned from a Bind operation:
success (0),
operationsError (1),
protocolError (2),
authMethodNotSupported (7),
noSuchObject (32),
invalidDNSyntax (34),
inappropriateAuthentication (48),
invalidCredentials (49),
busy (51),
[Page 3]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
unavailable (52),
unwillingToPerform (53),
other (80)
2.1.2 Search
2.1.2.1 SearchRequest
The full LDAPv2 SearchRequest is defined in RFC 1777. An
application providing a LDAP repository read service MUST implement
the following subset of the SearchRequest.
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
},
derefAliases ENUMERATED {
neverDerefAliases (0),
},
sizeLimit INTEGER (0),
timeLimit INTEGER (0),
attrsOnly BOOLEAN, -- FALSE only
filter Filter,
attributes SEQUENCE OF AttributeType
}
Filter ::=
CHOICE {
present [7] AttributeType, -- "objectclass" only
}
This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read"
operation: a base object search with a filter testing for the
existence of the objectClass attribute.
An application providing a LDAP repository read service MAY
implement other aspects of the SearchRequest as well.
2.1.2.2 SearchResponse
The full LDAPv2 SearchResponse is defined in RFC 1777.
An application providing a LDAP repository read service over LDAPv2
MUST implement the full SearchResponse.
2.1.3 Unbind
The full LDAPv2 UnbindRequest is defined in RFC 1777.
An application providing a LDAP repository read service MUST
[Page 4]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
implement the full UnbindResponse.
2.2 LDAP Repository Search
To search for an entry in a repository containing a user's public
key using arbitrary criteria requires a subset of the following
three LDAP operations:
BindRequest (and BindResponse)
SearchRequest (and SearchResponse)
UnbindRequest
The subset of each operation required is given below.
2.2.1 Bind
The BindRequest and BindResponse subsets needed are the same as
those described in Section 2.1.1.
The full LDAP v2 Bind Request is defined in RFC 1777.
2.2.2 Search
2.2.2.1 SearchRequest
The full LDAPv2 SearchRequest is defined in RFC 1777.
An application providing a LDAP repository search service MUST
implement the following subset of the SearchRequest protocol unit.
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2)
},
derefAliases ENUMERATED {
neverDerefAliases (0),
},
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
attrsOnly BOOLEAN, -- FALSE only
filter Filter,
attributes SEQUENCE OF AttributeType
}
All aspects of the SearchRequest MUST be supported, except for the
following:
- Only the neverDerefAliases value of derefAliases needs to be
[Page 5]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
supported
- Only the FALSE value for attrsOnly needs to be supported
This subset provides a more general search capability. It is a
superset of the SearchRequest subset defined in Section 2.1.2.1.
The elements added to this service are:
- singleLevel and wholeSubtree scope needs to be supported
- sizeLimit is included
- timeLimit is included
- Enhanced filter capability
An application providing a LDAP repository search service MAY
implement other aspects of the SearchRequest as well.
2.2.2.2 SearchResponse
The full LDAPv2 SearchResponse is defined in RFC 1777.
An application providing a LDAP repository search service over
LDAPv2 MUST implement the full SearchResponse.
2.2.3 Unbind
An application providing a LDAP repository search service MUST
implement the full UnbindRequest.
2.3 Transport
An application providing a LDAP repository read service or a LDAP
repository search service MUST support LDAPv2 transport over TCP,
as defined in Section 3.1 of RFC 1777.
An application providing a LDAP repository read service or a LDAP
repository search service MAY support LDAPv2 transport over other
reliable transports as well.
2.4 Security Considerations
For LDAP, since the elements of information which are key to the
PKI service (certificates and CRLs) are both digitally signed
pieces of information, no additional integrity service is required.
As neither information element need be kept secret and anonymous
access to such information is generally acceptable, no privacy
service is required. As CAs may have access to information
elements in the repository which anonymous users will not, it is
recommended that even though anonymous access can be provided to
end entities, CAs should bind to the repository with a minimum of
[Page 6]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
simple authentication.
3. File Transfer Protocol (FTP)
Some CAs mandate the use of on-line validation services, while
others distribute CRLs to allow certificate users to perform
certificate validation themselves. In general, CAs make CRLs
available to certificate users by posting them in the Directory.
The Directory is also the normal distribution mechanism for
certificates. However, Directory Services are not available in
many parts of the Internet today, and the File Transfer Protocol
(FTP), defined in RFC 959, offers an alternate method for
certificate and CRL distribution.
Within certificate extensions and CRL extensions, URI form of
GeneralName is used to specify the location where issuer
certificates and CRL may be obtained. For instance, a URI
identifying the subject of a certificate can be carried in
subjectAltName certificate extension. An IA5String describes the
use of anonymous, or authenticated FTP to fetch certificate or CRL.
For example:
ftp://ftp.netcom.com/sp/spyrus/housley.cer
ftp://ftp.your.org/pki/id48.cer
ftp://ftp.your.org/pki/id48.no42.crl
Internet users may publish the URI reference to a file that
contains their certificate on their business card. This practice
is useful when there is no Directory entry for that user. FTP is
widely deployed, and anonymous FTP is accommodated by many
firewalls. Thus, FTP is an attractive alternative to Directory
access protocols for certificate and CRL distribution.
For convenience, the names of files that contain certificates
should have a suffix of ".cer". Likewise, the names of files that
contain CRLs should have a suffix of ".crl".
Note that this service satisfies the the requirement to retrieve
information related to a certificate which is already identified by
a URI. It is not intended to satisfy the more general problem of
finding a certificate for a user about whom some other information,
such as their email address or corporate affiliation, is known.
4. Online Certificate Status Protocol (OCSP)
There exists a requirement for CAs to provide an Online Certificate
Status Protocol (OCSP) service characterized by a high degree of
availability and a rapid response time. Instances where this
service would be used include those where:
- Application vendors may not implement the syntax and semantics
required for standards-compliant certificate path validation.
[Page 7]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
- Application vendors who implement compliant certificate path
validation logic may not implement the logic associated with
periodic Certificate Revocation Lists (CRLs).
- Application vendors may find that while CRL processing is within
their reach, implementing the protocols necessary to obtain CRLs
from public repositories (e.g. an X.500 Directory System) is not.
- In lieu of or as a supplement to checking against a periodic CRL,
it may be necessary to obtain immediate status regarding a
certificate's revocation state (cf. PKIX Part 1, Section 3.3).
Examples include high-value funds transfer or the compromise of a
highly sensitive key.
Two meta-level requirements factor into the specification of OCSP.
First, it should be significantly easier to implement than the
corresponding local CRL processing it supplements. This will
enable the rapid integration of the protocol into emerging
certificate-enabled applications.
Secondly, the specification of OCSP should enable rapid
assimilation and deployment of the service among CA product and
service vendors. Since the task of certificate management is
largely unaffected by the mode of a certificate's use, it is
optimal from the CA perspective that a single OCSP implementation
would meet the needs of IPSEC, S/MIME, EDI and other diverse
applications. Recognizing that this goal may not be achievable,
the semantics of the OCSP transaction model should remain invariant
against the syntactic constraints of the transport protocol used to
convey the OCSP. For example, it's easily forseeable that use of
SMTP as a transport model is the path of least resistance for e-
mail User Agents, while HTTP is an optimal choice for Web browsers.
The OCSP syntax for each may differ according to each transport
protocol's usage patterns; the semantic constructs should not.
4.1 Protocol Overview
The Online Certificate Status Protocol (OCSP) enables applications
to efficiently and rapidly determine the validity and revocation
state of an identified certificate. An application issues a status
request to the certificate issuer (CA) and suspends further
certificate acceptance processing until the CA responds with a
status indication.
4.1.1 Query
An OCSP query is semantically defined by the following three
elements:
1 protocol version
2 service request
[Page 8]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
3 target certificate identifier
Upon receipt of a query, the CA first determines if: 1) the message
is well formed, 2) the CA provides the requested service, and 3)
the CA issued the subject certificate. If any one of the prior
conditions are not met, an error message is produced; otherwise, a
definitive response is returned.
4.1.2 Response
All definitive response messages are authenticated with the
responding CA's digital signature. A definitive response message
is composed of:
1 date and time of response
2 repeat of target certificate identifier
3 certificate status value
4 signature algorithm OID
5 signature computed across hash of previous four values
This specification defines the following "definitive" response
values:
1 VALID
2 INVALID
3 REVOKED
4 NOT REVOKED
5 EXPIRED
Two error response semantics are defined. The first favors service
availability at the expense of security. This is a "minimal" error
response. The second option provides the converse balance:
enhancing the authenticity of CA error responses through the use of
a signed error message, although at the risk of denial of service.
(The Performance Considerations and Security Considerations
sections of this document provide amplifying discussions.)
The syntactic definition of a minimal error message is expected to
vary by transport protocol. For example, when using HTTP to convey
OCSP, a minimal error response would be a single space character.
This is viewed as sufficient to inform the requesting party that,
with some degree of likelihood, the CA received the message but
could not return an otherwise definitive response.
Signed error messages are semantically identical to definitive
response messages, extending the set of definitive response values
to include the previously identified error conditions:
1 ILLFORMED MESSAGE
2 SERVICE UNAVAILABLE
3 DID NOT ISSUE CERTIFICATE
In the case of an ill-formed message, it may not be possible for
[Page 9]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
the receiving CA to parse the certificate identifier from the
received message. To regularize the implementation of response
generation and response processing logic, a null certificate
identifier is defined.
4.2 Requirements
For the purposes of requirements specification, abstract response
values are indicated by UPPER CASE. A syntactic-level
interpretation of these abstract values per transport protocol is
provided in Section 4.3.1 of this specification.
4.2.1 Definition of Services
Certificate status service information can be organized into three
categories: 1) certificate path validation; 2) current revocation
status; and 3) historical revocation status. Path validation
services enable applications to defer all processing associated
with determining a certificate's validity state to a trusted third
party. The current revocation status service provides the means to
determine whether or not an otherwise valid certificate has been
revoked within the interval of its validity period and maintains
this state for some limited time thereafter. The historical
revocation status service extends the current revocation status
service over an extended period of time beyond a certificate's
expiration.
4.2.2 Error Responses
Upon receipt of a query which fails to parse against defined OCSP
semantics, the receiving CA shall respond with an error message.
If a CA provides signed error responses, a failure to parse an
incoming query shall be indicated by an ILLFORMED MESSAGE response.
The value of the certificate identifier of such a response shall be
NULL_CERT_ID.
For service request categories not supported by a CA, the CA shall
respond with an error message. If a CA provides signed error
responses, non-availability of the requested service shall be
indicated by a SERVICE UNAVAILABLE response.
For service request categories supported by a CA, if the receiving
CA did not issue the subject certificate, the CA shall respond with
an error message. If a CA provides signed error responses, this
error situation shall be indicated by a DID NOT ISSUE CERTIFICATE
response.
CAs shall produce a minimal error response as described in Section
2.1.2. They may provide signed error responses as described in
Section 2.1.2. They should provide the option to do both. The
means by which a CA signals to a relying party which error behavior
is offered should be through certificate contents.
[Page 10]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
4.2.3 Required and Optional Services
CAs which offer online certificate status services shall at a
minimum provide the current revocation status service defined in
Section 3.1.
Upon receipt by a CA of a current revocation status request for a
certificate issued by the recipient CA, the CA shall respond with
either REVOKED or NOT_REVOKED, according to the certificate's
status, throughout the duration of the certificate's validity
interval and continuing for a given number days following the date
of the subject certificate's expiration. This latter interval is
identified as the certificate's "inclusion interval".
Specification of a certificate's inclusion interval is considered a
matter of a CA's certification practices, and should be documented
in the CA's Certification Practices Statement.
If a subject certificate was not revoked prior to the expiration of
its validity period, but a current revocation status request is
received by its issuer within the subject certificate's inclusion
interval, the CA shall respond with a status indicating EXPIRED.
Thereafter, CAs may respond with an error message. If a CA provides
signed error responses, this error situation shall be indicated by
a DID NOT ISSUE CERTIFICATE response. (That is, the CA is not
required to maintain online records regarding issuance beyond some
well-defined interval. The automatic mechanisms that produce OCSP
responses may not therefore be able to differentiate between the
expiration of a certificate previously issued and a certificate
that was never issued. This requirement is not intended to
establish the full extent of a CA's record-keeping obligations.
The means by which CAs enable the resolution of such queries via
other mechanisms and for other purposes are beyond the scope of
this specification.)
CAs may extend a certificate's inclusion interval to some
arbitrarily longer period of time, thereby providing historical
revocation status service. This interval is identified as a
certificate's "online status retention interval". Specification of
a certificate's online status retention interval is considered a
matter of a CA's certification practices, and should be documented
in the CA's Certification Practices Statement. (The same caveat
applies here regarding online vs. off-line records access
requirements.)
Queries on certificates beyond the online status retention interval
are considered by this specification to be more properly addressed
by CA Archive services. Interactions with CA Archive services are
beyond the scope of this specification.
CAs may provide online certificate path validation status services;
[Page 11]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
they are not required to do so. However, if a CA does provide this
service, then upon receipt of a path validation request for a
certificate issued by the recipient CA, the CA shall respond as
follows:
If the subject certificate is: CA responds with:
------------------------------ -----------------
within validity interval and valid: VALID
within validity interval and invalid: INVALID
within validity interval and revoked: REVOKED
within inclusion interval and not revoked: EXPIRED
within inclusion interval and revoked: REVOKED
4.2.4 Use of PKIX AuthorityInfoAccess Extension
In order to convey to certificate-using systems a well-known point
of information access, CAs that provide online certificate status
services shall provide the capability to include the
AuthorityInfoAccess extension (defined in PKIX Part 1, section
4.2.2.2) in certificates intended to be applied to the service.
At a minimum this extension shall contain a value for certStatus
field.
Conversely, certificate-using systems shall be capable of
processing the AuthorityInfoAccess extension for the purposes of
obtaining the AccessDescription value of the certStatus field.
4.2.5 Required and Optional Access Methods
CAs which provide certificate status services shall provide a value
for a uniformResourceIndicator (URI) accessLocation and the OID
value httpID for the accessMethod in the AccessDescription SEQUENCE
of the certStatus field. (The httpID OID value is defined in PKIX
Part 1, Section 8: ASN.1 Structures and OIDs.)
CAs may provide additional values of AccessDescription in the
certStatus field of AuthorityInfoAccess.
Certificate-using systems are not required to implement mechanisms
for all values of AccessDescription.
However, to ensure the development and deployment of a globally
interoperable infrastructure with the minimum number of
requirements, PKIX-compliant certificate-using systems shall be
capable of recognizing the httpID accessMethod and be capable of
using the corresponding URI accessLocation value in accordance with
the protocol syntax and semantics defined in Section 4.3.1 of this
document.
The syntax, semantics and OIDs of each additional included
AccessDescription syntax of certStatus shall conform to PKIX Part
[Page 12]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
1.
For each AccessDescription included in the certStatus SEQUENCE of a
given certificate, the issuing CA shall ensure that: 1) all
information required to obtain a certificate's status is included
in the accessLocation value; and 2), the status response is
invariant with respect to the use of any AccessDescription value
included in the certStatus SEQUENCE.
4.2.6 Access Method Symmetry
For each AccessDescription for which a CA provides a certificate
status service, the CA shall transmit responses using the access
method used to receive the correspondingly prior query. That is,
queries transmitted using HTTP will result in HTTP responses;
queries transmitted using SMTP will result in SMTP responses; and
so forth.
Conversely, certificate-using system which initiate a query using a
given access method shall be capable of receiving the corresponding
response using that same access method.
4.3 Detailed Protocol
This section specifies the details of OCSP per access method. At
present, only the HTTP access method is specified. Specifications
of OCSP over other access methods will follow.
4.3.1 HTTP
4.3.1.1 Query Syntax
An HTTP-based OCSP query is a text-based message composed of a URL
followed by a sequence of keyword-value pairs. The following loose
grammar specifies the query portion of the protocol. Quoted
syntactic elements are terminal elements of the grammar.
OCSP_query : url request version cert_id
url : protocol "://" domain_name "/"
protocol : "http"
request : service_class "/" action
service_class : "status"
action : "check"
cert_id : "ID" "/" hash
hash : hash_of(Issuer DN | cert serial number)
The cert_id field could be a straightforward reiteration of the
Issuer DN and certificate serial number. However, OCSP should be
responsive to bandwidth issues associated with high usage frequency
(i.e millions of hits per day on a responding server). Backend
search efficiency should be a factor as well, for exactly the same
reason.
[Page 13]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
A hash of issuer DN with certificate serial number meets these
needs, both reducing the bits on the wire and also providing an
unstructured index useful for high speed, random access to large
data repositories.
There is no cryptographic relevance to the use of a hash in OCSP
queries. The requirement is production of a compact, unique
identification. MD5 meets these needs and further yields fewer
bits on the wire than, for example, SHA-1. Support for other hashes
will require inclusion of a hash algorithm identifier, further
extending the number of bits on the wire. Consequently, the OCSP
query hash value shall be the base-64 representation of a hash
computed using MD5.
4.3.1.2 Response Syntax
An HTTP-based OCSP response is composed of a sequence of data
fields separated by a "#" character. Response codes are returned
as the ASCII encoding of a decimal number. Values with a minus
sign (ASCII encoding of "-") indicate definitive error values.
OCSP_response : definitive_rsp | error_rsp
definitive_rsp : base status_value signature_block
error_rsp : minimal_error | definitive_error
minimal_error : 0x20 // " " //
definitive_error : base error_value signature_block
base : time "#" prior_id "#"
time : YYYYMMDDHHMMSSZ
prior_id : // cert_id value of corresponding query //
error_value : illformed_msg | no_service | not_my_cert
illformed_msg : 0x2d 0x31 // "-1" //
no_service : 0x2d 0x32 // "-2" //
not_my_cert : 0x2d 0x33 // "-3" //
status_value : valid|invalid|revoked|not_revoked|expired
not_revoked : 0x31 // "1" //
revoked : 0x32 // "2" //
invalid : 0x33 // "3" //
valid : 0x34 // "4" //
expired : 0x35 // "5" //
signature_block : sig_alg_oid "#" signature
sig_alg_oid : // OID used to generate signature //
signature : // base-64 encoded value corresponding to
the result of using sig-alg-oid //
To produce a signed response, the responder first calculates a hash
across the to-be-transmitted sequence
[Page 14]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
{ time#prior_id#response_value#sign_alg_oid# },
signs the hash using the algorithm indicated by sig_alg_oid, base-
64 encodes the result and then concatenates it to the prior fields.
4.4 Performance Considerations
Performance considerations may motivate the use of a cache on the
status server end to retain recently retrieved state information.
When doing so, the effect of cache refresh rates need to be
considered. It is possible when using such an approach to reduce
the timeliness of the certificate status service to that
approaching periodic CRL distribution.
4.5 Security Considerations
For this service to be effective, certificate using system must
connect to the certificate status service provider. In the event
such a connection cannot be obtained, certificate-using systems
should implement CRL processing logic as a fall-back position.
A denial of service vulnerability is evident with respect to a
flood of queries constructed to produce error responses. The
production of a cryptographic signature significantly affects
response generation cycle time, thereby exacerbating the situation.
Performance studies on a preliminary implementation of OCSP capable
of handling two million hits per day without degradation suggest
this effect is of an orders of magnitude per response. Unsigned
error responses provide a reasonable tradeoff against protection
against this particular attack.
The use of unsigned error messages introduces a vulnerability to
intermediation attacks. It is reasonable to ask for error messages
to be signed to address this vulnerability. A request to do so
however must also consider the converse risk identified above-
namely that increasing the response cycle time of error messages
through use of cryptographic signing increases the impact of
flooding attacks. CAs that wish to offer to their relying parties
the benefit of signed error responses should strongly consider the
use of hardware-assisted cryptography. Do so will reduce the
threat of flood attacks.
To mitigate the effects of replay attacks (by using previously
signed responses), applications should match the certificate
identifier and time field of the incoming response to the previous
query before acting on the response.
Finally, the results delivered to the certificate acceptance
decision function may be mediated by one or more software
components which provide no explicit means to establish or maintain
a trusted path. Ultimately, the relying party (or, in the case of
[Page 15]
Draft-ietf-pkix-ipki2opp-00.txt March 1997
automated machine processing, the owner/operator of a router, Web
Server, X.400 MTA, etc.) is responsible for placing trust in the
results.
Author Addresses:
Sharon Boeyen
Entrust Technologies
2 Constellation Crescent, Nepean
P.O. Box 3511,Station C
Ottawa, Ontario
Canada K1Y 4H7
boeyen@entrust.com
Russell Housley
SPYRUS
PO Box 1198
Herndon, VA 20172
USA
housley@spyrus.com
Tim Howes
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA 94043
USA
howes@netscape.com
Michael Myers
VeriSign Inc.
2593 Coast Avenue
Mountain View, CA 94043
USA
myers@psn.net
Patrick Richard
Xcert Software Inc.
Suite 1001, 701 W. Georgia Street
P.O. Box 10145
Pacific Centre
Vancouver, B.C.
Canada V7Y 1C6
patr@xcert.com
[Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 12:35:44 |