RFC 8816

Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases

📅 published February 2021, from ietf

Part 1 of 7 💖

RFC 8816: Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases 🎀

Okay bestie, this one is from the Internet Engineering Task Force (IETF) 🦋. The authors are E. Rescorla at Mozilla and J. Peterson at Neustar, and it was published in February 2021. It's Informational, not a standards-track spec, with ISSN 2070-1721. Its header doesn't list any Obsoletes or Updates entries, so it doesn't replace or change any other RFC according to the header. 🌸

Abstract ✨

Okay so the Personal Assertion Token (PASSporT) format is a token that signaling protocols can carry, including SIP, to cryptographically prove who a caller is 🔐. But not every phone call uses Internet signaling, some calls only use it for part of the path, and some can't reliably deliver SIP header fields from end to end 😭. This doc covers the use cases that need PASSporT objects delivered outside the signaling path, and it defines the architectures and semantics to make that happen 🧚.

Status of This Memo

This is not an Internet Standards Track spec. It's just published for info 💅.

It's a product of the IETF, so it reflects the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for the details 👑.

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8816. 🌈

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved ©️.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 📜. Code Components pulled out of this doc must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ⚠️.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Operating Environments
   4.  Dataflows
   5.  Use Cases
     5.1.  Case 1: VoIP to PSTN Call
     5.2.  Case 2: Two Smart PSTN Endpoints
     5.3.  Case 3: PSTN to VoIP Call
     5.4.  Case 4: Gateway Out-of-Band
     5.5.  Case 5: Enterprise Call Center
   6.  Storing and Retrieving PASSporTs
     6.1.  Storage
     6.2.  Retrieval
   7.  Solution Architecture
     7.1.  Credentials and Phone Numbers
     7.2.  Call Flow
     7.3.  Security Analysis
     7.4.  Substitution Attacks
     7.5.  Rate Control for CPS Storage
   8.  Authentication and Verification Service Behavior for
           Out-of-Band
     8.1.  Authentication Service (AS)
     8.2.  Verification Service (VS)
     8.3.  Gateway Placement Services
   9.  Example HTTPS Interface to the CPS
   10. CPS Discovery
   11. Encryption Key Lookup
   12. IANA Considerations
   13. Privacy Considerations
   14. Security Considerations
   15. Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction 🎀

Okay so the STIR problem statement [RFC7340] lays out how bad impersonation is on the telephone network 😤. We're talking illegal robocalling, voicemail hacking, and swatting 💀. Phone services are moving onto the Internet and using Voice over IP (VoIP) protocols like SIP [RFC3261], so they need stronger identity mechanisms to stop impersonation 🛑. For example, [RFC8224] defines a SIP Identity header field that can carry PASSporT objects [RFC8225]. That lets the call's originator cryptographically prove they're authorized to use the calling party number (or, for native SIP cases, the SIP URI) tied to them 🔐✨.

Not every call uses SIP today, and even the ones that do don't always carry SIP signaling end-to-end 🙈. Calls from telephone numbers still routinely go through the Public Switched Telephone Network (PSTN) at some point. Broadly, calls fall into three categories:

  1. One or both of the endpoints is actually a PSTN endpoint.
  2. Both of the endpoints are non-PSTN (SIP, Jingle, etc.) but the call transits the PSTN at some point.
  3. Non-PSTN calls that do not transit the PSTN at all (such as native SIP end-to-end calls).

The first two categories cover most of the calls tied to problems like illegal robocalling 📞. Many robocalls start on the Internet but end at PSTN endpoints 😬. The core PSTN boxes are legacy gear, though, and they're unlikely to get upgraded to support an in-band authentication system at this point 🗿. So those devices basically can't be changed to pass Internet-originated signatures, or any in-band signaling data, through intact 💔. Even if there are fields for tunneling arbitrary data in traditional PSTN signaling, some legacy elements would strip the signatures out of them. Others might mess them up so badly they can't be verified anymore. For those first two categories, any in-band authentication scheme just doesn't seem practical in today's environment 🥲.

The core network of the PSTN is staying put, but the endpoints are getting more programmable and sophisticated 🤖. Landline "plain old telephone service" deployments, especially in the developed world, are shrinking and being replaced by three classes of intelligent devices: smart phones, IP Private Branch Exchanges (PBXs), and terminal adapters 📱. All three are general purpose computers, and they typically have Internet access as well as access to the PSTN. They might be used for residential, mobile, or enterprise telephone services 🏢. On top of that, various kinds of gateways are increasingly fronting for legacy PBX and PSTN switches 🌐. All of this opens up a potential path to an authentication system that gives stronger identity while leaving PSTN systems intact 🦋.

This capability is also an ideal transitional technology while in-band STIR adoption ramps up 🚀. Early adopters can use it even when the network elements in between aren't STIR-aware yet 🫶. And through various kinds of gateways, providers with a big PSTN investment can still secure their calls with STIR 💜.

So this document builds on the PASSporT [RFC8225] mechanism and the work of [RFC8224] to describe how a PASSporT object created in the originating network of a call can reach the terminating network. This works even when it can't be carried end-to-end in-band in the call signaling 🧠. The key piece is a new service defined here, called a Call Placement Service (CPS). The CPS lets the PASSporT object get stored during call processing and retrieved later for verification purposes 📦.

Quick heads-up for potential implementors: this doc only defines the operating environments where this out-of-band STIR mechanism is meant to run 👀. It gives use cases, a broad description of the components, and a potential solution architecture 💡. Different environments can have their own security requirements. A public deployment of out-of-band STIR faces way bigger challenges than a constrained intra-network deployment 😭. To flesh out storing and retrieving PASSporTs in the CPS in this context, the doc includes a strawman protocol for that purpose 🧸. But deploying this framework in any given environment would need additional specification that's outside this document's scope 📝.

2. Terminology 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. ✨

3. Operating Environments 🌸

This section describes the environments where the proposed out-of-band STIR mechanism is meant to run 🗺️. In the simplest setup, Alice calls Bob. Her call gets routed through some set of gateways and/or the PSTN that don't support end-to-end delivery of STIR 🛣️. Both Alice and Bob have smart devices that can access the Internet (maybe enterprise devices, or even end-user ones). But there's no clear telephone signaling connection between them 😩. Alice can't inject any data into signaling that Bob can read, except for the asserted destination and origination E.164 numbers 🔢. The calling party number might come from her own device or from the network. Those numbers are basically the only data that can be used for coordination between the endpoints 🫠.

                               +---------+
                              /           \
                          +---             +---+
     +----------+        /                      \        +----------+
     |          |       |        Gateways        |       |          |
     |   Alice  |<----->|         and/or         |<----->|    Bob   |
     | (caller) |       |          PSTN          |       | (callee) |
     +----------+        \                      /        +----------+
                          +---             +---+
                              \           /
                               +---------+

In a more complicated setup, Alice and/or Bob might not have a smart or programmable device. They might just have a traditional telephone 📟. But one or both of them sit behind a STIR-aware gateway that can take part in out-of-band coordination, as shown below 🎯:

                              +---------+
                             /           \
                         +---             +---+
   +----------+  +--+   /                      \   +--+  +----------+
   |          |  |  |  |        Gateways        |  |  |  |          |
   |   Alice  |<-|GW|->|         and/or         |<-|GW|->|    Bob   |
   | (caller) |  |  |  |          PSTN          |  |  |  | (callee) |
   +----------+  +--+   \                      /   +--+  +----------+
                         +---             +---+
                             \           /
                              +---------+

In a case like this, Alice might have an analog (e.g., PSTN) connection to her gateway or switch, which is responsible for her identity 📞. Similarly, the gateway verifies Alice's identity, generates the right calling party number information, and provides that number to Bob using ordinary Plain Old Telephone Service (POTS) mechanisms 🧚‍♀️💖.

4. Dataflows ✨

okay so, in these operating environments the endpoints literally cannot hand each other crypto info directly through signaling 😭 so any solution needs some rendezvous mechanism so the endpoints can actually talk. we call this the Call Placement Service (CPS) 💅, which is basically a place where a record of the call placement, here a PASSporT, can get stored for later retrieval. in principle it could carry any info, but at minimum we expect it to hold a full-form PASSporT that attests the caller, the callee, and the time of the call. the callee can use the existence of a PASSporT for an incoming call as rough validation of where that call says it came from. (see Section 11 for the limitations of this design 🙈)

this architecture doesn't force any particular kind of entity to run a CPS, and it doesn't force any way to discover one either 🦋 a CPS could live inside a network or be publicly available. a carrier could run one or more CPSes as repositories for PASSporTs for calls going to its customers, or a CPS could be built right into an enterprise PBX or even a smartphone 📱 we kept it generic on purpose, so it can fit a bunch of different STIR deployments.

there are roughly two plausible dataflow architectures for the CPS:

  1. the callee registers with the CPS. when the caller wants to call the callee, it sends the PASSporT to the CPS, and the CPS immediately forwards it to the callee.
  2. the caller stores the PASSporT with the CPS at the time of call placement. when the callee receives the call, it contacts the CPS and retrieves the PASSporT.

ok so the first one is roughly isomorphic to current VoIP protocols, and it shares their drawbacks too 😬 specifically, the callee has to keep a full-time connection to the CPS to act as a notification channel. that comes with the usual networking costs for the callee and it's especially rough for mobile endpoints 📉 honestly, if the endpoints had the capabilities to build that, they could just use SIP or some other protocol to set up a secure session. even if the media is going over the traditional PSTN, a "shadow" SIP session could carry the PASSporT 💀 so we focus on the second architecture, where the PSTN incoming call is the notification channel, and the callee can then contact the CPS to retrieve the PASSporT. in specialized environments, like a call center that gets a huge volume of incoming PSTN calls, the notification channel approach might be viable 🌸

5. Use Cases 💖

these are the motivating use cases for this mechanism. bear in mind that, just like in [RFC8224], there can be multiple Identity header fields in a single SIP INVITE, so there can be multiple PASSporTs in this out-of-band mechanism tied to a single call 🫶 for example, a SIP user agent might create a PASSporT for a call with an end-user credential, and then as the call exits the originating administrative domain, the network authentication service might create its own PASSporT for that same call. so these use cases can overlap when processing a single call, iykyk 🔥

5.1. Case 1: VoIP to PSTN Call 📞

a call starts in a SIP environment inside a STIR-aware administrative domain. the local authentication service for that domain creates a PASSporT that gets carried in band in the call per [RFC8224]. the call gets routed out of the originating administrative domain and reaches a gateway to the PSTN. eventually the call terminates on a mobile smartphone that supports this out-of-band mechanism 📱

in this use case, the originating authentication service can store the PASSporT with the appropriate CPS (following the practices in Section 10) for the target telephone number, as a fallback in case SIP signaling won't reach end-to-end 🛟 when the destination mobile smartphone gets the call over the PSTN, it consults the CPS and finds a PASSporT from the originating telephone number waiting for it. it uses that PASSporT to verify the calling party number ✨

5.2. Case 2: Two Smart PSTN Endpoints 🧠

a call starts with an enterprise PBX that has both Internet access and a built-in gateway to the PSTN, which talks through traditional telephone signaling protocols. the PBX immediately routes the call to the PSTN, but before it does, it provisions a PASSporT on the CPS associated with the target telephone number 💅

after normal PSTN routing, the call lands on a smart mobile handset that supports the STIR out-of-band mechanism. it queries the appropriate CPS over the Internet to find out if a call has been placed to it by a STIR-aware device. it finds the PASSporT the enterprise PBX provisioned and uses it to verify the calling party number 👑

5.3. Case 3: PSTN to VoIP Call 🎀

a call starts with an enterprise PBX that has both Internet access and a built-in gateway to the PSTN. it will immediately route the call to the PSTN, but before it does, it provisions a PASSporT with the CPS associated with the target telephone number 🍓 however, it turns out the call will eventually route through the PSTN to an Internet gateway, which translates it into a SIP call and delivers it to an administrative domain with a STIR verification service 😮‍💨

there are two subcases for how the PASSporT might get retrieved. in subcase 1, the Internet gateway that receives the call from the PSTN could query the appropriate CPS to find out if the original caller created and provisioned a PASSporT for this call. if so, it can retrieve the PASSporT and, when it creates a SIP INVITE for this call, add a corresponding Identity header field per [RFC8224] 🔗 when the SIP INVITE reaches the destination administrative domain, it'll be able to verify the PASSporT normally.

note: to avoid discrepancies with the Date header field value, only a full-form PASSporT should be used for this purpose 🚨

in subcase 2, the gateway doesn't retrieve the PASSporT itself. instead, the verification service at the destination administrative domain does 🫧 subcase 1 would perhaps be valuable for deployments where the destination administrative domain supports in-band STIR but not out-of-band STIR 🌈

5.4. Case 4: Gateway Out-of-Band 🌉

a call starts in the SIP world inside a STIR-aware administrative domain. the local authentication service for that domain creates a PASSporT that gets carried in band in the call per [RFC8224]. the call gets routed out of the originating administrative domain and eventually reaches a gateway to the PSTN 🚪

in this case, the originating authentication service doesn't support the out-of-band mechanism, so instead the gateway to the PSTN extracts the PASSporT from the SIP request and provisions it to the CPS. (when the call reaches the gateway to the PSTN, the gateway might first check the CPS to see if a PASSporT object was already provisioned for this call, and only provision a PASSporT if none is present 🧐)

ultimately, the call may terminate on the PSTN or get routed back into a SIP environment. in the former case, maybe the destination endpoint queries the CPS to retrieve the PASSporT provisioned by the first gateway 📲 if the call ends up returning to a SIP environment, it might be the gateway from the PSTN back to the Internet that retrieves the PASSporT from the CPS and attaches it to the new SIP INVITE it creates. or it might be the terminating administrative domain's verification service that checks the CPS when an INVITE arrives with no Identity header field 🔍 either way, the PASSporT can survive the gap in SIP coverage caused by the PSTN leg of the call 🦋

5.5. Case 5: Enterprise Call Center 🎧

a call starts from a mobile user, and a STIR authentication service operated by their carrier creates a PASSporT for the call. as the carrier forwards the call via SIP, it attaches the PASSporT to the SIP call with an Identity header field. as a fallback in case the call won't go end-to-end over SIP, the carrier also stores the PASSporT in a CPS 🛟

the call is then routed over SIP for a while, before it transitions to the PSTN and is ultimately handled by a legacy PBX at a high-volume call center 📈 the call center supports the out-of-band service and has a high-volume interface to a CPS to retrieve PASSporTs for incoming calls. agents at the call center use a general purpose computer to manage inbound calls and can receive STIR notifications through it 💻 when the PASSporT arrives at the CPS, it gets sent through a subscription/notification interface to a system that can correlate incoming calls with valid PASSporTs. the call center agent sees that a valid call from the originating number has arrived 🥳

6. Storing and Retrieving PASSporTs 🔐

the use cases show a whole variety of entities accessing the CPS to store and retrieve PASSporTs. so how the CPS authorizes storing and retrieving PASSporTs is a key design decision in the architecture 👑 the STIR architecture assumes that service providers and, in some cases, end-user devices will have credentials suitable for attesting authority over telephone numbers per [RFC8226]. those credentials are the most obvious way a CPS can authorize storing and retrieving PASSporTs 🪪 however, as use cases 3, 4, and 5 in Section 5 show, it may sometimes make sense for the entity storing or retrieving PASSporTs to be an intermediary, rather than a device tied to either the originating or terminating side of a call. those intermediaries often won't have access to STIR credentials covering the telephone numbers in question 🙃 so requiring authorization based on a credential to store PASSporTs is undesirable, though potentially acceptable if sufficient steps are taken to mitigate any privacy risk of leaking data 😬

minimizing the potential privacy exposure of using a CPS is an explicit design goal of this mechanism 🫣 ideally, the out-of-band mechanism shouldn't end up with a worse privacy situation than in-band STIR [RFC8224]. for in-band, we might say a SIP entity is authorized to receive a PASSporT if it's an intermediate or final target of the routing of a SIP request. the originator of a call can't necessarily predict the routing path a call will follow, so an out-of-band mechanism could conceivably even improve on the privacy story 💜

so broadly, the architecture recommended here is focused on permitting any entity to store encrypted PASSporTs at the CPS, indexed under the called number 🗂️ PASSporTs will be encrypted with a public key associated with the called number, so these PASSporTs can safely be retrieved by any entity, because only holders of the corresponding private key will be able to decrypt the PASSporT 🔑 this also stops the CPS itself from learning the contents of PASSporTs, and thus metadata about calls in progress. that makes the CPS a less attractive target for pervasive monitoring (see [RFC7258]) 🕵️‍♀️ as a first step, transport-level security can provide confidentiality from eavesdroppers for both storing and retrieving PASSporTs 🔒 to bolster the privacy story, prevent denial-of-service flooding of the CPS, and complicate traffic analysis, a few additional mechanisms are also recommended below 🌸✨

6.1. Storage 🎀

okay so there are a few dimensions to authorizing the storage of PASSporTs 💅. If you encrypt PASSporTs before storing them, the CPS has no way to tell if a PASSporT is valid 😭. It just holds encrypted blobs it can't open, so it can't make any authorization decision based on what's inside. There is certainly no prospect for the CPS to verify the PASSporTs itself 💀.

Note that this architecture needs clients that store PASSporTs to have access to an encryption key tied to the intended called party, the key used to encrypt the PASSporT 🔑. Finding that key needs a key lookup service (see Section 11), depending on how the CPS is architected 🧚. Some kind of key store or repository could sit right next to it, and maybe even be part of how it runs. Key discovery gets extra messy because there can be multiple entities with authority over one telephone number. A carrier, a reseller, an enterprise, and an end user might all have credentials that let them attest they're allowed to originate calls from a number, say 🙈. So PASSporTs for out-of-band use might need to be encrypted with multiple keys, in the hopes that one will be decipherable by the relying party 🤞.

Again, the most obvious way to authorize storage is to require the originator to authenticate themselves to the CPS with their STIR credential. However, since the call is indexed at the CPS under the called number, this can weaken the privacy story of the architecture, because it reveals to the CPS both the identity of the caller and the callee 👀. Moreover, it doesn't work for the gateway use cases described above. To support those, we must effectively allow any entity to store PASSporTs at a CPS. This does not degrade the anti-impersonation security of STIR, because entities who don't have the necessary credentials to sign the PASSporT won't be able to create PASSporTs that verifiers will treat as valid ✨. In this architecture, it doesn't matter whether the CPS received a PASSporT from the authentication service that created it or from an intermediary gateway downstream in the routing path, as in case 4 above. However, if literally anyone can store PASSporTs in the CPS, an attacker could easily flood it with millions of bogus PASSporTs indexed under a calling number. That would stop the called party from finding a valid PASSporT for an incoming call buried in a haystack of fake entries 😱.

The solution architecture must therefore include some sort of traffic control system to prevent flooding. Preferably, this should not require authenticating the source, as this will reveal to the CPS both the source and destination of traffic. A potential solution is discussed below in Section 7.5 🦋.

6.2. Retrieval 🌸

For retrieval, this architecture assumes that clients will contact the CPS through some sort of polling or notification interface to receive all current PASSporTs for calls destined to a particular telephone number, or block of numbers 📲.

Since PASSporTs stored at the CPS are encrypted with a key belonging to the intended destination, the CPS can safely let anyone download PASSporTs for a called number without much fear of leaking private info about calls in progress. That's provided that the CPS always returns at least one encrypted blob in response to a request, even if there was no call in progress 🫶. Otherwise, entities could poll the CPS constantly, or eavesdrop on traffic, to learn whether or not calls were in progress 👀. The CPS MUST generate at least one unique and plausible encrypted response to all retrieval requests, and these dummy encrypted PASSporTs MUST NOT be repeated for later calls. An encryption scheme needs to be carefully chosen so messages look indistinguishable from random when encrypted, so information about the called party isn't discoverable from legitimate encrypted PASSporTs 🔐.

Because the entity placing a call may discover multiple keys associated with the called party number, multiple valid PASSporTs may be stored in the CPS. A particular called party who retrieves PASSporTs from the CPS may have access to only one of those keys. So the presence of one or more PASSporTs that the called party cannot decrypt does not mean there's no call in progress. Those would look exactly like the "dummy" PASSporTs the CPS creates when no calls are in progress 🙃. A retriever will likely need to decrypt all PASSporTs it retrieves from the CPS, and may find only one that is valid 🔍.

In order to keep the CPS from learning the numbers a callee controls, callees might also request PASSporTs for numbers they do not own, which they have no hope of decrypting 🕵️. Implementations could even let a callee request PASSporTs for a range or prefix of numbers. That's a trade-off: the callee is willing to sift through bulk quantities of undecryptable PASSporTs in exchange for hiding from the CPS which numbers it controls 🧁.

Note that in out-of-band call forwarding cases, special behavior is required to manage the relationship between PASSporTs using the diversion extension [PASSPORT-DIVERT]. The originating authentication service encrypts the initial PASSporT with the public encryption key of the intended destination. But once a call is forwarded, it may go to a destination that doesn't have the matching private key, so it could not decrypt the original PASSporT 😬. This means the retargeting entity has to generate encrypted PASSporTs that show a secure chain of diversion. A retargeting storer SHOULD use the "div-o" PASSporT type, with its "opt" extension, as specified in [PASSPORT-DIVERT], in order to nest the original PASSporT within the encrypted diversion PASSporT 🪆.

7. Solution Architecture 🏰

In this section, we discuss a high-level architecture for providing the service described in the previous sections. This discussion is deliberately sketchy, focusing on broad concepts and skipping over details 🗺️. The intent here is merely to provide an overall architecture, not an implementable specification. A more concrete example of how this might be specified is given in Section 9 ✍️.

7.1. Credentials and Phone Numbers 📱

We start from the premise of the STIR problem statement [RFC7340] that phone numbers can be associated with credentials that can be used to attest ownership of numbers. For purposes of explanation, we'll assume ownership is associated with the endpoint (e.g., a smartphone), but it might just as well be associated with a provider or gateway acting for the endpoint instead 📲. It might be the case that multiple entities are able to act for a given number, provided they have the appropriate authority. [RFC8226] describes a credential system suitable for this purpose. How an entity is determined to have control of a given number is out of scope for this document 🙅‍♀️.

7.2. Call Flow 📞

An overview of the basic calling and verification process is shown below. In this diagram, we assume that Alice has the number +1.111.555.1111 and Bob has the number +2.222.555.2222 💕.

   Alice                    Call Placement Service                  Bob
   --------------------------------------------------------------------

   Store Encrypted PASSporT for 2.222.555.2222 ->

   Call from 1.111.555.1111 ------------------------------------------>


                                    <-------------- Request PASSporT(s)
                                     for 2.222.555.2222

                                    Obtain Encrypted PASSporT -------->
                                       (2.222.555.2222, 1.111.555.1111)

                                     [Ring phone with verified callerid
                                                      = 1.111.555.1111]

When Alice wants to call Bob, she contacts the CPS and stores an encrypted PASSporT on the CPS, indexed under Bob's number. The CPS then waits for retrievals for that number 🙋‍♀️.

When Alice places the call, Bob's phone would usually ring and display Alice's number (+1.111.555.1111). That's informed by the existing PSTN mechanisms for relaying a calling party number, like the Calling Party's Number (CIN) field of the Initial Address Message (IAM). But this time, Bob's phone quietly contacts the CPS and requests any current PASSporTs for calls to his number 🤫. The CPS responds with any such PASSporTs (or dummy PASSporTs if no relevant ones are currently stored). If such a PASSporT exists, and the verification service in Bob's phone decrypts it using his private key and validates it, then Bob's phone can present the calling party number information as valid ✅. Otherwise, the call is unverifiable. Note that this doesn't necessarily mean the call is bogus. Because we expect incremental deployment, many legitimate calls will be unverifiable 🌈.

7.3. Security Analysis 🔒

The primary attack we seek to prevent is an attacker convincing the callee that a given call is from some other caller C. There are two scenarios to be concerned with:

  1. The attacker wishes to impersonate a target when no call from that target is in progress.
  2. The attacker wishes to substitute himself for an existing call setup.

If an attacker can inject fake PASSporTs into the CPS or into the communication from the CPS to the callee, he can mount either attack 😈. As PASSporTs should be digitally signed by an appropriate authority for the number and verified by the callee (see Section 7.1), this should not come up in ordinary operations 🛡️. Any attacker who is aware of calls in progress can attempt to mount a race to substitute themselves, as described in Section 7.4 🏁. For privacy and robustness reasons, using TLS [RFC8446] on the originating side when storing the PASSporT at the CPS is RECOMMENDED 🔐.

The entire system depends on the security of the credential infrastructure. If the authentication credentials for a given number are compromised, then an attacker can impersonate calls from that number. However, that is no different from in-band STIR [RFC8224] 😭🚨.

A secondary attack we must also prevent is denial-of-service against the CPS, which requires some form of rate control solution that will not degrade the privacy properties of the architecture 🚦.

7.4. Substitution Attacks

okay so this one is giving con artist 🎭💅 All the CPS receipt of the PASSporT actually proves to Bob is that Alice is trying to call him (or at least was, like, very recently) 🫶 It does NOT prove that any particular incoming call is from Alice 😭 Let's say there's a callback service that rings you back at whatever number you type in. The attacker can try to fake the caller ID, like this:

    Attacker            Callback Service           CPS               Bob
    --------------------------------------------------------------------
    Place call to Bob ---------->
     (from 111.555.1111)
                                Store PASSporT for
                                CS:Bob ------------->

    Call from Attacker (forged CS caller-id info)  -------------------->

                                Call from CS ------------------------> X


                                                   <-- Retrieve PASSporT
                                                              for CS:Bob

                           PASSporT for CS:Bob ------------------------>

                                            [Ring phone with callerid =
                                               111.555.1111]

So here's the move 🕵️‍♀️ The attacker contacts the Callback Service (CS) and gives it Bob's number. That makes the CS call Bob. Same as before, the CS talks to the CPS to insert a legit PASSporT and then calls Bob. Because it's a valid CS doing the injecting, none of the security checks from above help 🙈 BUT the attacker also calls Bob at the same time, using forged caller ID that matches the CS. If they win the race against the CS, Bob's phone verifies the attacker's call (and it passes, because it's indistinguishable 💀), and the CS's call goes to busy, voicemail, or call waiting 😤

To stop a passive attacker from using traffic analysis (basically watching the timing and patterns) to figure out exactly when a call gets placed, the connection between the caller and the CPS MUST be encrypted, as recommended above 🔐 Hmm, actually I need to be precise: the text says it is essential that this connection be encrypted, so I'm keeping that full force. Authentication services could also store dummy PASSporTs at the CPS at random intervals, which makes it harder for an eavesdropper to guess that a call is about to happen 🌸

Quick note: in a SIP environment, the callee might notice there were multiple INVITEs and catch this attack 👀 But in some PSTN interworking setups, or highly intermediated networks, only one call setup attempt reaches the target, so the callee might not notice at all 🫣 Also, the success of this substitution attack depends on the attacker landing their call inside the narrow window where the PASSporT is kept at the CPS. So shortening that window means fewer chances to pull this off 🦋 Last one: smart endpoints could implement some kind of state coordination so both sides agree the call is in progress, but the ways to do that are outside the scope of this document 🧚

7.5. Rate Control for CPS Storage

okay bestie, the flooding problem 🌊 To stop a CPS from getting flooded with bogus PASSporTs, we propose using "blind signatures" (see [RFC5636]) 💜 A sender first authenticates to the CPS with its STIR credentials and gets a signed token back. That token gets presented later when it's time to store a PASSporT. The flow looks like this:

    Sender                                 CPS

    Authenticate to CPS --------------------->
    Blinded(K_temp) ------------------------->
    <------------- Sign(K_cps, Blinded(K_temp))
    [Disconnect]


    Sign(K_cps, K_temp)
    Sign(K_temp, E(K_receiver, PASSporT)) --->

So at an initial time when no call is in progress yet, a potential client connects to the CPS, authenticates, and sends a blinded version of a freshly generated public key 🔑 The CPS sends back a signed version of that blinded key. The sender can then unblind it and end up with a signature on K_temp from the CPS ✨

Then later, when a client wants to store a PASSporT, it connects to the CPS anonymously (ideally over a network connection that can't be linked to the token acquisition 🕶️). It sends both the signed K_temp and its own signature over the encrypted PASSporT. The CPS checks both signatures and, if they verify, stores the encrypted passport and throws away the signatures 🗑️

This design lets the CPS rate limit how many PASSporTs a sender can store, just by counting how many times K_temp shows up 📊 The CPS policy might reject storage attempts and make the sender get a new K_temp after storing more than a certain number of PASSporTs indexed under the same destination number in a short interval. Of course, this doesn't let the CPS tell when bogus data is being sent by an attacker, only how fast data is coming in 🙃 Feedback mechanisms could potentially be developed so called parties can tell the CPS when they're getting weird or bogus PASSporTs 📣

This architecture also assumes the CPS will age out PASSporTs 🧹 A CPS SHOULD NOT keep any stored PASSporT for longer than the recommended freshness policy for the "iat" value described in [RFC8224] (that's sixty seconds, i.e., sixty seconds) unless some local policy for the CPS deployment requires a longer or shorter interval. Any shrinking of this window makes substitution attacks (see Section 7.4) harder to pull off, but if the window gets too small, PASSporTs might age out while a heavily redirected call is still alerting 😬

An alternative to blind signatures would be verifiable oblivious pseudorandom functions (VOPRFs, per [PRIVACY-PASS]), which may prove faster ⚡

  1. Authentication and Verification Service Behavior for Out-of-Band

okay so [RFC8224] defines an authentication service and a verification service as functions that act in the context of SIP requests and responses 📞 This specification gives a more generic description of authentication service and verification service behavior that might or might not involve any SIP transactions. It only depends on placing a request for communications from an originating identity to one or more destination identities 🌈

8.1. Authentication Service (AS)

Out-of-band authentication services do steps similar to those in [RFC8224], with some exceptions 🎀

Step 1: The authentication service MUST determine whether it is authoritative for the identity of the originator of the request, meaning the identity it will put in the "orig" claim of the PASSporT 👑 It can only do this if it has the private key for one or more credentials that can sign for that identity, whether that's a domain, a telephone number, or some other identifier. For example, the authentication service could hold the private key tied to a STIR certificate [RFC8225] 🔐

Step 2: The authentication service MUST determine that the originator of communications can claim the originating identity. This is a policy decision the authentication service makes, based on its relationship to the originator 🧐 For an out-of-band app built into the calling device, for example, this is the same check as Step 1: does the calling device hold a private key, one corresponding to a STIR certificate, that can sign for the originating identity? 📱

Step 3: The authentication service MUST acquire the public encryption key of the destination, which gets used to encrypt the PASSporT (see Section 11) 🗝️ It MUST also discover (see Section 10) the CPS associated with the destination. The authentication service might already have the encryption key and destination CPS cached, or it may need to query a service to get the key. Note that per Section 7.5, the authentication service may also need to get a token for PASSporT storage from the CPS upon CPS discovery 🎟️ The discovery mechanism (see Section 10) used to find the right CPS is expected to also find the proper key server for the destination's public key, too 🧭 In some cases, a destination may have multiple public encryption keys associated with it. In that case, the authentication service MUST collect all of those keys 🗂️

Step 4: The authentication service MUST create the PASSporT object. That includes getting the system time to fill in the "iat" claim, and filling in the "orig" and "dest" claims as described in [RFC8225] ⏰ The authentication service MUST then encrypt the PASSporT. If in Step 3 it found multiple public keys for the destination, it MUST create one encrypted copy for each public key it found 🫧

Finally, the authentication service stores the encrypted PASSporT(s) at the CPS it found in Step 3. Only after that is done should any call get started 🚦 A call might be initiated over SIP, and then the authentication service would put the same PASSporT in the Identity header field value of the SIP request. Though SIP would carry a cleartext version instead of the encrypted version sent to the CPS 🙊 In that case, out-of-band would be a fallback mechanism if the request wasn't conveyed over SIP end-to-end 🛟 Also, the authentication service MAY use a compact form of the PASSporT for a SIP request, whereas the version stored at the CPS MUST always be a full-form PASSporT 💖

8.2. Verification Service (VS) 🎀

okay so when a call shows up, an out-of-band verification service runs steps that are basically like the ones in [RFC8224] 💅 with a few twists. ✨

Step 1: 🔍 The verification service asks the CPS for every current PASSporT tied to its destination number. Or, in some setups, the CPS can just push PASSporTs over to it through a push interface. Either way, the verification service MUST then decrypt all PASSporTs using its private key. 🔐 Some of them won't decrypt, and there are a bunch of reasons why. They might be meant for a different verification service, or they might be "dummy" values the CPS slipped in for privacy. 🙈 The next few steps narrow down that first decryptable batch so the verification service only looks at the good stuff. 💖

Step 2: 🧩 The verification service MUST check whether any "ppt" extensions in the PASSporTs are unsupported. Then it keeps only the supported PASSporTs and runs the next step on those. 🫶

Step 3: 📞 The verification service MUST check whether the calling party number in the call signaling overlaps with the "orig" field of any decrypted PASSporTs. It keeps the matches and moves them along. ✨

Step 4: 🪪 The verification service MUST check whether the credentials that signed each PASSporT are valid, and whether it trusts the CA that issued them. The trusted PASSporTs head to the next step. 👑

Step 5: ⏰ The verification service MUST check how fresh the "iat" claim is for each PASSporT. The exact freshness window is up to local policy, so it's totally up to the implementer. 🌸 The fresh PASSporTs go on to the next step.

Step 6: 🔏 The verification service MUST check the signature over each PASSporT, following [RFC8225]. 🦋

At the end of all that, the verification service is left with one or more valid PASSporTs for the call it got. 🎉 Keeping with baseline STIR, this document doesn't dictate how a call with valid PASSporTs should be treated. What happens next depends on how the verification service is built and on local policy. 💅 That said, it's expected that local policies could lead to different forwarding decisions in intermediary implementations, or change how the user gets alerted or how the identity is displayed in user agent implementations. 🌈

8.3. Gateway Placement Services 🌉

The STIR out-of-band mechanism also works with gateway placement services. These don't create PASSporTs themselves. Instead, they pull PASSporTs out of signaling protocols and store them at a CPS before gatewaying to a protocol that can't carry PASSporTs itself. 🧚 For example, a SIP gateway that sends calls to the PSTN could get a call with an Identity header field, pull a PASSporT out of that Identity header field, and store that PASSporT at a CPS. 📦

To place a PASSporT at a CPS, a gateway MUST perform Step 3 of Section 8.1 above. In other words, it has to discover the CPS and public key tied to the call's destination, and it may need to get a PASSporT storage token (see Section 6.1). 🔑 Per Step 3 of Section 8.1, this could mean discovering several keys. ✨ The gateway then collects the in-band PASSporT(s) from the in-band signaling, encrypts them, and stores them at the CPS. 🔐

A similar service could be done by a gateway that pulls PASSporTs from a CPS and drops them into signaling protocols that support carrying PASSporTs in-band. 🦋 This behavior may be defined by future specifications. 🔮

9. Example HTTPS Interface to the CPS 🌸

Here's a rough example of a CPS implementation that uses a Representational State Transfer (REST) API [REST] to store and retrieve objects at the CPS. 💻 The calling party stores the PASSporT at the CPS before starting the call, and the PASSporT goes to a spot at the CPS that matches the called number. 📍 Multiple parties can be calling the same number at the same time. For big call centers especially, a ton of PASSporTs could be stored at once, and it might be hard to match them up with incoming calls. 😭

Let's say an authentication service made the following PASSporT for a call to the telephone number 2.222.555.2222. (These are dummy values, babe.) 🙈

      eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9
      jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI
      jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6
      IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd
      3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ

Through some discovery mechanism (see Section 10), the authentication service finds the network location of a web service that acts as the CPS for 2.222.555.2222. ✨ Through that same mechanism, let's say it also found one public encryption key for that destination. It uses that key to encrypt the PASSporT, and the result is this encrypted PASSporT: 🔐

      rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
      MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
      nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
      wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
      IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j

Once the numbered steps in Section 8.1 are done, including getting any token (per Section 6.1) needed to store the PASSporT at the CPS, the authentication service stores the encrypted PASSporT. 🚀

      POST /cps/2.222.555.2222/ppts HTTP/1.1
      Host: cps.example.com
      Content-Type: application/passport

      rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
      MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
      nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
      wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
      IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j

The web service gives this encrypted PASSporT a new spot in the collection and replies with a 201 OK, along with the location /cps/2.222.222.2222/ppts/ppt1. 🎀 Now the authentication service can place the call, and that can be signaled through various protocols. 📲 Once the call reaches the terminating side, a verification service asks its CPS for the set of incoming calls for its telephone number (2.222.222.2222). 💌

      GET /cps/2.222.555.2222/ppts
      Host: cps.example.com

That gets the verification service a list of the PASSporTs currently in the collection, which right now is just /cps/2.222.222.2222/ppts/ppt1. 📋 The verification service then sends a new GET for /cps/2.222.555.2222/ppts/ppt1/, and it gets back:

      HTTP/1.1 200 OK
      Content-Type: application/passport
      Link: <https://cps.example.com/cps/2.222.555.2222/ppts>

      rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
      MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
      nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
      wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
      IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j

That wraps up Step 1 of Section 8.2. Next, the verification service goes on to process that PASSporT through its various checks. 🧐 A complete protocol description for CPS interactions is left to future work. 🛠️

10. CPS Discovery 🗺️

To make the two ends of the out-of-band dataflow work together, they have to agree on a way to discover a CPS and retrieve PASSporT objects from it, using only the rendezvous information they have: the calling party number and the called number. 📞 Since PASSporTs in this architecture are indexed by the called party number, it makes sense to discover a CPS based on the called party number too. 💡 There are a number of possible service discovery mechanisms that could work here, and the approach can change depending on the use case. 🌈

Even though most of the discussion above is about a single CPS, having a huge chunk of all telephone calls store and retrieve PASSporTs at one monolithic CPS would cause obvious scaling problems. It would also let that CPS collect metadata about a very wide set of callers and callees. 😬 Operational models with a federated CPS can help with these issues. Any service discovery mechanism for out-of-band STIR should make it possible to federate the CPS function. 🫶 Likely models include a carrier running one or more CPS instances for its customers, an enterprise running a CPS instance for its PBX users, or a third-party service provider offering a CPS as a cloud service. ☁️

Some service discovery possibilities under consideration include the following:

  • 🔒 For some deployments in closed (e.g., intra-network) environments, the CPS location can simply be provisioned in implementations, so there's no need for a discovery protocol.
  • 📇 If a credential lookup service is already available (see Section 11), the CPS location can also be recorded in the callee's credentials. An extension to [RFC8226] could, for example, provide a link to the location of the CPS where PASSporTs should be stored for a destination.
  • ☎️ There are a number of common directory systems that might be used to translate telephone numbers into the URIs of a CPS. ENUM [RFC6116] is commonly implemented, though no "golden root" central ENUM administration exists that could be easily reused today to help the endpoints discover a common CPS. Other protocols associated with queries for telephone numbers, such as the Telephone-Related Information (TeRI) protocol [MODERN-TERI], could also serve for this application.
  • 🌐 Another possibility is to use a single distributed service for this function. Verification Involving PSTN Reachability (VIPR) [VIPR-OVERVIEW] proposed a REsource LOcation And Discovery (RELOAD) [RFC6940] usage for telephone numbers to help direct calls to enterprises on the Internet. It would be possible to describe a similar RELOAD usage to identify the CPS where calls for a particular telephone number should be stored. One advantage that the STIR architecture has over VIPR is that it assumes a credential system that proves authority over telephone numbers. Those credentials could be used to determine whether or not a CPS could legitimately claim to be the proper store for a given telephone number. 👑

This document doesn't prescribe any single way to do service discovery for a CPS. 🙌 It's expected that initial deployments will provision the location of the CPS at the authentication service and verification service. ✨

11. Encryption Key Lookup ✨

okay so bestie, to encrypt a PASSporT (see Section 6.1) the caller needs the callee's public encryption key 🔐 and here's the twist: STIR signs PASSporTs with the Elliptic Curve Digital Signature Algorithm (ECDSA), so the public key used to verify PASSporTs is NOT the right key for this job 🙅‍♀️ which means the encryption key has to be discovered separately. that needs some kind of directory/lookup system 📖

some early STIR deployments already have certificate repositories up 🗂️ so verification services can grab the signing credentials for PASSporTs, linked through a URI in the x5u element of the PASSporT. those same repos could literally be repurposed so authentication services can download the callee's public encryption key too 🙌 as long as calling parties can actually find them. this document doesn't pick a discovery scheme, it just gives some general vibes about possible approaches 🌸

it's a desirable property for a party's public encryption key to be linked to their STIR credential 💜 one idea: an Elliptic Curve Diffie-Hellman (ECDH) [RFC7748] public-private key pair could be generated for a subcert [TLS-SUBCERTS] of the STIR credential. that subcert could get looked up alongside the called party's STIR credential. the details of this subcert and the exact lookup mechanism are being saved for future protocol work 🔮

now the privacy tea ☕ if there's one central database that the caller and callee both hit in real time to download each other's keys, that's a real privacy risk, because the central key database would learn about every single call 😳 a few mechanisms could help with that:

  • Have endpoints pre-fetch keys for potential counterparties (e.g., their address book or the entire database).
  • Have caching servers in the user's network that proxy their fetches and thus conceal the relationship between the user and the keys they are fetching.

and honestly there's a privacy/timeliness trade-off here 🤏 getting up-to-date knowledge about credential validity means contacting the credential directory in real time (e.g., via the Online Certificate Status Protocol (OCSP) [RFC6960]). this gets somewhat softened for the caller's credentials, since they can grab short-term credentials right before placing a call, which only reveals their calling rate and not who they're calling 📞 alternately, the CPS can verify the caller's credentials via OCSP, though of course that means the callee has to trust the CPS's verification 🤝 this approach doesn't work as well for the callee's credentials, BUT the risk there is more modest, since an attacker would need to both have the callee's credentials and regularly poll the database for every potential caller 🥱

we consider the exact best point in this trade-off space to be an open issue 🧩

12. IANA Considerations 🎀

this document has no IANA actions 💅

13. Privacy Considerations 🦋

okay privacy era 🫶 delivering PASSporTs out-of-band has a totally different set of privacy properties than traditional in-band STIR. in-band stuff puts PASSporTs in SIP headers in cleartext, which means any forwarding intermediaries can inspect them 👀 out-of-band STIR instead stores these PASSporTs at a service after encrypting them (as described in Section 6). that creates a path between the authentication and verification service where the CPS is the sole intermediary, but the CPS can't actually read the PASSporTs 🔒 so out-of-band PASSporT delivery could improve on the privacy story of STIR. iconic 👑

the principal actors in out-of-band operation are the AS, VS, and CPS 🧚 the AS and VS functions differ from baseline behavior [RFC8224] because they talk to a CPS over a non-SIP interface, and the REST interface in Section 9 is an example of that 🌐 some out-of-band deployments might also need a discovery service for the CPS itself (Section 10) and/or for encryption keys (Section 11). so even with encrypted PASSporTs, the network interactions between the AS, VS, and CPS (and to a lesser extent any discovery services) create potential openings for data leakage about calling and called parties 🙈

the act of storing and retrieving PASSporTs at a CPS can itself reveal info about calls being placed 📱 the mechanism deliberately avoids requiring the AS to authenticate itself to the CPS, and relies on a blind signature mechanism for flood control prevention instead 🛡️ Section 7.4 talks about storing "dummy" PASSporTs at random intervals to thwart traffic analysis 🎭 and as Section 8.2 notes, a CPS is required to return a dummy PASSporT even if nothing is indexed for that calling number. that similarly lets the retrieval side randomly request PASSporTs when there are no calls in progress, which is a very clever little cover move 🕵️‍♀️ also, the caller's IP address itself leaks info about the caller 😬 proxying the storage of the CPS through some third party could help prevent that attack. it might also be possible to use a more sophisticated system such as Riposte [RIPOSTE] 🧪 these measures can help mitigate information disclosure in the system. for implementations that require service discovery (see Section 10), perhaps through key discovery (Section 11), similar measures could make sure that service discovery doesn't itself disclose info about calls 🍓

ultimately this document only provides a framework for future implementation of out-of-band systems 🖼️ the privacy properties of any given implementation depend on the architectural assumptions made in that environment. more closed systems for intranet operations may adopt a weaker security posture but otherwise mitigate the risks of information disclosure, whereas more open environments will require careful implementation of the practices described here 🌈

for general privacy risks associated with STIR operations, also see the privacy considerations covered in Section 11 of [RFC8224] 📚

14. Security Considerations 💀

this entire document is about security 🚨 but the detailed security properties will vary depending on how the framework is applied and deployed. general guidance for dealing with the most obvious security challenges posed by this framework is given in Sections 7.3 and 7.4, along with proposed solutions for problems like denial-of-service attacks or traffic analysis against the CPS.

okay real talk 🥹 there are considerable security challenges with widespread deployment of a public CPS, but those have to be weighed against the potential usefulness of a service that delivers a STIR assurance without requiring end-to-end SIP to pass through 💫 ultimately, the security properties of this mechanism are at least comparable to in-band STIR. the substitution attack documented in Section 7.4 could be carried out by any in-band SIP intermediary or eavesdropper who happened to see the PASSporT in transit, say, and launched its own call with a copy of that PASSporT to race the original to the destination 🏎️💨 so yeah, not a new kind of problem, just a very dramatic one 😭

15. Informative References ✨

Okay bestie, here are the receipts 📚 Every informative reference the spec leans on, with all the details, no cap 💅

Acknowledgments 🫶

The ideas in this doc came out of chats with Richard Barnes and Cullen Jennings, so they get all the credit for the spark ✨ We also want to thank Russ Housley, Chris Wendt, Eric Burger, Mary Barnes, Ben Campbell, Ted Huang, Jonathan Rosenberg, and Robert Sparks for their super helpful suggestions 💖

Authors' Addresses 🎀

Meet the authors, bestie 🧚

Eric Rescorla
Mozilla

Email: ekr@rtfm.com


Jon Peterson
Neustar, Inc.
1800 Sutter St Suite 570
Concord, CA 94520
United States of America

Email: jon.peterson@team.neustar
📦 where this page comes from