OCSP over DNS

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

With the increasing number of highly available and highly utilized websites that require secure communications to protect the flow of information from the server to the client, the need for a low-cost efficient approach to revocation information availability is crucial. The OCSP-over-DNS approach allows clients to determine the status of digital certificates specifically for high-traffic Internet secure servers (i.e., SSL/TLS) by optimizing the delivery mechanism for revocation information distribution to the client. This transport protocol can be used in lieu of or in addition to other PKIX endorsed transport mechanisms such as HTTP. This specification addresses the problem of providing a low-latency highly-available distributed system for OCSP responses availability. In particular, OCSP-over-DNS is meant to be used in conjunction with pre-computed OCSP responses. This document defines the DNS records to be used for OCSP data publication and the definition of additional URLs for the AuthorityInfoAccess (AIA) extension in certificates.

In order to validate a certificate using OCSP-over-DNS, the client should check the certificate for a DNS-based OCSP base URI, construct the URI for the specific certificate, and then retrieve the OCSP response from the DNS. After this point, all procedures are to be performed according to the OCSP protocol as defined in . In particular, clients using OCSP-over-DNS, SHOULD: Lookup the OCSP URI provided in the AIA of the certificate to be checked. The format of the URI comprises the id-ad-ocsp identifier and a base URL where the scheme is dns://. The format of the full URI is discussed in the next section. Build the OCSP query for the certificate to be checked. This is done by pre-pending the hex representation of the digest of the certificate to the base domain provided in the OCSP DNS URI. Retrieve the DNS record carrying the required OCSP response. The Client SHOULD retrieve the revocation information directly through the DNS system. The distributed nature of DNS will allow for automatic load distribution. References to the suggested configurations for the transport and distribution protocols and servers is provided in the Appendix of this document.

As described in , in order to convey to OCSP clients a well-known point of information access, CAs SHALL provide the capability to include the AuthorityInfoAccess extension in certificates that can be checked using OCSP. In addition to the HTTP transport protocol defined in , this document defines an additional transport protocol for OCSP Responses, i.e. DNS records. This transport mechanism is useful only in environments where OCSP responses are pre-computed (common in Internet CAs). The accessMethod in the AccessDescription SEQUENCE of the URI should use id-ad-ocsp as its value as usual. However, if DNS records are used for distributing pre-computed OCSP responses , the value of the accessLocation field in the subject certificate SHOULD define 'dns' or 'dnssec' as the transport used to access the OCSP response data. Additionally the URL can optionally contain parameters to specify the digest algorithms to be used by clients to calculate the DNS query. The default digest algoritm is "SHA256".

A DNS URL begins with the protocol prefix "dns" or "dnssec" and is defined by the following grammar, following the ABNF notation defined in .

dnsurl = scheme COLON SLASH SLASH [base] [QUESTION [ algorithm / oid] ; base: is the base hostname for ; the lookup operation. ; algorithm: is the text representation ; of the algorithm to be used to calculate ; the hash of the certificate scheme = "dns" / "dnssec" algorithm = "SHA1" / "SHA256" / "SHA384" / "SHA512" oid = "OID" COLON oidvalue ; oidvalue is the string representation of ; the oid for the hash algorithm to be used ; to calculate the hash of the certificate SLASH = %x2F ; forward slash ("/") COLON = %x3A ; colon (":") QUESTION = %x3F ; question mark ("?") The "dns" prefix indicates an entry or entries accessible from the configured DNS server. The "dnssec" prefix indicates, instead, an entry or entries accessible via the DNSSEC protocol and verification of the returned data SHOULD be performed. Note that the <base> may contain literal IPv6 addresses as specified in Section 3.2.2 of . The <algorithm> construct is used to specify the digest algorithm that MUST be used to construct the final DNS query. The allowable values are "SHA1", "SHA256", "SHA384", or "SHA512". Alternatively, if a different hash algorithm is specified in the URL that is not covered by <algorithm>, the use of the string representation of the algorithm's OID SHOULD be used. For example, if MD5 is specified the resulting URL will look like the following:

dns://somedomain?OID:1.2.840.113549.2.5 On the other hand, if one of the listed hash algorithm is to be used in the URL, the resulting value will look like the following:

dns://somedomain?SHA256 At minimum, a conforming client SHOULD support SHA1 and SHA256 algorithms and MAY support additional ones.

In order to process the OCSP DNS URLs in a certificate, clients have to extract the <base> from the URL and pre-pend it with the hex representation of the digest value calculated over the DER representation of the certificate to be validated. The digest and the <base> values SHOULD be separated by the dot "." character. The hash algorithm to be used is to be extracted from the AIA extension. If no value is specified, the SHA256 algorithm SHOULD be used to calculate the hash value. The client then constructs the query for the DNS as follows:

4088439518ed222e9abf7555b954bd549b78325b.somedomain<base> At this point, the client has all the information to query the DNS for the OCSP response it is searching for. The client proceeds by querying the DNS for TXT records from the constructed query. The returned value SHOULD contain the value of the base64 encoded value of the OCSP response related to the certificate that needs to be validated.

No special considerations are required for IANA.

It is only possible to provide pre-computed responses in the case where the NONCE is not provided by the client. This allows the Validation Authority (VA) or CA to generate off-line signatures for responses, an optimization used in OCSP. Moreover if an authenticated secure channel is used at the transport level between the client and the VA (e.g. HTTPS or SFTP) signatures in requests and responses can be safely omitted.

The time validity should reflect the frequency of updates in revocation information. An interesting aspect to be considered is how often would users execute the protocol for a given set of data.