arXiv:1906.10775v2 [cs.CR] 20 Apr 2020 etfiaeslfsa.Mroe,asaldcertificate stapled over a contacted Moreover, frequently lifespan. be certificate’s must a they as author- (CAs) certification ities on reliance an and places addresses burden CRLs, additional [39] like but, stapling problem OCSP extra-round-trip of the [34]. sets [25], soft- through small updates clients ware upon to rely pushed instead revocations (i.e., and emergency checks OCSP) revocation and online CRL disable to decided security. have jeopardizing revoked, is certificate check- a not if to equivalent ing effectively re- con- the is a with anyway) receive proceeding nection (i.e., to open fails Failing block [47]. browser also sponse the may when trip users’ connection round reveals the extra and The valid- delay habits. certificate’s browsing page-load a increases verify This to ity. browser the communication by round-trip extra initiated making an revocations, require and [35] of CRLs OCSP inefficient. number browsers to the communication their in [59] [12], linearly (CRLs) grow PKI, lists revocation web Certificate (or short). infrastructure for public-key HTTPS the in Introduction 1. (CDN) network content-delivery cate, certifi- proxy revocation, delegation, certificate, ital Terms Index problems. pressing system several solve revocation proxy would appropriate or com- an credentials with that certificates show delegated also short-lived We bining schemes. X.509 delegation a the and revocation propose characterizing (i.e., we for that framework trust purpose, approaches 19-criteria this of For on chain path). focus certification the a with affect PKI, directly shortcomings web the revocation of and delegation standing as parties. such third practices with keys dangerous private their in sharing engage delegation to native domain owners a leads increasingly of which TLS, lack in mechanism the problems by These exacerbated are problems. latency, privacy from or suffer availability, public- traditional schemes any most revocation of certificate security Regrettably, the infrastructure. to key critical is key mised Abstract arn Chuat Laurent ie h bv rbes oebosrvendors browser some problems, above the Given challenge a been always has revocation Certificate long- the address that solutions analyze We Teaiiyt ucl eoeacompro- a revoke quickly to ability —The pbi-e nrsrcue(K) dig- (PKI), infrastructure —public-key ∗ beRha Abdou AbdelRahman , h isn ik nteWbsCano Trust of Chain Web’s the in Links Missing the o:Dlgto n Revocation, and Delegation SoK: † colo optrSine altnUniversity Carleton Science, Computer of School ∗ eateto optrSine T Zurich ETH Science, Computer of Department † afSasse Ralf , ∗ (R2) (R1) rmoredao oietf ouin aifigthe satisfying solutions identify to endeavor our from osbeslto.Dmi wessol eal to able any be for should requirements owners autonomously Domain two thus solution. full We following possible subdomains. in its the them and leaves formulate domain that their of solution control secure and subdomains? flexible their of key any and to revocation, perform renewal, they issuance, update every for CA a fundamen- question: following the tal ask on therefore We depend must support. heavily CA or they approaches needs, insecure revocation adopt either and sat- delegation to their position: isfy uncomfortable an into owners be domain observed. could is keys revoca- misbehavior as compromised secure soon as and as sharing invalidated minimized efficient key revocation. of be an consequences of would negative on that the rely system, to tion could related we problem intimately delegation If fact, The sys- [9]. in sharing delegation is, to key resort of often secure form owners domain some delegating a CDNs, explicitly to than for rights rather specific practice, beg In In [29]. and PKI. tem web now used are the (CDNs) widely networks for delivery emerged content particular, have problems [30]. ciated revocation certificate to comes it when Un- over efficiency security established. favor well often vendors now browser fortunately, is and security) efficiency round-trip system’s sacrificing extra the (but increasing an and CAs) (requiring tradeoff burdening browsers the informa- to general, revocation tion case In disseminating sev- in promptly compromise. to capabilities between key adversarial period private limit this of to reducing minutes of eral feasibility the the however, is remain, days about Questions four period. Again, validity stapling. suggested OCSP to benefits ble case; worst severe. the be in thus days can four us- consequences for remains the adversary key the private by compromised rogue able a a implying days, or four certificate for valid typically is status hitp Sprenger Christoph , u ytmtzto fkoldehsresulted has knowledge of systematization Our norve,dmi wessol eoee a offered be should owners domain view, our In put has landscape HTTPS the of evolution This asso- with requirements new revocation, Besides compara- provide [55] [42], certificates Short-lived ate,wtotsaigapiaekywt them. with key third private to a privileges sharing their without of parties, subset a or and all delegate certificates; own status their revocation or of period validity the on decide h r oanonr eurdt visit to required owners domain are Why ∗ ai Basin David , ∗ dinPerrig Adrian , ∗ above two requirements. We start by providing back- other schemes to satisfy the requirements and offer ground on delegation to CDNs (Section 2) to show additional properties. Finally, in Section 9, we discuss how the web and its trust model have evolved in related topics, and we draw conclusions in Section 10. recent years. We then review a wide spectrum of The main contributions of our work are to sys- approaches to revocation and delegation with differ- tematize existing work and suggest new solutions and ent features and trade-offs (Section 3). We divide directions in this important problem domain: revocation schemes into four categories, depending on • After segmenting revocation schemes into 4 cate- which actor provides the revocation information, and gories, we provide a detailed analysis of 19 dele- we distinguish delegation schemes with and without gation and revocation schemes with respect to 19 key sharing. We also highlight several problems of evaluation criteria. these approaches, showing why they fail to fully sat- • As those schemes offer a wide set of comple- isfy the requirements. Next, we examine different ap- mentary features, we examine how they can be proaches that extend the traditional chain of trust and combined so that both the requirements are met. promise to bring more security and flexibility to the • We show how proxy certificates can be adapted to HTTPS ecosystem (Section 4). These include name today’s web, and present three use cases for such constraints, short-lived certificates, proxy certificates, certificates. and delegated credentials. We focus on the latter two, • Finally, we point out that session resumption may proxy certificates and delegated credentials, as the undermine the security advantages provided by most promising candidates for satisfying the require- short-lived credentials, and we discuss potential ments and discuss them in more detail in Sections 5 workarounds. and 6. We refer readers who are not familiar with the The concept of proxy certificates was introduced HTTPS ecosystem to Durumeric et al. [15] or Clark more than a decade ago in the context of grid com- and van Oorschot [10] for background information. puting [56]. Proxy certificates allow entities holding non-CA certificates to delegate some or all of their privileges to other entities. We thoroughly investigate 2. Delegation to CDNs the challenges and advantages of such delegation in the context of the current web PKI. Allowing such dele- Content delivery networks (CDNs) pose new chal- gation would provide several security and efficiency lenges for the web PKI, as they fundamentally alter advantages. These include a domain owner’s ability the trust model upon which HTTPS relies [29]. Every to update and use multiple distinct keys (e.g., for CDN is composed of a myriad of servers that dis- multiple subdomains, or for different transactions per tribute content to users based on their location. The subdomain) much more easily and rapidly than with objective is usually to increase performance and avail- current practices. Domain owners can also issue short- ability, but CDN vendors may also provide security- lived proxy certificates for added security. Perhaps related services. The caching servers controlled by the more importantly, the owner’s main private key, corre- CDN, commonly referred to as edge servers, act as sponding to the public key in the CA-issued certificate, intermediaries between clients and the origin server need not be involved in online cryptographic opera- (controlled by the domain owner). At the moment, tions, and could thus be safely stored on a discon- this communication model is incompatible with TLS, nected (air-gapped) device. Additionally, proxy certifi- which was specifically designed to prevent man-in-the- cates need not be logged by Certificate Transparency middle (MitM) attacks, and may force domain owners servers, solving the problem of log servers disclosing to share their private key with the CDN operator who private subdomains [17], [48]. then acts as a MitM. More recently, another promising approach called Multiple options exist for redirecting HTTP re- delegated credentials was developed at the IETF quests to CDN servers. The most common techniques and described in an Internet Draft [3] as a first are the following: step towards standardization. On 1 November 2019, • Authoritative: The CDN’s name servers are de- Mozilla [22], Cloudflare [50], and Facebook [21] an- fined as authoritative for the domain in ques- nounced plans to support delegated credentials. We tion. This lets the CDN take full control over describe and study this new proposal in comparison the resolution of the entire domain. When try- to similar approaches, proxy certificates in particular. ing to contact example.com, the browser should In Section 7, we analyze the consequences of using obtain the IP address of one of the CDN’s edge short-lived certificates and investigate how TLS should servers. As the redirection happens through DNS, handle these certificates. the browser will attempt to establish a connec- In Section 8, we thoroughly analyze the different tion based on a valid certificate for example.com; approaches to revocation and delegation. We propose a therefore, the edge server must know the corre- 19-criteria framework, which includes criteria pertain- sponding private key. ing to delegation, revocation, security, efficiency, and • CNAME: The redirection is done through a deployability. We use this framework to evaluate and DNS Canonical Name (CNAME) record, which compare 19 delegation schemes, revocation schemes, allows for a more fine-grained mapping as it sup- and related certificate features. We show how dele- ports the redirection of specific subdomains. For gated credentials and proxy certificates fit into the example, such a record could specify the following bigger picture and how they can be combined with mapping: s1.example.com → s1.example.com.cdn.net Category II: server-driven. OCSP stapling [39] As in the previous case, if the browser tries to allows the web server to add a timestamped OCSP contact s1.example.com, then it will expect to response (signed by the corresponding CA) to the TLS see a valid certificate for it. handshake. Unfortunately, OCSP stapling is ineffec- • URL rewriting: The URLs of specific resources tive unless the browser knows when to expect a stapled (e.g., images, videos, documents) are modified response, as an attacker could just not include any (either automatically by the web server, or man- OCSP status when using a revoked certificate. The ually by the domain owner) so that they point must-staple extension [19] addresses this issue but has to CDN servers. This is the most fine-grained yet to gain widespread support. PKISN [53] tackles approach but it has drawbacks: URL rewriting another problem: collateral damage resulting from the does not support common security features that revocation of the certificate of a large CA, i.e., the the CDN may offer, such as DDoS protection and sudden invalidation of all certificates previously signed web application firewalls. Delegation plays a less by this CA, which should be unaffected. This requires significant role in this scenario, as the browser can all certificates to be timestamped by a verifiable log accept the CDN’s own certificate. server, whereby CA certificate revocations can be per- We classify schemes with respect to delegation by formed effective from a specific point in time, not whether it is supported in any (possibly insecure) affecting previously issued certificates. Although the way, and whether it is possible without requiring key authors [53] note that PKISN could also be deployed sharing, as necessary by Requirement R2. with a vendor-driven model, we will consider its main deployment model as one where servers deliver the revocation status to browsers with an OCSP-stapling- 3. Dealing with Key Compromise like mechanism.

We now review a vast range of techniques devel- Category III: vendor-driven. We identified three oped to prevent, detect, and remedy the compromise main examples of vendor-driven revocation schemes. of private keys. The schemes we present will be com- CRLSets [25] and OneCRL [34] are, respectively, pared in our systematic analysis in Section 8. Google’s and Mozilla’s effort to push a minimal set of critical revocations to their browsers. CRLite [26], 3.1. Revocation based on the same approach of disseminating revoca- tions through software updates, uses Bloom filters to Certificate revocation is a notoriously challenging efficiently represent a larger number of revocations. aspect of the web PKI [30]. In recent years, researchers have examined the question of how revocations should Category IV: middlebox-driven. This category of be delivered to clients, with objectives such as effi- schemes follows the observation that the communi- ciency, deployability, and privacy in mind. For this cation and storage burden incurred by revocations reason, we classify revocation schemes based on the de- can be carried by a single device for multiple hosts. livery process. Specifically, we distinguish four types of RevCast [45] propagates revocations over FM radio revocation schemes: client-driven, where the browser using the RDS protocol. An RDS-to-LAN bridge then establishes an out-of-band connection with a revoca- delivers revocations to end hosts. In a similar vein, tion provider; server-driven, where the TLS server RITM [52] relies on a network device on the client– attaches a recent revocation status to the connec- server path to deliver revocations to end hosts by tion; vendor-driven, where browser vendors push re- analyzing and appending relevant information to TLS vocations to clients through software updates; and handshakes. middlebox-driven, where network devices deliver revo- cations. Our selection of schemes is not intended to be 3.2. (Revocable) Delegation comprehensive; we instead seek to present a few promi- nent examples in each category to help the reader As we describe in Section 2, in most deploy- understand and further classify alternative schemes. ment models, hosting providers (such as CDNs) need browser-accepted certificates for the domains they Category I: client-driven. A traditional certificate serve. This often leads to key sharing [9], [29], which revocation list (CRL) [12] simply contains a set of can take various forms. In its simplest form, key shar- revocations typically recorded by a CA. The distri- ing consists of having the domain owner directly up- bution point of such a list can be specified within load its private key(s) to the hosting provider (through each certificate. A client may fetch the entire list a web interface, for example). Alternatively, the host- (which can grow quite large) from that distribution ing provider may use a certificate with a subject alter- point when establishing a TLS connection. OCSP [35] native name (SAN) list containing domain names from improves upon this design by letting clients contact a numerous distinct customers. Such certificates raise a special responder to determine the status of any spe- number of questions. Cangialosi et al. [9] refer to these cific certificate. Both approaches suffer from latency as “cruise-liner” certificates, and ask: and privacy issues. This is due to the fact that an extra “Who on a cruise-liner certificate deserves ac- connection must be established to the CRL issuer or cess to the certificate’s corresponding private OCSP responder, revealing to that third party which key, given that whoever has it can imperson- domain the user is visiting. ate all others on the certificate? Who among them has the right to revoke the certificate, constraint is specified as a fully qualified domain if so doing potentially renders invalid a cer- name and may specify a host. For example, as tificate the others rely on? Cruise-liner cer- indicated in RFC 5280, both “host.example.com” tificates are not covered explicitly by X.509, and “my.host.example.com” would satisfy the “.exam- but we can infer that, in all likelihood, only ple.com” constraint, but “example.com” would not. the hosting provider has the private keys and Unfortunately, this mechanism suffers from limited right to revoke.” support and implementation issues. Liang et al. [29] Because X.509 certificates do not natively sup- report that major browsers do not check name con- port explicit delegation, researchers and practitioners straints, except for Firefox. Even when they check have proposed different approaches that would allow name constraints, a limitation of the standard [12] domain owners to use proxies (CDNs, in particular) can allow a dishonest intermediate CA (normally re- without any key sharing. Keyless SSL [49] (developed stricted by a name constraint) to issue certificates for by CloudFlare) splits the TLS handshake so that most arbitrary domain names that is not caught by the of the connection establishment is handled by edge browser’s enforcement. servers, while operations requiring the domain’s pri- Short-lived certificates [55] reduce the attack win- vate key are delegated to a key server maintained by dow after a key compromise but require CA support. the domain owner. Keyless SSL is compatible with This places an extra burden on those CAs; the burden both RSA and Diffie-Hellman handshakes. In RSA increases with shorter expiry windows, imposing mini- mode, the key server decrypts the premaster secret mum length of certificates’ validity periods. Self-signed (generated and encrypted by the browser using the do- certificates, in contrast, allow domain owners to both main’s public key) and sends it back to the edge server delegate and select their attack window, but require over an encrypted channel. In the Diffie-Hellman case, trust on first use (TOFU) or an authenticated, out-of- the edge server sends a hash of parameters and nonces band transmission of the self-signed root certificate. to the key server, which the key server signs and returns. The protocol was analyzed in a cryptographic 3.4. Certificate Transparency model [5] where new attacks show that Keyless SSL, as specified for TLS 1.2, does not meet its intended secu- The Certificate Transparency (CT) framework [27] rity goals. Additionally, a new design for Keyless SSL was developed by Google in response to several cases for both TLS 1.2 and TLS 1.3 is given, together with of CA compromise that resulted in the issuance of a proof of security. In their design, session resumption illegitimate certificates for high-profile domains, in- is forbidden except in special cases. cluding *.google.com [40]. The objective of CT is to SSL splitting [28] is an older but similar technique make certificates publicly visible. To do so, CT relies with the additional guarantee that data served by the on append-only log servers that anyone can consult. proxy server is endorsed by the origin server. This To make the logging process verifiable, certificates are is achieved by requiring the origin server to com- incorporated into a Merkle hash tree, which allows pute message authentication codes: for each record, log servers to produce efficient proofs of presence the origin server sends the MAC and a short unique and consistency. When a certificate is submitted to identifier that the proxy server uses to look up the cor- a log server—provided that the certificate is rooted responding payload in its local cache. Unfortunately, in an accepted trust anchor—the log will reply with a this approach limits the benefits of using a CDN as Signed Certificate Timestamp (SCT). This constitutes it increases latency (even more so than Keyless SSL, a promise that the certificate is already or will be which only affects the initial handshake). incorporated into the hash tree within a predefined Liang et al. [29] proposed a solution, based on period. Chrome requires that SCTs be provided with DANE [20], that makes the delegation to a CDN all certificates issued after April 30, 2018 [37]. explicit through the name resolution process. The do- Certificate Transparency is relevant to our dis- main owner must add a special TLSA record contain- cussion for several reasons: CT allows detecting il- ing both its own certificate and the certificate of the legitimate CA actions and is thus a precious source CDN to its DNSSEC records. This approach requires of information for taking revocation decisions. As an that a modified version of DANE be deployed, and integral part of the current HTTPS ecosystem, CT that a browser extension be installed. It also increases must be accounted for when proposing a new scheme, page-load delay as it requires an extra round trip for both compatibility and efficiency reasons. Finally, during the TLS handshake. as an extensive source of certificates, CT is particularly helpful for understanding today’s PKI. 3.3. Related Certificate Features 4. Overview of Trust Models Revocation and delegation, as we will show, are issues that can be addressed simultaneously. Instead Figure 1 illustrates the trust model of name con- of relying on ad-hoc schemes to satisfy the two re- straints, short-lived certificates, proxy certificates, and quirements stated in Section 1, these requirements can delegated credentials. In a traditional PKI, the “chain be met using existing X.509 features, but currently of trust” is typically only three certificates long, and incurring major drawbacks. certificates are long-lived (on the order of months, The name constraints extension [12] allows CAs if not years). With name constraints, a link may be to issue CA certificates with a limited scope. The added to the chain in the form of a restricted CA Traditional PKI Name Constraints Short-Lived Certificates Proxy Certificates Delegated Credentials

root CA CA:true root CA CA:true root CA CA:true root CA CA:true root CA CA:true

inter. CA CA:true inter. CA CA:true inter. CA CA:true inter. CA CA:true inter. CA CA:true long-lived, logged domain domain domain domain domain CA:false CA:true CA:false CA:false owner owner owner owner owner *.example.com Constraint: CA:false CA:false CA:false *.example.com example.com

proxy

s1.example.com s2.example.com s3.example.com short-lived CA:false CA:false CA:false short-lived, credentials not logged (not logged)

Figure 1. Illustration of different PKI models and extensions. Solid arrows represent the “chain of trust”; certificates with no inbound arrow are self-signed. Only proxy certificates and delegated credentials may not be logged (see Section 5.2). certificate. Theoretically, a CA certificate with the This is true only to the extent that the responsibili- right constraints could be given to a domain owner, ties and security requirements of domain owners are but because browsers do not properly support name commensurate with the scale of their endeavors: the constraints at the moment, CAs do not offer this administrator of a small website could choose not to option. Also illustrated in Figure 1 are classic short- use any delegation mechanism at all, while an online lived certificates. Previous work suggested that these bank may want to spend a significant amount of time, should be issued by CAs [55]. Short-lived proxy cer- effort, and money on protecting its private keys. In the tificates offer the best of both worlds: domain owners worst case, a failure to adequately issue credentials can can impose their own policies without any form of CA only cause harm to the domain in question. support. Proxy certificates allow domain owners to CA support is the main feature distinguishing issue their own certificates, as self-signed certificates proxy certificates from name-constraint certificates. do, but do not require TOFU as the certificate chain While certificates that specify appropriate name con- starts from a CA certificate. With these properties, straints must be obtained from CAs, proxy certificates short-lived proxy certificates satisfy the requirements can be issued without interacting with a CA. Another (R1 and R2). Delegated credentials are stripped-down important aspect, relating to the above discussion, is certificates, containing merely a public key and a few that name constraints—because the CA bit must be parameters. Similarly to proxy certificates, delegated set to true in the corresponding certificate for them to credentials are signed with the domain owner’s private be effective—reinforce the misconception that domain key. Moreover, the time to live of delegated credentials owners would indispensably need to become CAs if must be shorter than 7 days [3]. they want to issue certificates for their own domain. While CA-based authentication has many ad- Delegated credentials also require special certificate vantages over trust-on-first-use or web-of-trust ap- extensions, but they do not require the CA bit to be proaches, proxy certificates illustrate that interactions set to true. Delegated credentials also have the ad- between certificate holder and CAs may be neither vantage of requiring minimal code changes, compared needed nor desirable for actions such as delegation to approaches that rely on full-fledged certificates, or revocation. One may argue, after the rise of Let’s because of the restricted semantics of the credentials. Encrypt, that interacting with an automated CA is Unfortunately, this also implies that delegated creden- free and effortless. However, Let’s Encrypt is a unique tials do not give domain owners the opportunity to case; it is actually a costly operation supported by a enforce fine-grained security policies. large number of sponsors. Interactions with a CA incur costs, and for Let’s Encrypt to continue to thrive, the burden put on it by new security schemes should be 5. Proxy Certificates for the Web minimal. Moreover, each CA is a single point of failure. While a CA being unavailable or going bankrupt may The concept of proxy certificates was first proposed not be an issue for a domain owner wanting to obtain a in the early 2000s in the context of grid comput- new certificate (as they can simply pick another CA), ing [56], [58], where the need for secure SSL/TLS it is a problem with regard to delegation and revo- delegation emerged. Back then, proxy certificates were cation. Finally, even if a CA provides a feature such used in middleware libraries and for use cases such as short-lived certificates, it will not necessarily be as single sign-on. The web was not envisioned as the flexible (the validity period may be fixed, for example). main application for proxy certificates. At the time, With proxy certificates or delegated credentials, the technologies used on the web were vastly different: domain owners can become issuers, which raises the the very first CDNs had just been created, Certificate question of whether they would need to fundamen- Transparency did not yet exist, and the use of HTTPS tally become CAs. This would imply following best was far less common than it is today. In this section, practices, using sophisticated software and hardware, we show how proxy certificates could be adapted to and being accountable in case of a security blunder. today’s web to fulfill the requirements. To delegate rights to a third party, a proxy certifi- as the current date/time and policies. The algorithm cate is signed using the domain owner’s private key. then iterates over the n certificates and verifies that It informs clients that the holder of the proxy certifi- they satisfy a number of conditions. We extend that cate may legitimately serve content for the specified algorithm as follows: domain name. The term “proxy” must be interpreted 1) Split the certification path into a regular path as an agent to which the domain owner has conferred (stopping at the first non-CA certificate, i.e., the certain rights. Here, proxies are HTTPS servers, under end-entity certificate) and a proxy path (consisting the control of either the domain owner or a third party of zero or more proxy certificates). such as a CDN or hosting provider. 2) Run the algorithm exactly as specified in RFC As we describe in detail in Section 5.3, several use 5280 on the regular path. If the algorithm indi- cases exist where proxy certificates would be bene- cates a failure, then stop and return the failure ficial. An overarching principle guiding their use is indication; otherwise, continue with the next step. that the scope and exposure of private keys should be 3) If the proxy path is null, then return a success limited. User-facing web servers, in particular, should indication; otherwise, run the algorithm of RFC only hold private keys with limited capabilities, be- 5280 on the proxy path as follows: cause they are especially exposed to various threats. • Provide the end-entity certificate as the “trust This has been demonstrated by recent vulnerabili- anchor information” input to the algorithm. ties, such as Heartbleed [16], which allow attackers • Ignore the CA boolean in the “basic con- to remotely read protected memory on the vulnerable straints” extension of the proxy certificate(s). machine and thus extract private keys. • Consider “subject alternative name” values Another important aspect to consider is the eco- in both the end-entity certificate and subse- nomic consequences proxy certificates would have on quent proxy certificates as additional name con- the current PKI ecosystem. They could reduce the straints. That is, in each iteration i of the al- number of requests to CAs (as having a separate gorithm, update the “permitted subtrees” state certificate for each subdomain would not be necessary variable, which defines a set of names “within anymore, for example) and thus reduce their revenue. which all subject names in subsequent certifi- Although this is not in the interest of CAs, they cates in the certification path MUST fall.” [12], will not be able to hinder the deployment of proxy as follows: certificates, as they are not involved in the issuance process. Reducing CA-incurred costs is beneficial for PSTi = PSTi−1 ∩ NCi ∩ (SANi ∪ CNi), the deployment of HTTPS, as demonstrated by the where PSTi−1 is the previous value of the “per- success of Let’s Encrypt, for example. mitted subtrees” variable, NCi is the set of In the remainder of this paper, we use the term acceptable names defined by the “name con- end-entity certificate to refer exclusively to a non- straints” extension, SANi is the set of names CA certificate issued by a CA, as opposed to proxy indicated in the “subject alternative names” certificate, which refers to a certificate that extends the extension, and CNi is the “common name” field chain of trust starting from an end-entity certificate. of the i-th certificate. Initially, PST0 = SAN0 We use the term end-entity key to refer to the private ∪ CN0, where SAN0, and CN0 are defined in key that corresponds to an end-entity certificate. the end-entity certificate. The path length is interpreted as is done in 5.1. Certification Path Validation RFC 5280 for the proxy path as well, restarting the count. The above validation algorithm then guarantees A proxy certificate is similar to any other X.509 that the following properties are satisfied: certificate in terms of format; the distinction from a regular certificate comes from the certification path. • The set of acceptable names cannot be extended In a nutshell, a proxy certificate is considered valid for by an additional proxy certificate down the cer- a given name if it extends the chain from a non-CA tification path. However, anyone holding a proxy certificate that is valid for that name and the proxy certificate and the corresponding private key may certificate also contains that name in its (possibly sign another proxy certificate with an equal or reduced) set of permitted names. However, we also smaller set of acceptable names, provided that the allow for chains of proxy certificates and the restriction path length constraint is respected. thereof through “path length” constraints, which— • Since every certificate in the validation path must among other factors—makes the validation of proxy be valid, the expiration time of a proxy certificate certificates non-trivial. Below we describe a validation cannot be deferred by extending the validation algorithm designed to require only minor changes to path with an additional proxy certificate. the current X.509 specification and implementations. • The end-entity certificate must be issued by a An algorithm for the validation of a regular cer- trusted CA. It may be used as is by the domain tification path is given in RFC 5280 [12, Section 6]. owner, without any proxy certificate in the chain Trust anchor information (typically in the form of self- (i.e., with a null proxy path). signed certificates) must be provided as input to the A CDN holding a proxy certificate for www.exam- algorithm. A prospective certification path of length ple.com may issue a valid proxy certificate (one level n (which does not contain the trust anchor) is also below in the chain of trust) for www.example.com, provided as input, along with other information such but not for admin.example.com. Note also that a wildcard certificate for *.example.com would match Fetch/push proxy cert. foo.example.com but not bar.foo.example.com as per current standards [43]. Therefore, someone holding Certificate Server* End-Entity Key* TLS session such a wildcard certificate cannot issue valid proxy Firewall Client Edge Server certificates for names that would otherwise not be (Browser) (Proxy) covered by the wildcard certificate itself, even when Fetch content extending the proxy path. (upon cache miss) Origin Server* RFC 3820 [56] provides an analogous logic. How- *may or may not be hosted on the same machine ever, we base our algorithm upon the more recent and complete RFC 5280 [12], which does not cover proxy Figure 2. Deployment model for Use Case 1 (content delivery). certificates. In contrast to our algorithm, RFC 3820 The white key is certified by the end-entity key (in black) (a) forbids usage of the “subject alternative name” through proxy certificates. extension in proxy certificates, (b) does not specify how “name constraints” should be treated, and (c) website with no sensitive data could choose to forgo introduces an additional field for restricting the length using proxy certificates altogether, as they are not of the proxy path, rather than utilizing the existing mandatory. At the other extreme, the end-entity key “path length” parameter as we do here. can be stored on an air-gapped device, kept in a secure location and configured only to sign very-short-lived 5.2. Certificate Logging proxy certificates, which could then be extracted from the signing device using QR codes [33] displayed on As indicated in Figure 1, we submit that proxy an attached screen and read by a networked camera, certificates should not be logged (by CT servers, for for example. This might be the solution of choice for example). Our rationale is as follows: First, the CT an organization with high security requirements, such framework was created with the objective of uncov- as a financial institution. ering CA misbehavior and compromise, not attacks Before an HTTPS connection can be established, against individual domain owners. Second, comparing the client must obtain the IP address of the edge with the current situation, not logging proxy certifi- server through DNS resolution. The edge server could cates does not reduce security: an attacker who com- be one of many servers under the control of a CDN, promises a private key can already impersonate the for example, or a machine that the domain owner corresponding domain; issuing bogus proxy certificates controls directly. If the edge server is controlled by the for that domain would not give the attacker any more domain owner, the DNS resolution is straightforward. capabilities. Therefore, logging proxy certificates does Redirection to a CDN server, on the other hand, can not help domain owners discover breaches. Finally, be realized in different ways, as described in Section 2. traditional short-lived certificates are issued by CAs The client then establishes an HTTPS connection and, except for their validity period, cannot be dis- with the edge server, which temporarily stores some tinguished from regular certificates. This implies that or all of the resources fetched from an origin server, each short-lived certificate must be logged as any other as illustrated in Figure 2. To establish a TLS connec- certificate, increasing the pressure on log servers. Al- tion with the client, the edge server needs a proxy though potential solutions have been proposed, there certificate that it can either fetch from the certificate is no consensus on how log servers should deal with server, or that the certificate server can push at regular short-lived certificates [31]. If proxy certificates are not intervals. Issuing these proxy certificates requires an logged, they do not suffer from this issue. initial setup: 5.3. Use Cases 1) The edge server (or the entity controlling it) gen- erates a key pair and puts the public key into an In this section, we describe three use cases that unsigned certificate signing request (CSR) with highlight the benefits proxy certificates would bring to the same format as a standard CSR. We call this the web PKI. These use cases are non-exhaustive, and file a proxy CSR. the features we present can be combined in different 2) The domain owner obtains the proxy CSR ways. For example, a domain owner may want to (a) through an authentic channel (e.g., the web portal use a CDN, (b) have multiple subdomains, and (c) be of the CDN). able to specify different policies on each subdomain. 3) The domain owner configures the certificate server to issue proxy certificates (based on the Use Case 1: Content Delivery. The primary use proxy CSR) at a specified frequency and with case we envision for proxy certificates is content deliv- a specified validity period. Only the notBefore ery, with a potentially large number of caching servers and notAfter fields [12] are updated. The validity distributing content fetched from an origin server. periods of two consecutive proxy certificates must The infrastructure needed to best take advantage of overlap to avoid downtimes. proxy certificates in this scenario depends on different Thereafter, when needed, the certificate server cre- factors, including whether the domain owner decides ates a new proxy certificate and signs it using the end- to focus on security, deployability, or efficiency. An entity key. This implies that the certificate server must entire range of possible configurations exists. At one either have direct access to the end-entity key or access end of the spectrum, the administrator of a static to a device able to produce the appropriate signatures. For example, the end-entity key could be stored on breakage in the early deployment of CT, and listed a hardware security module (HSM). The proxy cer- name redaction as an open problem. Eskandarian et tificate is then transmitted from the certificate server al. [17] proposed a solution to supporting private sub- to the edge server. As proxy certificates are public domains based on cryptographic commitments, but information, any communication protocol can be em- it would require updating browsers, log servers, and ployed. The CDN could even extend the certification CA software. Scheitle et al. [44] also showed that CT path further (by additional proxy certificates) so that logs are being actively monitored to find new domain different keys are used by different edge servers. names as targets. Under normal circumstances, even if the proxy certificates are short-lived, the key pair used by the Use Case 3: Dynamic Security Policies. One of edge server can remain unchanged over a long time. the benefits of proxy certificates is that they lend Indeed, the reissuance process only serves the purpose themselves to short validity periods. However, a more of extending a lease to the proxy, but does not imply general advantage is that they allow domain owners a key rollover. If needed, key rollover can be achieved to define security policies dynamically and for each simply by having the edge server generate a new key subdomain separately: every time a proxy certificate pair, and use the new public key for subsequent key is created or renewed, the domain owner is free to signing requests. The domain owner has the option of define a new policy or change an existing one using terminating that lease at any time, by simply stopping the appropriate fields in the proxy certificate. We do the issuance process, thus effectively revoking delega- not attempt to exhaustively list all such policies here, tion privileges. It is recommended, in such a context, but discuss a few salient examples. The notBefore and to restrict traffic to the certificate and origin servers, notAfter fields define the validity period of the cer- especially from the public Internet. A firewall may tificate, while pathLenConstraint restricts the length be configured to limit incoming connections to those of the certification path. from the CDN’s IP space, which is generally public As we have seen, the assumption that the domain information [11]. name and servers are controlled by the same entity no Since 2016, Let’s Encrypt has been offering free longer holds. As a consequence, a domain owner may certificates to domain owners, thanks in part to a not approve of the server’s configuration. For example, completely automated domain validation process sup- a CDN (or attacker having compromised the domain’s ported by the Automatic Certificate Management private key) may try to use session resumption to ex- Environment (ACME) protocol [2]. Since then, sev- tend a TLS session far beyond the certificate’s expira- eral other CAs have followed suit and started us- tion date (see Section 7). With a dedicated certificate ing ACME [14], [46]. These CAs generally also offer extension field in the proxy certificate, a security- tools for (re)issuing and revoking certificates. In 2018, focused domain owner could indicate to the browser ACME v2 was adopted by Let’s Encrypt, notably to that session resumption should not be attempted. support wildcard certificates [1]. Similar automation The browser may be configured to strengthen certain could be adopted by domain owners to handle and domain policies, but should not weaken them. maintain proxy certificates, which could be imple- Another example of a policy relates to how mented using a software framework like that of Let’s browsers deal with protocol errors. As pointed out Encrypt, or incorporated into it. by Szalachowski et al. [54], domain owners should be able to influence the decision of the browser to either Use Case 2: Private, Separated Subdomains. completely stop a TLS communication in case an Another use case is that of using different private anomaly occurs, a hard fail, or give the user an option keys on different subdomains. Wildcard certificates to proceed despite the risk, a soft fail. Indeed, the (albeit generally more expensive than regular ones) domain owner is the entity best able to specify the are appreciated by domain owners because they allow level of security and availability that their application them to protect any number of subdomains they want, requires and determine whether the browser should independently from CAs. However, a wildcard certifi- hard fail or soft fail. We suggest that domain owners cate normally implies that the same private key is used should be able to express their preference for a failure on all subdomains. In contrast, by using a wildcard in mode through an extension in the proxy certificates the end-entity certificate (such as *.example.com) but they issue. a more specific name (such as s1.example.com) in all proxy certificates (see Figure 1), the domain owner can 6. Delegated Credentials make sure that the consequences of a key compromise or misbehavior from a hosting provider are confined A recent alternative to proxy certificates are dele- to the corresponding subdomain. gated credentials, which we describe here to enable our Moreover, as proxy certificates need not be in- detailed comparison later. Similarly to proxy certifi- cluded in certificate logs such as CT’s (see Section 5.2 cates, delegated credentials are designed to be short- above for motivations), they would not disclose pri- lived and allow delegation to be done offline. In con- vate subdomain names such as secret-project.ex- trast to proxy certificates delegated credentials are not ample.com, which is an otherwise inherent and unde- full-fledged X.509 certificates. A delegated credential sirable consequence of Certificate Transparency [18]. is composed of a public key, a validity time (relative Stark et al. [48] reported that CAs stripping full do- to the certificate’s notBefore field), a signature al- main names from logged certificates was a cause of gorithm, and the signature itself. In addition, every delegated credential is bound to a signature algorithm protocols. On the one hand, new security policies (e.g., that may be used during the TLS handshake [3]. requiring that the server provide SCTs to support An argument put forth by the authors of the Inter- Certificate Transparency) are often not enforced due net Draft for using delegated credentials rather than to fear of breakage [48]. On the other hand, not sup- proxy certificates is that their semantics are minimized porting a new scheme and thus causing breakage is to mitigate the risks of cross-protocols attacks. More- different. Proxy certificates and delegated credentials over, software changes required to support delegated both fall into the second category, as a connection to credentials are limited to the TLS stack and do not a server employing one of those delegation techniques affect PKI code. might fail if the browser does not support them. Delegated credentials almost exclusively address the Use Case 1 of proxy certificates, that is, delega- 7. TLS with Short-Lived Certificates tion to content delivery networks. They do not allow domain owners to enforce security policies on a per- TLS was not designed with short-lived certificates subdomain basis and do not address the problem of or credentials in mind. In this section, we explain why keeping subdomains private. it is critical that the certificate lifetime be considered even after a connection is established. We stress that 6.1. Server and Client Authentication this issue does not only concern proxy certificates. Our discussion concerns any TLS session that is sufficiently Although TLS is most commonly used for server long-lived to extend beyond the certificate’s expiration authentication, it supports client authentication as time. This situation is not as unlikely as it may ini- well, and so do delegated credentials. Below we only tially appear, when we consider session resumption, describe server authentication but client authentica- but has unfortunately often been neglected in previous tion is handled analogously. work on short-lived certificates [36], [55]. A client supporting delegated credentials must first indicate it by sending an empty “delegated creden- 7.1. TLS sessions and resumption tial” extension in its ClientHello message (during the TLS handshake). The server may then send a dele- We focus on TLS 1.3 [41] and use its nomencla- gated credential to the client, only if this extension is ture, rather than that of older TLS versions. However, present. This mechanism ensures that an incremental similar arguments apply to older TLS versions, in deployment is possible: delegated credentials are only particular, TLS 1.2. provided to browsers that support them while a less TLS describes a key-exchange protocol between efficient alternative, such as Keyless SSL, can be used two parties, resulting in shared keying material used with legacy clients. A similar mechanism could be used in a subsequent connection transferring data. Such for an incremental deployment of proxy certificates. a connection usually times out after not being used between 1 to 5 minutes, but can otherwise stay alive 6.2. Validation and Requirements indefinitely. This connection is part of a session that may (and in practice does) provide a pre-shared key A delegated credential is validated as follows. First, (PSK) which is single-use and provisioned for session the current time must be within the validity period resumption, which creates a new connection. of the credential, and the lifetime of the credential Based on a PSK, a client can reconnect to the cannot be greater than 7 days. Second, the signature server while the PSK stays valid, without the certifi- algorithm used to sign the TLS handshake must match cate being checked again. Note that a PSK stays valid the one indicated in the credential. Finally, the end- for up to 7 days, at the issuing server’s discretion. entity certificate must satisfy the conditions we de- Using PSK-based resumption (usually) provisions a scribe below, and its public key must be used to verify new PSK, again valid for 7 days from its issuance, the signature on the credential. allowing indefinite chaining [41, Section 4.6.1]. Delegated credentials introduce a new certificate extension: DelegationUsage. The signature on the 7.2. The problem with resumption delegated credential may be generated using the end- entity certificate’s private key, under the conditions At no point after the initial full key exchange is that the digitalSignature bit is set (in the key usage the certificate, or its lifetime, considered. The TLS extension of the certificate) and that the delegation 1.3 specification suggests that the validity of connec- usage extension is present. The digital signature bit is tions and sessions should consider certificate validity, only required when the subject public key is used for but does not mandate it [41, at the end of Section verifying signatures “other than signatures on certifi- 4.6.1]. Using session resumption can therefore nullify cates” [12]. Therefore, the digital signature bit is not the security benefits of short-lived certificates. Cur- required for validating proxy certificates. rent web browsers do not check that a resumption is performed within the certificates’ lifetime. A malicious 6.3. Deployment Incentives edge server can issue a session PSK with a long lifetime (maximum of 7 days) to clients and prolong them on The deployment of a new technology is always every subsequent connection, thereby subverting the challenging, especially when it affects core Internet benefit of short-lived certificates. The Internet Draft describing delegated creden- in Table 1. We formulate the properties in terms of the tials [3] only states that “if a client decides to cache benefits that the different schemes may provide and we the certificate chain and re-validate it when resuming a categorize these benefits into six classes: revocation- connection, the client should also cache the associated related, delegation-related, security, efficiency, deploy- delegated credential and re-validate it.” ability, and cross-category benefits. We consider 19 possible benefits in total, two of which cover the re- 7.3. Possible solutions quirements we have set out in Section 1. We classify each scheme as to whether it provides, partially pro- Currently, the simplest solution to this problem is vides, or does not provide each benefit. to disallow session resumption completely, thereby for- At the bottom of the table we list various com- saking its efficiency benefits. For non security-sensitive binations of schemes that add benefits. Short-lived websites, one can opt for more efficiency and use proxy certificates and delegated credentials offer al- longer-lived certificates together with session resump- ready most of the benefits. By combining proxy certifi- tion. Unfortunately, most browsers do not allow users cates of delegated credentials with different revocation to configure the use of session resumption. However, schemes, we can achieve additional benefits. some privacy-aware browsers such as Tor Browser or JonDoBrowser disable session resumption globally to Evaluation Criteria prevent user tracking [51]. We propose a more flexible approach based on dynamic policies (as explained in A. Revocation-Related Benefits Use Case 3 above, Section 5.3) where a domain can determine an on-off session resumption policy, which Supports CA revocation: A revocation scheme is then enforced by the browser. should give authorized entities (such as CAs or soft- A further improvement that combines security and ware vendors) the ability to invalidate the certificates efficiency would require a coordination between the of root and intermediate CAs. We give partial points lifetimes of the short-lived certificates and the session to schemes that theoretically support revoking CA PSKs, ensuring that a PSK cannot be used after certificates but require contacting those CAs. the expiration of the edge server’s (or subdomain’s) Supports damage-free CA revocation: Revoking certificate. For the certificate obtained from the a CA certificate should not cause collateral damage, server during the first connection of a session, this i.e., it should not invalidate certificates issued by the could be achieved by dropping the connection when revoked CA before it was compromised. Standard re- the certificate expires. Unfortunately, handling the vocation invalidates all previously issued certificates extended expiration time of subsequently issued by a revoked CA, thus leading to collateral damage. short-lived certificates appears hard to achieve, since Supports leaf revocation: This benefit is offered by it additionally mandates a timely update of these schemes that enable the revocation of certificates or certificates in the browser. Such an update could be credentials at the end of the certification path. We achieved by either (a) establishing a fresh session, give partial points to schemes that only propagate a which involves a full TLS handshake, or (b) updating manually selected subset of revocations. Short-lived the certificate in the web browser by an out-of-band certificates and delegated credentials offer this benefit communication with the domain. The former solution (although, strictly speaking, they do not support revo- means that the use of the session PSK is limited by the cation) because they allow domain owners to rapidly lifetime of a single short-lived certificate, which makes make a compromised key unusable for the attacker, resumption useless with minute-range certificate which is equivalent. Self-signed certificates do not offer lifetimes. The latter would effectively enable the this benefit as their revocation requires additional use of session resumption as long as the browser mechanisms. Proxy certificates get partial points as possesses a valid certificate for the domain. However, they are not necessarily short-lived. implementing this solution would likely involve Supports autonomous revocation: Domain own- considerable modifications to current infrastructure. ers can autonomously (i.e., without reliance on a CA, Using proxy certificates, a domain owner can spec- browser vendor, or log) perform “leaf revocation” (see ify its own session resumption policies, which are then above). This benefit corresponds to Requirement R1. enforced by the browser. This allows a fine-grained split, for example by subdomain, where security- B. Delegation-Related Benefits critical subdomains (e.g., a login page) disallows re- Supports delegation: Schemes offering this benefit sumption, while other pages allow it. In conclusion, as allow domain owners to transfer some or all of their proxy certificates provide domain owners fine-grained privileges (not necessarily in a secure way). control over their policies, they achieve the efficiency Supports delegation without key sharing: This benefits of quick session resumption without losing the benefit is offered by schemes that let domain owners security benefits across all subdomains. autonomously delegate certain rights without sharing any private key. This corresponds to Requirement R2. 8. Analysis C. Security Benefits We now present our framework for characterizing delegation and revocation schemes with respect to a Supports domain-based policies: This benefit is wide range of properties. Our results are summarized offered by schemes that let domain owners define Table 1. Comparison of revocation and delegation approaches. Columns represent benefits. Each benefit falls under one of six categories (A–F). Benefits corresponding to the requirements are marked with R1 and R2 . See Section 3 for our categorization of revocation schemes (Cat. I–IV) and Section 8 for the definitions of our criteria. Supports CA revocation Supports damage-free CA rev. Supports leaf revocation Supports autonomous rev. (R1) Supports delegation Delegation w/o key sharing (R2) Supports domain-based policies No trust-on-first-use required Preserves user privacy Does not increase page-loadLow delay burden on CAs Reasonable logging overhead Non-proprietary No special hardware required No extra CA involvement No browser-vendor involvement Server compatible Browser compatible No out-of-band communication

Scheme Reference A B C D E F a. Regular CRL (Cat. I) [12] G## # # # # # # # # G# # b. Hard-fail OCSP (Cat. I) [35] G## # # # # # # # # G# # c. OCSP stapling (Cat. II) [39] G## # # # # # # G#G# d. PKISN (Cat. II) [53] # # # # G#G## # Revocation e. CRLSets (Cat. III) [25] # G## # # # # # G# Schemes f. OneCRL (Cat. III) [34] # G## # # # # # G# g. CRLite (Cat. III) [26] # # # # # # # h. RevCast (Cat. IV) [45] # # # # # ## # i. RITM (Cat. IV) [52] # # # # # G## # j. SSL splitting [28] ### # # # # k. Keyless SSL [5] ### # # # # Delegation l. Key sharing [9] ### # # # Schemes m. DANE-based delegation [29] ### # # # # n. Delegated credentials [3] ## G# G# # # o. Self-signed certificates [59] ### # G# G# G# p. Short-lived certificates [55] ## # # # # # # # Certificate q. Name-constrained cert. [13] ### # # # G# Features r. Cruise-liner certificates [9] ### # # # # s. Proxy certificates [58] # # G# G# G## n + d # G#G## # n +(e or f) # # # G## # # n + g # # G## # # Combinations p + s ## G## of Schemes p + s + d G#G## # p + s +(e or f) # # # G## p + s + g # # G##

= offers the benefit; G# = partially offers the benefit; # = does not offer the benefit. policies, e.g., specifying whether session resumption D. Efficiency Benefits is authorized or not (see Use Case 3 in Section 5.3). We give partial points to delegated credentials because Does not increase page-load delay: This benefit is their semantics are limited and only allow the domain offered by schemes that do not substantially increase owner to define the validity period. the time it takes for the browser to load pages. We ignore small processing delays, but do not grant this benefit to schemes that incur additional network delay. No trust-on-first-use required: This benefit is of- Low burden on CAs: Experience has shown that if a fered by schemes that do not require trusting a public scheme requires CAs to make considerable operational key the first time it is encountered. We give partial efforts, but provides limited financial benefits, then the points to self-signed certificates as they can be ob- scheme is unlikely to be successful. In particular, CAs tained through an authentic channel beforehand. should not have to handle high numbers of requests from clients (e.g., to check a revocation status) or be Preserves user privacy: Browsers should not have required to reissue certificates at a high frequency. to reveal any domain-related data to a third party Reasonable logging overhead: The scheme should when validating a certificate or delegation. not put excessive pressure on certificate logs. Logging certificates with a short validity period or issued by the clients will not reap the security benefits of that the domain owners themselves (hence, potentially too scheme)”, but this is captured by our “browser com- many) would make logs blow up. patible” benefit. The flip side of deploying a security scheme that is compatible with previous browser ver- E. Deployability Benefits sions is that users with outdated software are unlikely to realize that their browser does not support the Non-proprietary: A scheme is more generally useful latest security standards, which does not encourage if it is not bound to or controlled by a particular adoption. software vendor. This benefit is offered by schemes that are open, not controlled by a single organization, F. Cross-Category Benefit and not restricted to a single browser. No special hardware required: This holds for No out-of-band communication: Requiring users schemes without special hardware requirements. We to communicate with a third party or use a different give partial points to schemes that do not require channel is problematic. It can compromise user pri- special hardware but require that existing hardware vacy, increase latency, and captive portals may not (e.g., middleboxes) be updated to support the scheme. allow the connection to be made. We grant this benefit No extra CA involvement: This benefit is offered to schemes that require users to neither use a separate by schemes that work without the participation of channel nor establish a connection with a server that CAs (beyond regular certificate issuance). We give would not be contacted otherwise. We grant partial partial points to delegated credentials as they require points to self-signed certificates for this benefit, as the CA to issue an end-entity certificate with special an out-of-band communication may be used to cir- extensions (see Section 6.2). We also give partial points cumvent the TOFU problem self-signed certificates to schemes that permit CA involvement but do not inherently have otherwise. require it. CRLs and OCSP do not provide this benefit as CAs typically act as issuer/responder, although in Combinations of Schemes theory this role can be fulfilled by another entity. No browser-vendor involvement: This benefit is In Table 1, we evaluate the benefits of combin- offered by schemes that do not require the participa- ing proxy certificates and delegated credentials with tion of browser vendors beyond the need to develop other schemes. When proxy certificates are short-lived compatible software. For example, browser-vendor in- (i.e., when schemes p and s are combined), revocation volvement can consist in regularly selecting and prop- becomes feasible thus offering the “supports leaf re- agating a set of revocations through browser up- vocation” benefit. In that case, revocation would be dates. We give partial points to schemes that permit undertaken by the domain owner rather than the CA. software-vendor involvement but do not require it. The owner issues short-lived certificates (e.g., a few Server compatible: This benefit means that no hours) and simply refrains from renewing these on changes are required on the server side. OCSP sta- time of expiry when revocation is needed. pling partially offers the benefit as it requires actions The revocation of CA certificates is supported nei- from the web server but is widely supported. Proxy ther by proxy certificates nor by delegated creden- certificates also partially offer the benefit as they could tials. CA certificate revocation has a vastly different be used a priori by any web server, but software scale (with regard to the total number of certificates) updates would be needed to let domain owners fully and different requirements. Therefore, we suggest that take advantage of proxy certificates. schemes that were specially designed for that purpose Browser compatible: This indicates that no changes (such as PKISN [53]) or schemes that work well with to the browser are required. We give partial points to smaller numbers of certificates (such as CRLSets and standardized schemes that are implemented by major OneCRL) be used in conjunction with proxy certifi- browser vendors but often turned off by default or im- cates or delegated credentials. properly enforced. Self-signed certificates also received As we could not include all possible combinations partial points for this benefit as they typically generate in our comparison table, we only included schemes error messages on first use. We also give partial points that offer complementary benefits with minimal draw- to schemes that are specific to a particular browser backs, and schemes that are already widely deployed (e.g., CRLSets for Chrome only). (CRLSets, OneCRL). We see that several combina- We purposely did not include “incrementally de- tions fulfill both of the requirements, in most cases ployable” in our analysis as we believe that it is a requiring only minor software updates. vague and potentially misleading “benefit” in this con- text. OCSP stapling, for example, can be considered 9. Related Work incrementally deployable in its soft-fail variant (i.e., the browser does not return an error when the server In 2013, Clark and van Oorschot [10] surveyed does not support stapling), but this allows an attacker problems of the TLS/HTTPS ecosystem and its trust to simply omit the OCSP status of a revoked certifi- model. Their systematization of knowledge covers cate and thus provides no added security. Incremental a wide range of problems, including TLS protocol deployment can also be interpreted as “clients that flaws, certification, trust anchoring, and user interface have not been updated to support a scheme can still issues. They evaluate various enhancements with communicate with servers that support it (although respect to security properties in three categories (detecting MitM attacks, TLS stripping, and PKI on Intel SGX, Intel QuickAssist Technology, and the improvements) and their general impact on security SIGMA (SIGn-and-MAc) protocol, which can be used and privacy, deployability, and usability.1 Their to distribute and protect SSL/TLS keys. analysis highlighted how CA infrastructures are increasingly being seen as a fundamental weakness in 9.3. Other Issues with SSL/TLS the PKI system. The authors also analyzed techniques against fraudulent certificates, including certificate Sy et al. [51] recently showed, after analyzing as pinning. With support for certificate pinning dropped many as 48 browsers, that session resumption was also after years of operation [38], it is becoming clearer problematic for user privacy as it can be used to track that such directions provide little hope to address the average user for up to eight days with standard our current challenges. In contrast, our work focuses settings. With a long session resumption lifetime, a on delegation and revocation and considers recent majority of users can even be tracked permanently. developments of the HTTPS ecosystem, such as Problems have also been discovered in the way CAs delegated credentials, Certificate Transparency, perform domain validation: exploiting a BGP vulner- CDNs, and session resumption. Moreover, the work ability to hijack traffic, an attacker can obtain a rogue of Clark and van Oorschot does not include proxy certificate from vulnerable CAs [6], [7]. Brubaker et certificates and recently proposed revocation schemes. al. also found serious vulnerabilities in popular imple- We now mention related topics that are relevant to mentations of SSL/TLS using certificates with unusual the area of the web PKI, delegation, or more generally combinations of extensions and constraints [8]. SSL/TLS, but go beyond the scope of our study. 10. Conclusion 9.1. Holistic PKI Proposals Delegation and revocation sometimes appear to be AKI [23] and its successor ARPKI [4] are more two sides of the same coin. We have shown that it is holistic approaches to upgrading the web PKI. One possible to simultaneously address both of these issues of the main ideas in these proposals is that resilience with a slight modification to the chain of trust, but this to compromise can be improved by requiring is a delicate task. On the one hand, using a single long- that multiple CAs sign each end-entity certificate. lived certificate per domain has several advantages: Additionally, to guarantee that no other rogue it is more practical for administrators, it lowers the certificate exists for a given domain, all certificates pressure on transparency logs, it reduces CA-incurred must be logged and log servers efficiently produce costs, and thus benefits the deployment of HTTPS. both presence and absence proofs. Unfortunately, this On the other hand, using short-lived credentials, not also implies that only one certificate per domain can sharing private keys with third parties, and limiting be valid at any given time. ARPKI’s key security the scope and exposure of private keys is preferable properties were also formally verified. from a security standpoint. PoliCert [54] builds on top of ARPKI to solve the Delegated credentials and proxy certificates solve unique-certificate problem by replacing the end-entity this conundrum with minor changes to existing stan- certificate by a unique domain policy that specifies dards and little overhead. They give more flexibility which CAs are allowed to issue (potentially multiple) to domain owners and accommodate practices that certificates for that domain. However, that approach have become ubiquitous on the web, such as delegation does not allow domain owners to rapidly change their to CDNs. Although proxy certificates and delegated policies or produce their own certificates (i.e., with- credentials address similar issues, proxy certificates out contacting several CAs). Therefore, proxy certifi- offer more flexibility. For example, they enable domain cates could complement ARPKI certificate chains as a owners to maintain as many certificates as they desire, lightweight and more dynamic alternative to PoliCert. without CA reliance, with policies and validity periods defined individually for each subdomain. Proxy cer- tificates also address the problem of keeping private 9.2. Beyond HTTPS Delegation subdomains hidden from certificate logs. We thus view the recent deployment efforts sur- A number of previous research papers have ad- rounding delegated credentials with optimism, but dressed the problem of delegation in different con- note that many challenges remain. For example, ses- texts than that of the web. Kogan et al. [24] argue sion resumption—whose goal is to bring page-load that a secure delegation system should always make delay to a minimum, which in turn is one of the who what whom explicit “ will do to ”, and present a main reasons for using a CDN in the first place— design for the SSH protocol, called Guardian Agent. finds itself in conflict with short-lived credentials. Also, MacKenzie et al. [32] address the problem of server the revocation of CA certificates is a major issue that delegation in the context of capture-resilient devices short-lived credentials do not address. Other schemes (i.e., devices required to confirm password guesses with bring solutions to these issues but combining them a designated remote server before private-key opera- in meaningful ways is hard. Some of the examined tions). STYX [57] is a key management scheme, based proposals may be conceptually simple, but have con- 1. Some evaluation criteria semantically overlap with theirs, siderable ramifications in the highly complex HTTPS e.g., “preserves user privacy”, “server compatible”, and “no out- ecosystem. We hope that our systematic analysis sheds of-band communication”. Other criteria are problem-specific. light on these issues and helps guide future research. References [18] Google Code Archive. Need options for avoiding logging private subdomains (certificate-transparency issue #20), October 2013. https://perma.cc/27RW-PNWF. [1] Josh Aas. ACME v2 API endpoint coming January 2018, June 2017. https://perma.cc/K65K-N9L6. [19] Phillip Hallam-Baker. X.509v3 extension: OCSP stapling required. Internet draft, October 2012. draft-hallambaker- [2] Richard Barnes, Jacob Hoffman-Andrews, Daniel McCar- muststaple-00. ney, and James Kasten. Automatic certificate management environment (ACME). RFC 8555, March 2019. [20] Paul Hoffman and Jakob Schlyter. The DNS-based authen- tication of named entities (DANE) transport layer security [3] Richard Barnes, Subodh Iyengar, Nick Sullivan, and Eric (TLS) protocol: TLSA. RFC 6698, August 2012. Rescorla. Delegated credentials for TLS. Technical report, November 2019. draft-ietf-tls-subcerts-05. [21] Subodh Iyengar, Kyle Nekritz, and Alex Guzman. Del- egated credentials: Improving the security of TLS certifi- [4] David Basin, Cas Cremers, Tiffany Hyun-Jin Kim, Adrian cates, November 2019. https://perma.cc/G3TC-9ZYU. Perrig, Ralf Sasse, and Pawel Szalachowski. Design, anal- ysis, and implementation of ARPKI: an attack-resilient [22] Kevin Jacobs, J.C. Jones, and Thyla van der Merwe. Val- public-key infrastructure. IEEE Transactions on Depend- idating delegated credentials for TLS in firefox, November able and Secure Computing (TDSC), October 2016. 2019. https://perma.cc/VG47-PKLC. [5] Karthikeyan Bhargavan, Ioana Boureanu, Pierre-Alain [23] Tiffany Hyun-Jin Kim, Lin-Shung Huang, Adrian Perrig, Fouque, Cristina Onete, and Benjamin Richard. Content Collin Jackson, and Virgil Gligor. Accountable key in- delivery over TLS: a cryptographic analysis of keyless SSL. frastructure (AKI): A proposal for a public-key validation In Proceedings of the IEEE European Symposium on Secu- infrastructure. In Proceedings of the International World rity and Privacy (EuroS&P), August 2017. Wide Web Conference (WWW), May 2013. [6] Henry Birge-Lee, Yixin Sun, Annie Edmundson, Jennifer [24] Dmitry Kogan, Henri Stern, Ashley Tolbert, David Maz- Rexford, and Prateek Mittal. Bamboozling Certificate Au- ières, and Keith Winstein. The case for secure delegation. thorities with BGP. In Proceedings of the USENIX Security In Proceedings of the ACM Workshop on Hot Topics in Symposium, 2018. Networks (HotNets), pages 15–21, 2017. [25] Adam Langley. Revocation checking and Chrome’s CRL. [7] Markus Brandt, Tianxiang Dai, Amit Klein, Haya Shul- ImperialViolet, 2012. https://perma.cc/X7FT-W3LF. man, and Michael Waidner. Domain Validation++ for MitM-Resilient PKI. In Proceedings of the ACM Confer- [26] James Larisch, David Choffnes, Dave Levin, Bruce M. ence on Computer and Communications (CCS), 2018. Maggs, Alan Mislove, and Christo Wilson. CRLite: A scal- able system for pushing all TLS revocations to all browsers. [8] Chad Brubaker, Suman Jana, Baishakhi Ray, Sarfraz Khur- In Proceedings of the IEEE Symposium on Security and shid, and Vitaly Shmatikov. Using frankencerts for auto- Privacy (S&P), May 2017. mated adversarial testing of certificate validation in ssl/tls implementations. In Proceedings of the IEEE Symposium [27] Ben Laurie, Adam Langley, and Emilia Kasper. Certificate on Security and Privacy (S&P), 2014. transparency. RFC 6962, June 2013. [9] Frank Cangialosi, Taejoong Chung, David Choffnes, Dave [28] Chris Lesniewski-Laas and M Frans Kaashoek. SSL split- Levin, Bruce Maggs, Alan Mislove, and Christo Wilson. ting: Securely serving data from untrusted caches. Com- Measurement and analysis of private key sharing in the puter Networks, 48(5):763–779, August 2005. HTTPS ecosystem. In Proceedings of the ACM Conference [29] Jinjin Liang, Jian Jiang, Haixin Duan, Kang Li, Tao Wan, on Computer and Communications (CCS), 2016. and Jianping Wu. When HTTPS Meets CDN: A Case of [10] Jeremy Clark and Paul C. van Oorschot. SoK: SSL and Authentication in Delegated Service. In Proceedings of the HTTPS: revisiting past challenges and evaluating certifi- IEEE Symposium on Security and Privacy (S&P), pages cate trust model enhancements. In Proceedings of the IEEE 67–82, April 2014. Symposium on Security and Privacy (S&P), 2013. [30] Yabing Liu, Will Tome, Liang Zhang, David Choffnes, Dave [11] CloudFlare. IP ranges. https://www.cloudflare.com/ips. Levin, Bruce Maggs, Alan Mislove, Aaron Schulman, and Christo Wilson. An end-to-end measurement of certificate [12] David Cooper, Stefan Santesson, Stephen Farrell, Sharon revocation in the web’s PKI. In Proceedings of the ACM Boeyen, Russell Housley, and Tim Polk. Internet X.509 Internet Measurement Conference (IMC), 2015. public key infrastructure certificate and certificate revoca- tion list (CRL) profile. RFC 5280, May 2008. [31] Diego Lopez, Antonio Pastor-Perales, Yaron Sheffer, and Thomas Fossat. Short-lived certificates and certificate [13] Matt Cooper, Yuriy Dzambasow, Peter Hesse, Susan transparency. IETF 100 Singapore, November 2017. Joseph, and Richard Nicholas. Internet X.509 public key infrastructure: Certification path building. RFC 4158, [32] Philip MacKenzie and Michael K. Reiter. Delegation of September 2005. cryptographic servers for capture-resilient devices. Dis- tributed Computing, 16(4):307–327, December 2003. [14] DigiCert. DigiCert announces certcentral enterprise, a comprehensive, all-in-one digital certificate management [33] Stephanos Matsumoto, Samuel Steffen, and Adrian Perrig. solution for enterprise cloud and hosted TLS/SSL environ- CASTLE: CA signing in a touch-less environment. In ments, January 2019. https://perma.cc/54V4-MDD2. Proceedings of the Annual Computer Security Applications Conference (ACSAC), December 2016. [15] Zakir Durumeric, James Kasten, Michael Bailey, and J Alex Halderman. Analysis of the HTTPS certificate ecosystem. [34] Mozilla. CA:RevocationPlan. https://wiki.mozilla.org/ In Proceedings of the 2013 conference on Internet measure- CA:RevocationPlan. ment conference, pages 291–304, 2013. [35] Michael Myers, Rich Ankney, Ambarish Malpani, Slava Galperin, and Carlisle Adams. X.509 internet public key [16] Zakir Durumeric, Frank Li, James Kasten, Johanna infrastructure online certificate status protocol - OCSP. Amann, Jethro Beekman, Mathias Payer, Nicolas Weaver, RFC 2560, June 1999. David Adrian, Vern Paxson, Michael Bailey, et al. The matter of Heartbleed. In Proceedings of the ACM Internet [36] Yoav Nir, Thomas Fossati, Yaron Sheffer, and Toerless Measurement conference (IMC), 2014. Eckert. Considerations for using short term certificates. Technical report, March 2018. draft-nir-saag-star-01. [17] Saba Eskandarian, Eran Messeri, Joseph Bonneau, and Dan Boneh. Certificate transparency with privacy. Proceed- [37] Devon O’Brien. Certificate Transparency Enforcement ings on Privacy Enhancing Technologies, 2017(4):329–344, in Chrome and CT Day in London. https://perma.cc/ 2017. 73NM-SHZN. [38] Chris Palmer. Intent to deprecate and remove: Public key [56] Steven Tuecke, Von Welch, Doug Engert, Laura Pearlman, pinning, 2017. https://perma.cc/MC9E-BW5H. and Mary Thompson. Internet X.509 public key infrastruc- ture (PKI) proxy certificate profile. RFC 3820, June 2004. [39] Yngve N. Pettersen. The transport layer security (TLS) multiple certificate status request extension. RFC 6961, [57] Changzheng Wei, Jian Li, Weigang Li, Ping Yu, and Haib- June 2013. ing Guan. STYX: a trusted and accelerated hierarchical SSL key management and distribution system for cloud [40] J. Ronald Prins. DigiNotar certificate authority breach based CDN application. In Proceedings of the ACM Sym- “Operation Black Tulip”. Interim report, Fox-IT, Septem- posium on Cloud Computing (SoCC), pages 201–213, 2017. ber 2011. [58] Von Welch, Ian Foster, Carl Kesselman, Olle Mulmo, Laura [41] Eric Rescorla. The transport layer security (TLS) protocol Pearlman, Steven Tuecke, Jarek Gawor, Sam Meder, and version 1.3. RFC 8446, August 2018. Frank Siebenlist. X.509 proxy certificates for dynamic [42] Ronald L. Rivest. Can we eliminate certificate revocation delegation. In Proceedings of the 3rd annual PKI R&D lists? In Proceedings of the Financial Cryptography and workshop, volume 14, 2004. Data Security Conference, 1998. [59] Peter E. Yee. Updates to the internet X.509 public key in- frastructure certificate and certificate revocation list (CRL) [43] Peter Saint-Andre and Jeff Hodges. Representation and profile. RFC 6818, January 2013. verification of domain-based application service identity within internet public key infrastructure using X.509 (PKIX) certificates in the context of transport layer secu- rity (TLS). RFC 6125, March 2011. [44] Quirin Scheitle, Oliver Gasser, Theodor Nolte, Johanna Amann, Lexi Brent, Georg Carle, Ralph Holz, Thomas C. Schmidt, and Matthias Wählisch. The rise of Certificate Transparency and its implications on the Internet ecosys- tem. In Proceedings of the ACM Internet Measurement Conference (IMC), 2018. [45] Aaron Schulman, Dave Levin, and Neil Spring. RevCast: Fast, private certificate revocation over FM radio. In Pro- ceedings of the ACM Conference on Computer and Com- munications (CCS), 2014. [46] Sectigo. Sectigo adds ACME protocol support in certificate manager platform to automate SSL lifecycle management, April 2019. [47] Emily Stark, Lin-Shung Huang, Dinesh Israni, Collin Jack- son, and Dan Boneh. The case for prefetching and preval- idating TLS server certificates. In Proceedings of the Net- work and Distributed System Security Symposium (NDSS), 2012. [48] Emily Stark, Ryan Sleevi, Rijad Muminović, Devon O’Brien, Eran Messeri, Adrienne Porter Felt, Brendan McMillion, and Parisa Tabriz. Does certificate trans- parency break the web? Measuring adoption and error rate. In Proceedings of the IEEE Symposium on Security and Privacy (S&P), 2019. [49] Douglas Stebila and Nick Sullivan. An analysis of TLS handshake proxying. In Proceedings of the IEEE Inter- national Conference on Trust, Security and Privacy in Computing and Communications (TrustCom), 2015. [50] Nick Sullivan and Watson Ladd. Delegated credentials for TLS, November 2019. https://perma.cc/4CPK-HX9Z. [51] Erik Sy, Christian Burkert, Hannes Federrath, and Mathias Fischer. Tracking users across the web via TLS session re- sumption. In Proceedings of the Annual Computer Security Applications Conference (ACSAC), 2018. [52] Pawel Szalachowski, Laurent Chuat, Taeho Lee, and Adrian Perrig. RITM: Revocation in the middle. In Proceedings of the IEEE International Conference on Distributed Com- puting Systems (ICDCS), June 2016. [53] Pawel Szalachowski, Laurent Chuat, and Adrian Perrig. PKI safety net (PKISN): Addressing the too-big-to-be- revoked problem of the TLS ecosystem. In Proceedings of the IEEE European Symposium on Security and Privacy (EuroS&P), March 2016. [54] Pawel Szalachowski, Stephanos Matsumoto, and Adrian Perrig. Policert: Secure and flexible TLS certificate man- agement. In Proceedings of the ACM Conference on Com- puter and Communications (CCS), 2014. [55] Emin Topalovic, Brennan Saeta, Lin-Shung Huang, Collin Jackson, and Dan Boneh. Towards short-lived certificates. Web 2.0 Security and Privacy, 2012.