Additional content/transfer encodings are disallowed because many clients and servers in this context are basic HTTP engines attached to key management applications, not full-featured browsers; eliminating choices reduces code complexity and potential security issues.

http, pkix

Certificate and CRL stores are allocated separate URIs because certificate stores contain large numbers of small items while CRL stores contain a small number of potentially large items, enabling back-end implementations tailored to each data type.

pkix, http

Multiple certificate responses are returned as multipart/mixed rather than ASN.1 SEQUENCE OF Certificate or PKCS #7 because this is simpler with standard web-enabled tools and does not restrict the mechanism to DER-based data, allowing XML, PGP, and SPKI content as well.

pkix, http

PGP IDs are encoded as base64 rather than the traditional C-style 0xABCDEF hex notation to ensure consistency and avoid ambiguity, since hex strings are also valid base64 strings and near-misses like '0xABCDRF' are hard to classify reliably.

pkix

SHA-1 hashes are used for arbitrary-length fields such as DNs to keep URI lengths manageable and to emphasize that structured name searching is not supported — this is a simple {key,value} store interface, not an HTTP interface to X.500.

pkix, http

SIA/AIA extensions are used to indicate the CRL store interface rather than the CRLDistributionPoint (CRLDP) extension because CRLDP points to a single static CRL for one certificate, while SIA/AIA indicates how to access CA information and services for any certificate issued by the CA.

pkix

'Well-known' locations are provided as a fallback because DNS SRV, while optimal for service discovery, is not supported by older Windows systems (Windows 95/98); the well-known URI scheme allows those clients to locate certificate stores without SRV support.

dns, http, pkix

Chunked transfer encoding is given a SHOULD NOT rather than MUST NOT because many versions of Apache web server use it unnecessarily; clients that choose not to support chunked encoding may encounter problems with Apache-based HTTP certificate stores.

http, pkix

For historical reasons, some clients may submit the URI attribute name as 'email' rather than 'uri' (reflecting legacy use for S/MIME certificate lookup). Servers may choose to accept 'email' as an alias for 'uri', though this is not required.

http, pkix, email

This protocol is similar to the PGP HKP protocol but no attempt has been made to ensure interoperability or compatibility with HKP-based servers due to HKP's lack of formal standardisation documentation.

http, pkix

CAs SHOULD use the SubjectInfoAccess (SIA) and AuthorityInfoAccess (AIA) extensions in certificates to convey well-known points of information access to relying parties.

pkix, http

Certificate store service providers SHOULD use the defined 'well-known' URI forms (e.g., certificates.<domain>/search.cgi) in preference to other alternatives.

http, pkix

Certificate URIs MUST support retrieval by all defined X.509 attribute types: certHash, uri, iHash, iAndSHash, name, sHash, and sKIDHash.

http, pkix

CRL URIs MUST support retrieval by the iHash and sKIDHash attribute types. A CRL query MUST return the matching CRL with the greatest thisUpdate value (the most recent CRL).

http, pkix

For DNS SRV service location, the symbolic name SHALL be 'certificates' for the certificate store, 'crls' for the CRL store, 'pgpkeys' for PGP public keys, and 'pgprevocations' for PGP revocation information.

dns, pkix, http

If more than one certificate matches a query, the response MUST be returned as a multipart/mixed response. The returned data MUST NOT use any additional content- or transfer-encoding at the HTTP level (e.g., compression or base64).

http, pkix

Implementations SHOULD NOT use chunked encoding in responses because the small data quantities (1-2kB) make it unnecessary and chunked encoding support is vulnerable to various implementation bugs.

http, pkix

Key URIs for PGP MUST support retrieval by all defined PGP attribute types: email, fingerprint, keyID, and name. Revocation URIs MUST support retrieval by fingerprint and keyID.

http, pkix

The query value in the URI MUST be encoded using the form-urlencoded media type. Queries containing base64-encoded values with characters outside 'a'-'z', 'A'-'Z', '0'-'9', '+', and '/' MUST be rejected.

http, pkix, security

PGP attribute types defined for key and revocation queries: email (email address), fingerprint (base64-encoded 160-bit PGP key fingerprint), keyID (base64-encoded 64-bit PGP key ID), name (user name).

http, pkix

The HTTP query URI uses the form: query = attribute '=' value, where the attribute is a certificate or key identifier type and the value specifies one or more certificates or public keys to be returned. Additional attribute/value pairs separated by '&' may specify further actions; stores SHOULD ignore unrecognized pairs.

http, pkix

Two new AIA/SIA accessMethod OIDs are defined: id-ad-http-certs (id-ad 6) for the HTTP certificate store URI and id-ad-http-crls (id-ad 7) for the HTTP CRL store URI, both under the PKIX id-ad arc.

pkix, http, registry

X.509 attribute types defined for certificate and CRL queries: certHash (SHA-1 fingerprint), uri (subject URI without scheme), iHash (DER-encoded issuer DN hash), iAndSHash (issuerAndSerialNumber hash), name (subject CommonName), sHash (DER-encoded subject DN hash), sKIDHash (subjectKeyIdentifier hash).

http, pkix

Back-end databases accessed via the web interface SHOULD be configured for read-only access (e.g., via SQL GRANT/REVOKE or opening Berkeley DB in read-only mode) to prevent modification of the certificate store through the HTTP interface.

security, pkix, http

HTTP caching proxies may return out-of-date certificates or CRLs if misconfigured. Clients and servers should use 'Cache-Control: no-cache' (or 'Pragma: no-cache' for HTTP 1.0) to prevent stale responses.

security, http, pkix

The certificate store is not a trusted directory; fetching a certificate from an entity claiming to be X provides no assurance about the certificate's veracity. Users must independently verify certificates before use; using signed representations or HTTPS are local policy options.

security, pkix

Unvalidated query values passed to RDBMS back-ends enable SQL injection attacks; even read-only access can expose password hashes. Implementations MUST use parameterised queries (placeholders) rather than assembling SQL strings from query values, and MUST check both encoded and decoded forms of input.

security, pkix, http

Binary search key encoding: arbitrary-length binary fields (e.g., DN hashes) are first SHA-1 hashed to 160 bits, then base64-encoded to 27 characters (trailing '=' padding dropped). Fields marked 'Base64' only are base64-encoded without the SHA-1 step; trailing '=' padding is removed in all cases.

pkix, http, crypto