RFC 4387
Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP
Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP ✨
- RFC: 4387
- Author: P. Gutmann, Ed. (University of Auckland) 🎀
- Stream: Network Working Group
- Category: Standards Track 💜
- Date: February 2006 📅
- Obsoletes/Updates: the title block doesn't list anything it obsoletes or updates 🦋
Status of This Memo
okay so this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 If you want to know where this protocol stands in standardization, check the current "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸
Copyright Notice
Copyright (C) The Internet Society (2006). 💅
Abstract
the protocol conventions in here help cover some of the operational requirements of the Internet Public Key Infrastructure (PKI) ✨ It explains how to use the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface for grabbing certificates and certificate revocation lists (CRLs) from PKI repositories. Other mechanisms that address PKIX operational requirements are specified in separate documents 🧚
Table of Contents
1. Introduction ....................................................2
2. HTTP Certificate Store Interface ................................3
2.1. Converting Binary Blobs into Search Keys ...................4
2.2. Attribute Types: X.509 .....................................5
2.3. Attribute Types: PGP .......................................6
2.4. Attribute Types: XML .......................................6
2.5. Implementation Notes and Rationale .........................6
2.5.1. Identification ......................................7
2.5.2. Checking of Input Values ............................9
2.5.3. URI Notes ..........................................10
2.5.4. Responses ..........................................11
2.5.5. Performance Issues .................................12
2.5.6. Miscellaneous ......................................13
2.6. Examples ..................................................14
3. Locating HTTP Certificate Stores ...............................15
3.1. Information in the Certificate ............................15
3.2. Use of DNS SRV ............................................16
3.2.1. Example ............................................16
3.3. Use of a "well-known" Location ............................16
3.3.1. Examples ...........................................17
3.4. Manual Configuration of the Client Software ...............18
3.5. Implementation Notes and Rationale ........................18
3.5.1. DNS SRV ............................................18
3.5.2. "well-known" Locations .............................19
3.5.3. Information in the Certificate .....................19
3.5.4. Miscellaneous ......................................20
4. Security Considerations ........................................20
5. IANA Considerations ............................................22
6. Acknowledgements ...............................................22
7. References .....................................................22
7.1. Normative References ......................................22
7.2. Informative References ....................................231. Introduction ✨
this spec is part of a multi-part standard for the Internet Public Key Infrastructure (PKI) that uses X.509 certificates and certificate revocation lists (CRLs) 🔥 It lays out how to use HTTP, or optionally HTTPS, as an interface for getting certificates or public keys, and certificate revocation lists (CRLs), from PKI repositories. From here on, the generic term HTTP covers either option 🫶
Okay, so RFC 2585 [RFC2585] does cover fetching certificates over HTTP, but it only mentions that certificates may be fetched from a static URL 🙈 That doesn't give you any general-purpose interface to a certificate store. The conventions in this doc let HTTP work as a general-purpose, transparent interface to basically any kind of certificate or key store: flat files, standard databases like Berkeley DB and relational databases, and traditional X.500/LDAP directories 💅 Typical uses include web-enabled relational databases (which, let's be honest, is most databases) or simple {key,value} lookup systems like Berkeley DB and its many descendants 💖
Additional mechanisms that address PKIX operational requirements are specified in separate documents 🧚
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 📜
2. HTTP Certificate Store Interface
the GET method gets used together with an HTTP query URI [RFC2616] to pull certificates out of the underlying certificate store 🦋
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]the query portion of the URI takes parameters. Those are a certificate or key identifier made up of an attribute type and a value, and together they pick out one or more certificates or public keys to return from the query 🎀
query = attribute '=' valueCertificates and public keys come from one URI (the certificate URI), and CRLs come from another URI (the revocation URI) 🌸 These may or may not point to the same certificate store and/or server. The exact interpretation is a local configuration issue, so it's up to you 🤷♀️
The query value MUST be encoded using the form-urlencoded media type [RFC2854] 🔒 For more on URI construction, size limits, and other factors, check [RFC2616].
Responses to unsuccessful queries (like a non-match or an error condition) get handled in the standard manner per [RFC2616] 🙃 Clients should especially be aware that servers may sometimes return HTTP type 3xx redirection requests to explicitly redirect queries to another server. And obviously, implicit DNS-based redirection is also possible 👀
If more than one certificate matches a query, it MUST be returned as a multipart/mixed response 🍓 The returned data MUST be returned verbatim. It MUST NOT use any additional content- or transfer-encoding at the HTTP level (so no compressing it, and no base64 or quoted-printable text, periodt) 🚫 Implementations SHOULD NOT use chunked encoding in responses ⭐
The query component of the URI MAY optionally contain additional attribute/value pairs separated by the standard ampersand delimiter '&'. These specify further actions for the certificate store to take ✨ Certificate stores SHOULD ignore any additional unrecognised attribute/value pairs present in the URI 💜
Other info, like naming conventions and MIME types, is specified in [RFC2585] (with extra MIME types for non-X.509 content in [RFC3156] and [RFC3275]) 🧚
2.1. Converting Binary Blobs into Search Keys
some fields (the ones marked with a "Process" value in the tables below) are arbitrary length and/or contain non-textual data 😭 Both of those things make them unsuited for direct use in HTTP queries. To make them usable, fields whose processing option is "Hash" get hashed down first to a fixed-length 160-bit value. Fields whose processing option is "Hash" or "Base64" then get base64-encoded to turn the binary data into text 🌈
Processing Processing step
option
"Hash" Hash the key value using SHA-1 [FIPS180] to produce a
160-bit value, then continue with the base64 encoding
step that follows.
"Hash" Encode the binary value using base64 encoding to produce
"Base64" a 27-byte text-only value. Base64 encoding of the 20
byte value will produce 28 bytes, and the last byte will
always be a '=' padding character. The 27-byte value is
created by dropping the trailing '=' character.For cases where the binary value is smaller or larger than the 20-byte SHA-1 output (for example, with 64-bit/8 byte PGP key IDs), the final value is made by removing any trailing '=' padding from the encoding of the binary value. This is basically a generalisation of the case above 🧠
Implementations MUST verify that the base64-encoded values submitted in requests contain only characters in the ranges 'a'-'z', 'A'-'Z', '0'-'9', '+', and '/'. Queries containing any other character MUST be rejected 🛑 (See the implementation notes in Section 2.5 and the security considerations in Section 4 for more details on this requirement. It's a big deal, bestie 😤)
2.2. Attribute Types: X.509
these are the permitted attribute types and their associated values for use with X.509 certificates and CRLs 💖 Arbitrary-length binary values (as the table below shows) get turned into a search key using the process from Section 2.1. Heads up: the values are checked for an exact match (after decoding any form-urlencoded [RFC2854] portions if needed), so they're case sensitive 👑
Attribute Process Value
--------- ------- -----
certHash Hash Search key derived from the SHA-1 hash of the
certificate (sometimes called the certificate
fingerprint or thumbprint).
uri None Subject URI associated with the certificate,
without the (optional) scheme specifier. The URI
type depends on the certificate. For S/MIME
certificates, it would be an email address; for
SSL/TLS certificates, it would be the server's DNS
name (this is usually also specified as the
CommonName); for IPsec certificates, it would be
the DNS name/IP address; and so on.
iHash Hash Search key derived from the DER-encoded issuer DN
as it appears in the certificate, CRL, or other
object.
iAndSHash Hash Search key derived from the certificate's
DER-encoded issuerAndSerialNumber [RFC3852].
name None Subject CommonName contained in the certificate.
sHash Hash Search key derived from the DER-encoded subject
DN as it appears in the certificate or other
object.
sKIDHash Hash Search key derived from the certificate's
subjectKeyIdentifier (specifically the contents
octets of the KeyIdentifier OCTET STRING).Certificate URIs MUST support retrieval by all the above attribute types 💅
CRL URIs MUST support retrieval by the iHash and sKIDHash attribute types, which identify the issuer of the CRL. CRL URIs MAY also support retrieval by certHash and iAndSHash attribute types, for cases where the use of the issuingDistributionPoint extension requires it 🦋 A CRL query MUST return the matching CRL with the greatest thisUpdate value. In other words, you get the most recent CRL 🌟
2.3. Attribute Types: PGP 🔑
okay so this part is all about PGP keys and key revocation info, and the attribute types you're allowed to use are listed right here 💅 Binary values (the ones marked in the table) get turned into a search key using the process from Section 2.1 ✨
Attribute Process Value
--------- ------- -----
email None email address associated with the key.
fingerprint Base64 160-bit PGP key fingerprint [RFC2440].
keyID Base64 64-bit PGP key ID [RFC2440].
name None User name associated with the key.Key URIs MUST support retrieval by all of the above attribute types. 🗝️ No skipping any of them, bestie!
Revocation URIs MUST support retrieval by the fingerprint and keyID attribute types, which identify the issuer of the key revocation. 🚨
2.4. Attribute Types: XML 🧡
the XML side is super chill 😌 Permitted attribute types and associated values for use with XML are as specified in sections 2.2 and 2.3. Since XML lets arbitrary attributes hang off the <RetrievalMethod> child element of <KeyInfo> [RFC3275], there are no additional special requirements for use with XML. no extra homework, periodt 🎀
2.5. Implementation Notes and Rationale 🛠️
this part is informative, which means it's the "why" behind everything in Section 2 🧠 It also gives guidance for implementors, so grab a snack and get comfy 🍓
2.5.1. Identification 🪪
the identifiers are taken from PKCS #15 [PKCS15], a standard that covers (among other things) a transparent interface to a certificate/public key store 📚 These identifiers are field proven, since they've been in common use for years, usually through PKCS #11 [PKCS11]. Certificate stores and the identifiers that are required for typical certificate lookup operations get a deep dive in [Gutmann], so go check that out if you're nerdy like me 🤓
The URI identifier type specifies the identifier tied to the certificate's intended usage with a given Internet security protocol. For example, an SSL/TLS server certificate would contain the server's DNS name (this is traditionally also specified as the CommonName or CN) an S/MIME certificate would contain the subject's email address; an IPsec certificate would contain a DNS name or IP address; and a SIP certificate would contain a SIP URI. A modicum of common sense is assumed when deciding upon an appropriate URI field value 🧠✨
For historical reasons going back to its primary use as a means of looking up users' S/MIME email certificates, some clients may specify the URI attribute name as email rather than uri 📧 Although not required by this specification, servers may choose to allow the use of email as an alias for uri. 🎭
In addition, it is common practice to use the Internet identifier associated with the certificate's intended field of application as the CN for the certificate when this is the most sensible name for the certificate subject. For example, an SSL/TLS server certificate will contain the server's DNS name in the CN field. In web-enabled devices, this may indeed be the only name that exists for the device. It is therefore quite possible that the URI will duplicate the CN, and that it may be the only identifier present (that is, there's no full DN but only a single CN field) 💁♀️
By long-standing convention, URIs in certificates are given without a scheme specifier. For example, an SSL/TLS server certificate would contain www.example.com rather than https://www.example.com, and an S/MIME certificate would contain user@example.com rather than mailto:user@example.com. This convention is extended to other URI types as well, so that a certificate containing the (effective) URIs im:user@example.com and xmpp:user@example.com would be queried using the single URI user@example.com. The certificate store would then return all certificates containing this URI, leaving it to the client to determine which one is most appropriate for its use. This approach is taken both because for the most common URI types there's no schema specifier (see the paragraphs above) and no easy way to determine what the intended use is (an SSL/TLS server certificate is simply one presented by an SSL/TLS server), and because the relying party/client is in a better position to judge the certificate's most appropriate use than the certificate store server. the client is the one who knows best, so the client decides 🙌
Another possible identifier that has been suggested is an IP address or DNS name, which will be required for web-enabled embedded devices. This is necessary to allow for example a home automation controller to be queried for certificates for the devices that it controls. Since this value is regarded as the CN for the device, common practice is to use this value for the CN in the same way that web server certificates set the CN to the server's DNS name, so this option is already covered in a widely-accepted manner 🏠💡
The name and email address are an exact copy of what is present in the certificate, without any canonicalisation or rewriting (other than the transport encoding required by HTTP). This follows standard implementation practice, which transfers an exact copy of these data items in order to avoid problems due to character set translation, handling of whitespace, and other issues. no editing the name, no "fixing" the email, we copy it exactly 🫶
Hashes are used for arbitrary-length fields such as ones containing DNs in place of the full field to keep the length manageable. In addition, the use of the hashed form emphasizes that searching for structured name data isn't a supported feature, since this is a simple interface to a {key,value} certificate store rather than an HTTP interface to an X.500 directory. Users specifically requiring an HTTP interface to X.500 may use technology such as HTTP LDAP gateways for this purpose. X.500 searching is not the vibe here 🙅♀️
Although clients will always submit a fixed 160-bit value, servers are free to use as many bits of this value as they require. For example, a server may choose to use only the first 40, 64, 80, or 128 bits for efficiency in searching and maintaining indices. flexible servers are the best servers ✨
PGP has traditionally encoded IDs using a C-style 0xABCDEF notation based on the display format used for IDs in PGP 2.0. Unfortunately, strings in this format are also valid strings in the base64 format, complicated further by the fact that near-misses such as 0xABCDRF could be either a mistyped attempt at a hex ID or a valid base64 ID. For this reason, and to ensure consistency, base64 IDs are used throughout this specification. The search keys used internally will be binary values, so whether these are converted from ASCII-hex or base64 is immaterial in the long run. ugh the ambiguity is so real 😭
The attributes are given shortened name forms (for example, iAndSHash in place of issuerAndSerialNumberHash) in order to keep the lengths reasonable, or common name forms (for example, email in place of rfc822Name, rfc822Mailbox, emailAddress, mail, or email) where multiple name forms exist. short names, same energy 💅
In some cases, users may require additional, application-specific attribute types. For example, a healthcare application that uses a healthcare ID as the primary key for its databases may require the ability to perform certificate lookups based on this healthcare ID. The formatting and use of such application-specific identifiers is beyond the scope of this document. However, they should begin with 'x-' to ensure that they don't conflict with identifiers that may be defined in future versions of this specification. 🏷️ so custom ones get the x- prefix, iykyk
2.5.2. Checking of Input Values 🛡️
⚠️ bestie, this one is serious. The attribute value portion of the identifier should be carefully checked for invalid characters since allowing raw data presents a security risk.
Consider, for example, a certificate/public key store implemented using an RDBMS in which the SQL query is built up as "SELECT certificate FROM certificates WHERE iHash = " + <search key>. If <search key> is set to "ABCD;DELETE FROM certificates", the results of the query will be quite different from what was expected by the certificate store administrators. 💀 Even a read-only query can be problematic; for example, setting <search key> to "UNION SELECT password FROM master.sysxlogins" will list all passwords in an SQL Server database (in an easily-decrypted format) if the user is running under the sa (DBA) account. For this reason, only valid base64 encodings should be allowed. The same checking applies to queries by name or email address. 🙈
Straightforward sanitisation of queries may not be sufficient to prevent all attacks; for example, a filter that removes the SQL query string "DELETE" can be bypassed by submitting the string embedded in another instance of the string. Removing "DELETE" from "DELDELETEETE" leaves the outer "DELETE" in place. Abusing the truncation of over-long strings by filters can also be used as a means of attack, with the attacker ensuring that the truncation occurs in the middle of an escape sequence, bypassing the filtering. Although in theory recursive filtering may help here, the use of parameterised queries (often called placeholders) that aren't vulnerable to SQL injection should be used to avoid these attacks. More information on securing database back-ends may be found in [Birkholz], and more comments on sanitisation and safety concerns may be found in the security considerations section. 🔐 the filter-only approach is NOT it, bestie, use parameterised queries 🫶
2.5.3. URI Notes ✨
Okay so pre-built URIs that fetch a certificate or public key for one fixed search are lowkey iconic for web pages, business cards, or helpdesk staff who want to email someone a link but can't find the cert themselves 💌 🎀. These URIs can also keep things private by mixing up the search key in a way that only the store (or the store and its users) knows, which basically turns the URI into a capability 🔐. For example, a user with a brand-new certificate could be told to fetch it with a key of x-encrCertHash=..., which the store decrypts to find the right certificate. That way only the owner can grab their cert right after it's issued 🥹. Same vibe for an org that doesn't want its certs open to public searching: it could require a MAC on search keys (like x-macCertHash=...) so only authorised users can search 🙅♀️. (Honestly though, if a real web server is sitting in front of the store, the better place for access control is the HTTP level, obviously 💅.)
The query types were picked so this isn't just an HTTP wrapper around LDAP. It's a general-purpose retrieval mechanism that lets basically any certificate or public key storage system be the back-end, with a soft spot for simple {key,value} stores, which are everywhere (ISAM, Berkeley DB, or an RDBMS, take your pick) 🗂️. This spec is deliberately technology neutral, so any {key,value} lookup method works. It honestly doesn't matter if you have trained chimpanzees flipping through books of tables 🐒📖, as long as the method gives the right answer with reasonable efficiency 💖.
Certificate/public key stores and CRL stores get separate URIs because they might be built on totally different mechanisms 🧩. A certificate store usually holds loads of small items, while a CRL store holds a tiny number of potentially huge ones. Separate URIs mean each store can be built on something tailored to its data, which is so smart 🧠✨.
PGP bundles key and revocation info into one data object, so one URI can return both public keys and revocation info 📦. If you've got separate key and revocation servers, that can give a slight performance boost, since fetching revocation info doesn't mean also fetching the key it applies to ⚡. If you don't have separate servers, one server can handle both kinds of query, but with a slight performance hit, because fetching revocation info will also pull back the public key data tied to that revocation 🥲.
2.5.4. Responses 🌸
The ban on exotic encoding forms makes total sense once you realise most clients (and lots of servers, especially on embedded devices) aren't general-purpose web browsers or servers that can handle every encoding and type under the sun 🙃. They're just basic HTTP engines plugged into a key management app. So the HTTP interface is a little add-on to key management, not the other way round 🔑. Cutting unnecessary choices keeps the implementation simple, shrinks the code, and means there's less chance of security problems sneaking in with the extra complexity 🛡️✨.
Sending Accept-encoding: identity would get you the same result as banning extra encodings, and it might actually be useful, because section 14.3 of [RFC2616] says that if this header is missing, any encoding may be taken as allowed 🤔. But it bloats the HTTP header in a way that can hurt performance (see Section 2.5.5), whereas just requiring that responses come back with no extra decoration means nobody has to specify it in every request 💅. So implementations should leave the Accept-encoding header out entirely. If it really has to be there, it should include identity or the wildcard * as an accepted content-encoding type 🎯.
Chunked encoding gets a SHOULD NOT instead of a MUST NOT because [RFC2616] requires support for it 😤. Even so, it's strongly discouraged, because the data (1-2kB) is so small that chunking is totally unnecessary, and supporting it is vulnerable to a bunch of implementation bugs, some of which could affect security 🚨. Here's the tea though: lots of versions of the Apache web server will chunk responses for no reason 🙈. A MUST NOT would be the ideal, but it would make clients that reject chunking incompatible with the world's most popular web server 💀. So support for chunked encoding is strongly discouraged but still permitted. Clients that skip it should know they might run into trouble talking to Apache-based HTTP certificate stores ⚠️.
Multiple responses come back as multipart/mixed instead of an ASN.1 SEQUENCE OF Certificate or a PKCS #7/CMS certificate chain (degenerate signed data that only holds certificates) 📬. The reason is that multipart/mixed is way more straightforward to build with standard web-enabled tools 🛠️. Bonus: it's not tied to DER-based data, so it can be extended to other certificate types like XML, PGP, and SPKI 🌈.
2.5.5. Performance Issues 🚀
When high throughput and performance under load are critical, you can put a main-memory database in between the on-disk database and the HTTP interface, acting like a content cache [Garcia-Molina] 🧠⚡. It gives you the same functionality as an on-disk database and is fully transparent to the HTTP front-end, but it has buffer management and retrieval features tuned for data that lives in memory 💾. If you need even more scalability, the content-caching system could be a cluster of main-memory databases [Ji] 👑.
There are a bunch of network efficiency things to think about when you build this certificate/public key distribution mechanism 🌐. For example, a simple implementation that does two writes (the HTTP header and the certificate, written separately) and then a read will clash badly with TCP delayed-ACK and slow-start 😭. That's because the TCP MSS is usually 1460 bytes on a LAN (Ethernet) or 512/536 bytes on a WAN, while HTTP headers are ~200-300 bytes, way smaller than the MSS 📏. When an HTTP message is first sent, the TCP congestion window starts at one segment, and slow-start doubles it with each ACK 📈. Sending the headers separately means one tiny segment goes out, then a second MSS-sized one, and then the TCP stack waits for the responder's ACK before carrying on ⏳. The responder gets both segments and then holds its ACK for 200ms, hoping to piggyback it on some response data. That data never comes, because it's still waiting for the rest of the HTTP body from the initiator 🫠. Result: there's a 200ms (+assorted RTT) delay in every message sent. Ouch 💔.
Other performance considerations are covered in depth elsewhere [Spero] [Heidemann] [Nielsen], so go read those if you're curious 📚. Also, changes to TCP's behaviour, like 4K initial windows [RFC3390] (designed to get small HTTP transfers done in a single RTT), should help soften some of these issues 🦋.
A rule of thumb for top performance: combine the HTTP header and data payload into a single write. Honestly any reasonable HTTP implementation does this already, thanks to all the experience people have had tuning HTTP server performance 🙌. Also keep the HTTP headers minimal so the data fits within the TCP MSS. And since this protocol doesn't involve a web browser, there's no reason to include browser-type headers like ones describing software versions or acceptable languages 🧁.
2.5.6. Miscellaneous 🎀
The interface in this document is a basic read-only type, and it's what most clients will use 📖. Updates (both insertion and deletion) are a whole complicated situation 😵💫. On the technical side, a bunch of indexing and retrieval fields would need a technology-neutral spec, or the certificate store would have to parse each item being added itself, which turns a near-universal key=value lookup into a full public-key/certificate processing system 🧱. On the political side, the question is who gets to update the store, and under what conditions? 🤷♀️. Because it's so messy, the details of any update mechanism are left as a local configuration issue. They might get covered in a future document if enough people ask for it 📝💜.
People have raised concerns about using HTTP as a substrate [RFC3205] 🤨. The mechanism here is a straightforward request/response protocol with the same semantics as traditional HTTP requests, so it isn't affected by those issues 🙌. It doesn't implement any kind of complex RPC mechanism, it doesn't require HTTP security measures, and firewalls don't affect it, since it only uses a basic HTTP GET rather than layering a new protocol on top of HTTP 🔥. It also uses well-defined MIME media types from standards documents. So the concerns raised in [RFC3205] don't apply here 💅. Also, although a number of servers still don't fully support some of the more advanced features of HTTP 1.1 [Krishnamurthy], the minimal subset used here is well supported by most servers and HTTP implementations 🫶.
This access mechanism is similar to the PGP HKP protocol [HKP]. The catch is that HKP is almost entirely undocumented, so implementors have to reverse-engineer other implementations 😩. Because of that lack of standardisation, no effort was made to ensure interoperability or compatibility with HKP-based servers, though PGP developers gave a lot of really valuable input for this document 🙏. HKP does have one perk: lots of implementation experience. That suggests this is a very workable solution to the problem of simple certificate/public key retrieval 🌟. HKP servers have been built on flat files, Berkeley DB, and various databases, like Postgres and MySQL 🐘🍓.
2.6. Examples ✨
okay so let's make a search key 💖 To convert the subject DN C=NZ, O=... CN=Fred Dagg into one, you hash the DN in the DER-encoded form it shows up in within the certificate 🎀 That gives you:
96 4C 70 C4 1E C9 08 E5 CA 45 25 10 D6 C8 28 3A 1A C1 DF E2Then you Base-64 encode that to get:
lkxwxB7JCOXKRSUQ1sgoOhrB3+I(notice there's no trailing = padding 🙈) and that's your search key to pop into the query URI ✨
To fetch all the certificates useful for sending encrypted email to foo@example.com, the request is:
GET /search.cgi?email=foo%40example.com HTTP/1.1(For simplicity, the extra Host: header that [RFC2616] asks for is left out here and in the following examples 💅) In this case, /search.cgi is the abs_path portion of the query URI, and the request goes to the server at the net_loc portion of the query URI. Also, check out how the '@' symbol gets encoded as per [RFC2854] 😭 The other required headers, like the "Host" header that HTTP 1.1 needs, are omitted so it stays clean and readable 🫶
Now the chaining queries, bestie 🦋 To grab the CA certificate that issued the email certificate:
<Convert the issuer DN to a search key>
GET /search.cgi?sHash=<search key> HTTP/1.1Or, if chaining is done by key identifier:
<Extract the keyIdentifier from the authorityKeyIdentifier>
GET /search.cgi?sKIDHash=<search key> HTTP/1.1To fetch other certificates belonging to the same user as the email certificate:
<Convert the subject DN to a search key>
GET /search.cgi?sHash=<search key> HTTP/1.1To fetch the CRL for the certificate:
<Convert the issuer DN to a search key>
GET /search.cgi?iHash=<search key> HTTP/1.1Heads up: since the differentiator is the URI base, the above two queries look identical (the URI base isn't shown) but they are actually totally distinct 💀
And if you want to retrieve a key using XML methods, the <KeyName> (which holds the string identifier for the key) used with the subject DN hash from above would be:
<KeyName KeyID="sHash">lkxwxB7JCOXKRSUQ1sgoOhrB3+I</KeyName>.3. Locating HTTP Certificate Stores 🧚
okay so how do relying parties actually find these servers? 👑 They can use one or more of these strategies:
- Information contained in the certificate
- Use of DNS SRV
- Use of a "well-known" location
- Manual configuration of the client software
The whole goal is making certificate store access as transparent as possible ✨ so users only have to configure things manually as a last resort 💅
3.1. Information in the Certificate
To give relying parties a well-known spot for info access, CAs SHOULD use the SubjectInfoAccess (SIA) and AuthorityInfoAccess (AIA) extension [RFC3280] in their certificates 🎀 The OID value for the accessMethod is one of:
id-ad-http-certs OBJECT IDENTIFIER ::= { id-ad 6 }
id-ad-http-crls OBJECT IDENTIFIER ::= { id-ad 7 }where:
id-ad OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
pkix(7) 48 }The corresponding accessLocation is the query URI 🦋 This gives a CA a convenient, standard place to point to where more certificates can be found, for example for certification path construction. And fyi, providing certificate store access isn't limited to CAs only 💖
3.2. Use of DNS SRV
DNS SRV is a facility for specifying the location of the server(s) for a specific protocol and domain [RFC2782] 🌸 For the certificate store interface, the DNS SRV symbolic name SHALL be "certificates". The name for the CRL store interface SHALL be "crls". The name for the PGP public key store SHALL be "pgpkeys". The name for the PGP revocation store SHALL be "pgprevocations". Handling of extra DNS SRV stuff, like the priority and weight fields, is as per [RFC2782] 🫶
3.2.1. Example
Say a CA with the domain example.com wants its certificates available via an HTTP certificate store interface. The server details could be found by looking up:
_certificates._tcp.example.comand
_crls._tcp.example.comThat returns the server(s) and port(s) for the service as specified in [RFC2782] ✨
3.3. Use of a "well-known" Location
If no other location info is available, the certificate store interface may be located at a "well-known" location built from the service provider's domain name 💅 Usually, the URI is made by prepending the type of info being retrieved ("certificates.", "crls.", "pgpkeys.", or "pgprevocations.") to the domain name to get the net_loc portion, and by appending the fixed abs_path portion "search.cgi". So the URI form of the "well-known" location is:
certificates.<domain_name>/search.cgi
crls.<domain_name>/search.cgi
pgpkeys.<domain_name>/search.cgi
pgprevocations.<domain_name>/search.cgiCertificate store service providers SHOULD use these URIs in preference to other alternatives 🌈 Also, using "search.cgi" does not imply the use of CGI scripts [RFC3875]. That would be the exception rather than the rule, since it would lead to a pretty inefficient implementation 🙈 It just gives one possible (and relatively simple to set up) implementation option (see the rationale for more on this) 🧚
There's a second case too, when the certificate access service is provided by web-enabled embedded devices, like Universal Plug and Play devices [UPNP] 🏠 These devices have a single, fixed net_loc (either an IP address or a DNS name) and offer services over an HTTP interface. Here, the URI is built by appending the fixed abs_path portion "certificates/search.cgi" for certificates, "crls/search.cgi" for CRLs, "pgpkeys/search.cgi" for PGP public keys, and "pgprevocations/search.cgi" for PGP revocation information to the net_loc. The URI form of the "well-known" location is therefore:
<net_loc>/certificates/search.cgi
<net_loc>/crls/search.cgi
<net_loc>/pgpkeys/search.cgi
<net_loc>/pgprevocations/search.cgiIf the device implements certificate access as described in this document, then it SHOULD use these URIs in preference to other alternatives (see the rationale for more on this requirement) 💜
3.3.1. Examples
If a CA with the domain example.com makes its certificates available via an HTTP certificate store interface, the "well-known" query URIs for certificates and CRLs would be:
http://certificates.example.com/search.cgi
http://crls.example.com/search.cgiA home automation controller with the IP address 192.0.2.1 (a control point in UPnP terminology) would make certificates for devices like HVAC controllers, lighting and appliance controllers, and fire and physical intrusion detection devices available as:
http://192.0.2.1/certificates/search.cgi
http://192.0.2.1/crls/search.cgiA print server with the DNS name "printspooler" would make certificates for web-enabled printers that it talks to available as:
http://printspooler/certificates/search.cgi
http://printspooler/crls/search.cgi3.4. Manual Configuration of the Client Software
The accessLocation for the HTTP certificate/public key/CRL store MAY be configured locally at the client 🎀 This is useful if no other information is available, or if it's necessary to override other information 🫶
3.5. Implementation Notes and Rationale 🌸
This informative section documents the rationale behind the design in Section 3 and gives guidance for implementors 💅
3.5.1. DNS SRV
The optimal solution for service location would be DNS SRV 🙄 Unfortunately, the operating system used by the user group most desperately in need of this kind of handholding has no support for anything beyond the most basic DNS address lookups. That makes it impossible to use DNS SRV with anything but very recent Win2K and XP systems 💀 To make things even more chaotic, several function names and some function parameters changed at various points during the Win2K phase of development, and the behaviour of portions of the Windows sockets API changed in undocumented ways to match 😭 So you get this messy situation where a Unix sysadmin can use DNS SRV to avoid technical configuration issues, but a Windows'95 user can't. Because of these problems, there's an alternative to DNS SRV for situations where DNS SRV can't be used 🦋
The SRV or "well-known" location option can often be derived automatically by user software from parameters it already knows ✨ For example, if the recipient's email address is @example.com, the user software would query _certificates._tcp.example.com or go to certificates.example.com and request the certificate. User software may also keep a list of known certificate sources, the same way browsers maintain lists of known CAs 🌈 The specific mention of support for redirection in Section 2 shows that lots of sites will outsource the certificate-storage task 💖 At worst, all that's needed is adding a single static web page that points to the real server 🧚 Alternatives like DNS CNAME RRs are possible too, but they may not be as easy to set up as HTTP redirects (corporate policies tend to be more flexible about web page contents than about modifying DNS configurations) 👑
3.5.2. "well-known" Locations
The "well-known" location URI is designed to make hosting options as flexible as possible 🌷 Locating the service at www.<domain name> would generally require it to be handled by the provider's main web server, while a distinct server URI lets the provider handle it however they like 🎀 Sure, there will no doubt be servers that implement the interface using Apache and Perl scripts, but a more logical implementation would be a simple network interface to a key-and-value lookup mechanism, such as Berkeley DB 🤓 The URI form presented in Section 3.3 gives maximum flexibility, since it works with both web servers/CGI scripts and non-web-server-based network front-ends for certificate stores 💜
3.5.3. Information in the Certificate ✨
okay so, if your setup needs nonstandard locations, ports, or HTTPS instead of HTTP but you still want "well-known" locations, it should use an HTTP redirect at the "well-known" spot to point at the nonstandard one 🎀. For example, if the print spooler in Section 3.3 used an SSL-protected server called printspooler-server with an abs_path portion of cert_access, it would use an HTTP 302 redirect to https://printspooler-server/cert_access 🦋. This gives you the plug-and-play magic of "well-known" locations plus the freedom to use nonstandard locations and ports. literally the best of both worlds 💅
Now the SIA and AIA extensions are used to show the location of the CRL store interface, NOT the CRLDistributionPoint (CRLDP) extension, because they do totally different jobs 🙈. A CRLDP holds "a pointer to the current CRL", which is a fixed spot with a CRL for the current certificate. The SIA/AIA extension says "how to access CA information and services for the subject/issuer of the certificate in which the extension appears", and in this case that's the CRL store interface that hands out CRLs for any certificates the CA issued 🌸. CRLDP also attaches other attribute info to a query, which doesn't mesh with the simple query mechanisms in this document. not compatible, bestie 💀
A single server can handle both CRLDP and AIA/SIA queries, as long as the CRLDP form uses an HTTP URI ✨. Since CRLDP points to one static location for a CRL, a query can be pre-built and stored in the CRLDP extension. Software using CRLDP grabs the single CRL that applies to its certificate from the server, and software using AIA/SIA can grab any CRL from the server 🧚. Pre-built URIs like these can also be handy in other places (like links on web pages), placed in spots such as the issuerAltName, or even emailed by tech support or helpdesk staff to users who can't find the certificate themselves, as described in Section 2.5 💌. When the user clicks the resulting certstore URL, it directly accesses the certificate in any certificate-aware app, like a browser or mail program. it's giving effortless 🫶
3.5.4. Miscellaneous 🌈
Web-enabled (or, more strictly, HTTP-enabled) devices are meant to be plug-and-play, with minimal (or no) user configuration needed 🍓. The "well-known" URI lets any known device (for example, one found via UPNP's Simple Service Discovery Protocol, SSDP) be queried for certificates without any extra user configuration. Lowkey fun fact: in practice no embedded device would ever use the address in the example, since the de facto standard address for web-enabled embedded devices is 192.168.1.x and not 192.0.2.x. IETF policy just requires this non-address for examples 🙈💜.
Protocols like UPnP have their own ways of sharing device and protocol info 🔥. For example, UPnP uses SOAP, which provides a GetPublicKeys action for pulling device keys and a PresentKeys action for pushing control point keys. The text in Section 3.3 is NOT trying to say this document overrides the existing UPnP mechanism. It just means that if a device implements the mechanism described here, it should use the naming scheme in Section 3.3 instead of making up arbitrary names 👑.
4. Security Considerations 🔐
okay bestie, serious moment incoming 😭. HTTP caching proxies are everywhere on the Internet, and some of them may not check for the latest version of an object correctly. [RFC2616] specifies that responses to query URLs should not be cached, and most proxies and servers correctly implement the Cache-Control: no-cache mechanism, which can be used to override caching (Pragma: no-cache for HTTP 1.0). BUT in the rare case that an HTTP request for a certificate or CRL goes through a misconfigured or otherwise broken proxy, the proxy may return an out-of-date response 💀.
Care should be taken to make sure only valid queries get fed through to the back-end used to retrieve certificates 🛡️. Letting attackers submit arbitrary queries may let them mess with the certificate store in unexpected ways if the back-end tries to interpret the query contents. Picture this: a certificate store is built on an RDBMS, and the calling app assembles a complete SQL string for the query like "SELECT certificate FROM certificates WHERE iHash = " + <search key>. If <search key> is set to "X;DELETE FROM certificates", the results will be totally different from what the certificate store administrator expected 😱. The same goes for queries by name and email address. Even read-only queries can be a problem. For example, setting <search key> to "UNION SELECT password FROM master.sysxlogins" will list all passwords in an SQL Server database (in an easily decrypted format) if the user is running under the sa (DBA) account 🙀. Straightforward sanitisation of queries may not be enough to stop every attack. For instance, a filter that removes the SQL query string "DELETE" can be bypassed by submitting the string embedded in another instance of the string. Removing "DELETE" from "DELDELETEETE" leaves the outer "DELETE" in place 🤯. Abusing the truncation of over-long strings by filters can also be used as an attack, where the attacker makes sure the truncation happens in the middle of an escape sequence, which bypasses the filtering. Parameterised queries (often called placeholders) that aren't vulnerable to SQL injection should be used to avoid these attacks 💅.
Also, since some query data may be encoded or decoded before it gets sent to the back-end, applications should check both the encoded and decoded form for valid data 🎀. A simple way to dodge these problems is to use parameterised commands instead of hand-assembling SQL strings for queries (this is also more efficient for most database interfaces). With parameterised commands, the query value is never in any position where it could be read as part of the query command ✨.
Alongside filtering queries, the back-end should be configured to disable any form of update access via the web interface 🔒. For Berkeley DB, you can impose this restriction by opening the certificate store in read-only mode from the web interface. For relational databases, it can be imposed through the SQL GRANT/REVOKE mechanism. For example, "REVOKE ALL ON certificates FROM webuser. GRANT SELECT ON certificates TO webuser" will allow read-only access of the appropriate kind for the web interface 🌷. Server-specific security measures can also be used. For example, SQL Server provides the built-in db_datareader account, which only allows read access to tables (but see the note above about what can be done even with read-only access), and the ability to run the server under a dedicated low-privilege account (a standard feature of Unix systems) 🐧.
The mechanism in this document is NOT meant to work as a trusted directory/database 🚫. Users should not assume that just because they fetched a public key or certificate from an entity claiming to be X, X has made any statement about the veracity of that public key or certificate. Using a signed representation of the stored items removes the need to depend on the certificate store for any security service other than availability 🧾. It's possible to build a trusted directory/database using HTTPS or some other secured/trusted link, but that's a local policy/configuration issue. Without those extra security measures, users should apply appropriate levels of verification to any keys or certificates fetched before they take them into use 🫶.
5. IANA Considerations 📋
No action by IANA is needed 🌸. The AIA/SIA accessMethod types are identified by object identifiers (OIDs) from an arc managed by the PKIX working group. If additional accessMethods get introduced (for example, for attribute certificates or non-X.509 certificate types), the advocates for those accessMethods are expected to assign the necessary OIDs from their own arcs 🧚.
6. Acknowledgements 💖
Anders Rundgren, Blake Ramsdell, Jeff Jacoby, David Shaw, and members of the ietf-pkix working group gave useful input and feedback on this document 🫶.
7. References 📚
7.1. Normative References 🌟
- [FIPS180] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
- [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
- [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
- [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
- [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000.
- [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
- [RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
- [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
- [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
7.2. Informative References 📚✨
okay bestie, this is the background reading list 🤓📖 these are here for context, and each one has its own citation tag so you can find it fast.
- [Birkholz] "Special Ops: Host and Network Security for Microsoft, Unix, and Oracle", Erik Birkholz et al, Syngress Publishing, November 2002. 🔐
- [Garcia-Molina] "Main Memory Database Systems", Hector Garcia-Molina and Kenneth Salem, IEEE Transactions on Knowledge and Data Engineering, Vol.4, No.6 (December 1992), p.509. 🧠
- [Gutmann] "A Reliable, Scalable General-purpose Certificate Store", P. Gutmann, Proceedings of the 16th Annual Computer Security Applications Conference, December 2000. 🗄️
- [Heidemann] "Performance Interactions Between P-HTTP and TCP Implementations", J. Heidemann, ACM Computer Communications Review, April 1997. 🐢
- [HKP] "A PGP Public Key Server", Marc Horowitz, 2000,
http://www.mit.edu/afs/net.mit.edu/project/pks/thesis/paper/thesis.html. A more complete and up-to-date overview of HKP may be obtained from the source code of an open-source OpenPGP implementation such as GPG. 🔑 - [Ji] "Affinity-based Management of Main Memory Database Clusters", Minwen Ji, ACM Transactions on Internet Technology, Vol.2, No.4 (November 2002), p.307. 🗂️
- [Krishnamurthy] "PRO-COW: Protocol Compliance on the Web - A Longitudinal Survey", Balachander Krishnamurthy and Martin Arlitt, Proceedings of the 3rd Usenix Symposium on Internet Technologies and Systems (USITS'01), March 2001, p.109. 🕸️
- [Nielsen] "Network Performance Effects of HTTP/1.1, CSS1, and PNG", H.Nielsen, J.Gettys, A.Baird-Smith, E.Prud'hommeaux, H.Wium Lie, and C.Lilley, 24 June 1997,
http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html🌐 - [PKCS11] PKCS #11 Cryptographic Token Interface Standard, RSA Laboratories, December 1999. 🪙
- [PKCS15] PKCS #15 Cryptographic Token Information Syntax Standard, RSA Laboratories, June 2000. 🪪
- [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002. 🌸
- [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002. 🪟
- [RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface (CGI) Version 1.1", RFC 3875, October 2004. ⚙️
- [Spero] "Analysis of HTTP Performance Problems", S.Spero, July 1994,
http://www.w3.org/Protocols/HTTP/1.0/HTTPPerformance.html. 📈 - [UPNP] "Universal Plug and Play Device Architecture, Version 1.0", UPnP Forum, 8 June 2000. 🔌
Author's Address 🖋️
Peter Gutmann
University of Auckland
Private Bag 92019
Auckland, New Zealand
EMail: pgut001@cs.auckland.ac.nzFull Copyright Statement ©️
Copyright (C) The Internet Society (2006). 💜
This document is subject to the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights. 🫶
This doc and the info in it are provided "AS IS". ⚠️ The contributor, the organization they represent or are sponsored by (if any), the Internet Society and the IETF all disclaim every warranty, express or implied, including but not limited to any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. 🙈
Intellectual Property 🦋
The IETF takes no position on whether any Intellectual Property Rights (or other rights) that might be claimed to cover the technology in this document are valid or how far they reach, and it doesn't say whether any license under those rights is or isn't available. It also doesn't claim to have independently searched for any such rights. 🔍 For the procedures around rights in RFC documents, check out BCP 78 and BCP 79. 📜
Copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses to be made available, or the results of any attempt to get a general license or permission to use proprietary rights for implementers or users of this spec, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. 🗃️
The IETF invites anyone to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. 💌 Send that info to the IETF at ietf-ipr@ietf.org. ✉️
Acknowledgement 🌈
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🎀💖
📦 where this page comes from
- ietf: rfc4387 2006-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms