RFC 9060
Secure Telephone Identity Revisited (STIR) Certificate Delegation
RFC 9060: Secure Telephone Identity Revisited (STIR) Certificate Delegation 🎀
Okay bestie, let's get into it! 💖 This is RFC 9060, a Standards Track document from the IETF, published in September 2021. J. Peterson from Neustar wrote it, and it lives in the ISSN 2070-1721 series. The title block doesn't list any documents it obsoletes or updates, so there's no drama there 🦋
Abstract ✨
STIR certificates are how you attest authority over telephone numbers and related identifiers, so spoofers can't just pretend to be someone else 📞 This spec explains how that authority can be delegated from a parent certificate to a subordinate one 👑 It's giving very useful for things like service providers handing credentials to enterprises or other customers who want to sign calls with STIR 💅
Status of This Memo 🌸
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Info about the current status of this document, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc9060.
Copyright Notice 🔥
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please review those documents carefully, since they describe your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License.
Table of Contents 🗂️
1. Introduction
2. Terminology
3. Motivation
4. Delegation of STIR Certificates
4.1. Scope of Delegation
5. Authentication Service Signing with Delegate Certificates
6. Verification Service Behavior for Delegate Certificate
Signatures
7. Acquiring Multiple Certificates in STIR
8. Certification Authorities and Service Providers
8.1. ACME and Delegation
8.2. Handling Multiple Certificates
9. Alternative Solutions
10. IANA Considerations
11. Privacy Considerations
12. Security Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgments
Author's Address1. Introduction 💖
The STIR problem statement [RFC7340] goes over all the mess that impersonation causes on the telephone network, like robocalling, voicemail hacking, and swatting [RFC7375]. A huge piece of stopping impersonation is having credentials that prove who controls a telephone number 🧚 The STIR certificate specification [RFC8226] describes a credential system for this. It's built on version 3 certificates [X.509], following [RFC5280]. STIR authentication services [RFC8224] can use those credentials to sign PASSporT objects [RFC8225] that get carried in SIP [RFC3261] requests.
[RFC8226] adds an extension to X.509 called the Telephony Number (TN) Authorization List, which certification authorities (CAs) can include in certificates. This extension gives relying parties extra info to use when they validate a transaction with the certificate ✨ For example, when a SIP request reaches a terminating administrative domain, the calling number it attests can be compared against the TN Authorization List of the certificate that signed the PASSporT. That tells you whether the caller is actually allowed to use that calling number 🫶
So far, deployment of [RFC8226] has mostly used Service Provider Codes (SPCs) to show the scope of a certificate's authority. These are usually internal telephone network identifiers, like the Operating Company Numbers (OCNs) given to carriers in the United States. The catch is that these network identifiers are basically unavailable to non-carrier entities, which raises the question of how those entities can take part in STIR when they need to 🥺 Also, a carrier may sometimes operate numbers that are formally assigned to a different carrier. [RFC8226] gives an overview of a certificate enrollment model based on "delegation," where the holder of a certificate can hand a subset of that certificate's authority to another party 👑 This specification details how delegation of authority works for STIR certificates.
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 read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, just like they do here 🌈
This specification also uses these terms:
- delegation: The concept of STIR certificate delegation and its terms are defined in [RFC8226].
- legitimate spoofing: The practice of choosing an alternative presentation number for a telephone caller in a legitimate way.
3. Motivation 🦋
The biggest need for delegation in STIR shows up in use cases where callers want to use a particular calling number, but for whatever reason their outbound calls won't go through the authentication service of the service provider that controls that numbering resource 😭
Picture an enterprise that places outbound calls through a bunch of service providers. For each call, a provider gets picked based on least-cost routing or some similar local policy 💅 The enterprise got its calling number from one particular service provider, but some calls from that number will go out through other providers.
A user might also roam from their usual service provider to a different network or administrative domain for all sorts of reasons. A lot of "legitimate spoofing" examples look like this, where someone wants to use the main callback number for their business as their calling party number even while they're away from the office 📞
These sorts of cases could be handled if the carrier that controls the numbering resource could delegate a credential that can sign calls no matter which network or administrative domain handles the outbound routing. Without something like a delegation mechanism, outbound carriers may be forced to sign calls with credentials that don't cover the originating number in question. That's a problem, because it would be really hard to tell apart from malicious spoofing. If it spreads, it could erode trust in STIR overall 🙈
4. Delegation of STIR Certificates 👑
STIR delegate certificates are certificates that contain a TNAuthList object and that have been signed with the private key of a parent certificate. That parent certificate itself contains a TNAuthList object, either by value or by reference (see Section 4.1). The parent certificate needs to contain a basic constraints extension with the cA boolean set to "true" [RFC5280], which indicates that the subject can sign certificates. Every STIR delegate certificate identifies its parent certificate with a standard Authority Key Identifier extension [RFC5280] 🧚
The authority the parent certificate gives to the holder of the delegate certificate is recorded in the delegate certificate's TNAuthList. STIR certificates use the TNAuthList object, not the Subject Name, to show the scope of their authority. So traditional name constraints [RFC5280] aren't directly applicable to STIR 🤷♀️ Similar to the "encompassing" semantics in the Resource Public Key Infrastructure (RPKI) [RFC6480], each delegate certificate MUST have a TNAuthList scope that is equal to or a subset of its parent certificate's scope. In other words, it must be "encompassed" 🫶
Here's an example. A parent certificate with a TNAuthList that attests authority for the numbering range +1-212-555-1000 through 1999 could issue one delegate a certificate attesting authority for the range +1-212-555-1500 through 1599. It could issue another delegate a certificate for the individual number +1-212-555-1824 ✨
Delegate certificates MAY also contain a basic constraints extension with the cA boolean set to "true", which means they can sign subordinate certificates for further delegates 💖 Only end-entity certificates can actually sign PASSporTs, though. So the holder of a STIR certificate with a "true" cA boolean may create a separate end-entity certificate. That certificate can have either an identical TNAuthList to its parent's or a subset of the parent's authority, and it's the one that would be used to sign PASSporTs 💅
More parts are coming, bestie, so stay tuned! 🎀💜
4.1. Scope of Delegation ✨
okay so a STIR certificate's TNAuthList can hold one or more SPCs, one or more telephone number ranges, or a mix of both 💅 when you delegate from one, the child certificate can inherit either or both of those, and this spec explicitly lets an SPC-only parent hand individual numbers or ranges down to a child 🫶 it's not a random allowance either, it's needed in some real operating environments 😭 depending on what kind of numbering resources the delegate got, there are different syntaxes you can use to capture the delegated resource 🦋
some non-carrier entities end up with huge, messy allocations of phone numbers that might be only partly contiguous or totally scattered 🌈 and those allocations can change often, in small ways or big ways 💀 when the resources are that complex, dynamic, or extensive, listing them all inside a certificate is just prohibitively difficult 😩 Section 10.1 of [RFC8226] describes one way to handle this: put the TNAuthList (specified in [RFC8226]) in the certificate by reference instead of by value. So a URL in the certificate points to a secure, dynamically updated list of the telephone numbers in the certificate's scope of authority 🔥 for entities that are carriers in all but name, another option is getting an SPC 👑 that gives you basically the same property, because the SPC is effectively a pointer to an external database that dynamically tracks the numbers attached to it 🧚 either approach could make sense for a given deployment, so pick your vibe 💖 and the certification path construction described below treats by-reference TNAuthLists in a certificate as if they had been included by value ✨
other non-carrier entities have really straightforward number assignments, like an enterprise that receives a set of a thousand blocks from a carrier and might keep them for years or even decades 🍓 some freephone numbers also have a long-term link to an enterprise and its brand 🎀 for these kinds of assignments, an SPC might feel like overkill, and using the TN ranges of the TNAuthList (by value) is sufficient 🌸
no matter which approach you take to represent the delegated resource, there are fundamental trade-offs about when and where in the architecture a delegation gets validated 🙈 that means when the delegated TNAuthList is checked and determined to be "encompassed" by the TNAuthList of its parent. This might happen when the delegate certificate is issued, when a verification service receives an inbound call, or potentially both 💜 it's generally desirable to offload as much of this as possible to the certification process, because verification happens during call setup, and extra network dips could cause perceptible delay 😭 whereas certification happens outside of call processing as a mostly administrative function 📋 ideally, if a delegate certificate can supply a by-value TN range, a verification service could figure out that an attested calling party number is within the scope of the certificate without making any extra transactions with a service 🦋 in practice, verification services may already bake network queries into their processing (for example, to dereference the x5u field of a PASSporT), so any extra information they need could just piggyback on those 🫶
quick note: the permission semantics of the TNAuthList [RFC8226] are additive 💅 the scope of a certificate is the superset of all the SPCs and telephone number ranges listed in the TNAuthList. Since SPCs are effectively pointers to a set of telephone number ranges, and a telephone number can belong to more than one SPC, this may add some redundancy to the set of numbers in a certificate's scope 🌈 the presence of one or more SPCs and one or more sets of telephone number ranges is treated additively in the same way, even if the ranges turn out to be redundant to an SPC's scope 🙃
5. Authentication Service Signing with Delegate Certificates 🔐
authentication service behavior differs from [RFC8224] in the ways below, but the same checks still happen when the authentication service compares the calling party number attested in call signaling with the scope of authority of the signing certificate 💖 authentication services SHOULD NOT use a delegate certificate without validating that its scope of authority is encompassed by that of its parent certificate 😤 and if that parent certificate has its own parent, the entire certification path SHOULD be validated 🧚
this delegation architecture doesn't require a non-carrier entity to act as its own authentication service 🌸 that job can be done by any authentication service that holds the private key corresponding to the delegate certificate 🍓 so it could be one run by an outbound service provider, a third party in an enterprise's outbound call path, or even the SIP User Agent itself ✨
one more thing, and it's important 🚨 authentication services creating a PASSporT for a call signed with a delegate certificate MUST provide an x5u link corresponding to the entire certification path, not just the delegate certificate used to sign the call, as described in Section 7 🫶 no shortcuts here, bestie 💅
6. Verification Service Behavior for Delegate Certificate Signatures 🦋
a verification service validating PASSporTs signed with delegate certificates still follows the baseline specifications [RFC8224] and [RFC8225] 🌈 but it needs some extra procedures on top of that 🙌 when the verification service dereferences the x5u parameter, it acquires a certificate list instead of a single certificate 📜 it MUST then validate all of the credentials in that list, identifying the parent certificate for each delegate through its Authority Key Identifier extension 🔍
okay here's the spicy bit 🌶️ relying parties normally have a lot of latitude in certification path construction when they validate a path, but STIR assumes a more rigid hierarchical subordination model 👑 so it's not one where relying parties get to derive their own certification path to particular trust anchors 🙅♀️ if the certificates acquired from the x5u element of a PASSporT don't lead to an anchor the verification service trusts, the validation gets treated no differently than when a non-delegated certificate was issued by an untrusted root 💀 in SIP, the verification service MAY return a 437 "Unsupported Credential" response if the call should be failed for lack of a valid Identity header 😭
7. Acquiring Multiple Certificates in STIR 📥
PASSporT [RFC8225] uses the x5u element to convey the URL where verification services can acquire the certificate used to sign a PASSporT 🎀 this value is mirrored by the info parameter of the Identity header when a PASSporT is conveyed via SIP 🔗 commonly, this is an HTTPS URI 🔒
when a STIR delegate certificate is used to sign a PASSporT, the x5u element in the PASSporT will contain a URI indicating where a certificate list is available 📜 the baseline JSON Web Signature (JWS) also supports an x5c element specifically for certificate chains 🧩 but in operational practice, certification paths are already being delivered in the STIR environment via the x5u element, so this specification RECOMMENDS that implementations continue to use x5u 💅 x5c is OPTIONAL for environments where it is known to be supported 🌸
that list will be a concatenation of certificates encoded with Privacy Enhanced Mail (PEM) of the type application/pem-certificate-chain defined in [RFC8555] 🍓 the certificate path [RFC5280] ordering MUST be ordered from the signer to the trust anchor 🧭 the list begins with the certificate used to sign the PASSporT, followed by its parent, then any subsequent grandparents, great-grandparents, and so on 👑 the key identifier in the Authority Key Identifier extension in the first certificate MUST appear in the Subject Key Identifier extension in the second certificate 🔑 and the key identifier pairing MUST match in this way throughout the entire chain of certificates ⛓️
one last detail from ACME 🧚 Automatic Certificate Management Environment (ACME) [RFC8555] requires the first element in a pem-certificate-chain to be an end-entity certificate 🫶
8. Certification Authorities and Service Providers 🏛️
once a telephone service provider has received a CA certificate attesting to their numbering resources, they can delegate resources from it however they see fit 💖 the allocation to a service provider of a certificate with a basic constraints extension with the cA boolean set to "true" doesn't require the service provider to act as a certification authority itself 🙌 serving as a certification authority is a function that needs specialized expertise and infrastructure, like maintaining certificate revocation lists and related functions, plus publishing certification practice statements 📋 a third-party certification authority, including the same one that issued the service provider its parent certificate, could act as the CA issuing delegate certificates for the service provider, if the business relationships allow it 🤝 in that case, a service provider might act as a Token Authority (see Section 8.1), granting its customers permissions to receive certificates from the CA 🎟️
now, if the same CA that issued the parent certificate is also issuing a delegate certificate, it may be possible to shorten the certification path 🦋 that's great because it reduces the work verification services have to do ✨ the trade-off is that if the CA simply issued a non-delegate certificate (whose parent is the CA's trust anchor) with the proper TNAuthList value, relying parties might not be able to figure out which service provider owned those telephone numbers 🤔 that info might be used to make an authorization decision on the terminating side 📞 however, some additional object in the certificate outside of the TNAuthList could preserve that information 🌈 this is a potential area for future work, and longer certification paths are the only mechanism currently defined 🛠️
all CAs must detail in their practices and policies a requirement to validate that the "encompassing" of a delegate certificate is done by its parent 📝 this requires that CAs have access to the necessary industry databases to ascertain whether, for example, a particular telephone number is encompassed by an SPC 🗂️ alternatively, a CA may acquire an Authority Token (see Section 8.1) that affirms a delegation is in the proper scope 🎫 exactly what operational practices this entails may vary across national telephone administrations, so they're left to the Certificate Policy / Certification Practice Statement (CP/CPS) [RFC3647] 🌍💜
8.1. ACME and Delegation ✨
okay so STIR deployments usually use ACME [RFC8555] to get their certificates, and it's totally expected that delegate certificates will get acquired through an ACME interface too 💅. An entity can grab a certificate from a particular CA by asking its parent for an Authority Token [ACME-CHAL] with the desired TNAuthList [ACME-TOKEN] object 🦋. Quick heads up, bestie: if the client plans to do its own further subdelegation, it should request a token with the "ca" Authority Token flag set 🫶.
Then the entity shows that Authority Token to a CA to get a STIR delegate certificate ✨. ACME hands back an "application/pem-certificate-chain" object, and that object would be perfect to publish as an HTTPS resource for retrieval with the PASSporT x5u mechanism discussed in Section 7 🌸. If the Certificate Signing Request (CSR) sent to the ACME server is for a certificate with the cA boolean set to "true", then the ACME server makes a policy decision about whether it's appropriate to issue that certificate to the requesting entity 👑. That policy decision gets reflected in the "ca" flag in the Authority Token 💜.
Service providers that want to age out delegated certificates super fast can lean on the ACME Short-Term, Automatically Renewed (STAR) [RFC8739] mechanism to automate short-term certificate expiry 🍓.
8.2. Handling Multiple Certificates 🎀
In some deployments, non-carrier entities might get telephone numbers from several different carriers 📞. That could mean enterprises need to keep a sort of STIR keyring, with different certificates delegated to them from different providers 🔑. These certificates could be issued by different CAs, and the enterprise picks between them when signing a call 💅. This could happen no matter which syntax is used in the TNAuthList to represent the scope of the delegation (see Section 4.1). As noted in Section 8, if the parent certs use the same CA, it may be possible to shorten the certification path ✂️.
For non-carrier entities handling a small number of certificates, this is probably not a significant burden 🙈. When it does become burdensome, a few potential approaches exist. A delegate certificate could be cross-certified with another delegate certificate via an Authority Information Access (AIA) field containing the URL of a Certificate Authority Issuer, so that a signer only needs to sign with a single certificate to inherit the privileges of the other certificate(s) it has cross-certified with 🧚. In very complex delegation cases, it might make more sense to establish a bridge CA that cross-certifies with all of the certificates the enterprise holds, rather than a giant mesh of cross-certification between a huge number of certificates 🌈. Again, this bridge CA function would likely be performed by some existing CA in the STIR ecosystem ✨. These procedures would, however, complicate the fairly straightforward certification path reconstruction approach described in Section 7 and would require further specification 😭.
9. Alternative Solutions 🌷
At the time this specification was written, STIR was only starting to see deployment 🌱. In some future environment, the policies that govern CAs may not permit them to issue intermediate certificates with a TNAuthList object and a cA boolean set to "true" in the basic constraints certificate extension [RFC5280] 🚫. Similar problems in the web PKI space motivated the development of TLS subcerts [TLS-CRED], which substitutes a signed "delegated credential" token for a certificate in such environments 🔐. A comparable mechanism could be developed for the STIR space, allowing STIR certificates to sign a data object that contains effectively the same data as the delegate certificate specified here, including a public key that could sign PASSporTs 💖. The TLS subcerts system has further explored leveraging ACME to issue short-lived certificates for temporary delegation as a means of skipping the need for revocation ⏳. Specification of a mechanism similar to TLS subcerts for STIR is future work and will only be undertaken if the market requires it 👑.
10. IANA Considerations 📋
This document has no IANA actions.
11. Privacy Considerations 🙈
Any STIR certificate that identifies a narrow range of telephone numbers potentially exposes information about the entities placing calls 🫣. Since such a telephone number range is a necessary superset of the calling party number that's openly signaled during call setup, the privacy risks associated with this mechanism are not substantially greater than baseline STIR 🦋. See [RFC8224] for guidance on the use of anonymization mechanisms in STIR 💜.
12. Security Considerations 🚨
This document is entirely about security 🔐💀. As delegation can allow signing-in scenarios where unauthenticated "legitimate" spoofing would otherwise be used, the hope is that delegation will improve the overall security of the STIR ecosystem 🛡️. For further information on certificate security and practices, see [RFC5280], particularly its security considerations. Also see the security considerations of [RFC8226] for general guidance on the implications of using certificates in STIR, and [RFC7375] for the STIR threat model 📚.
Much of the security of delegation depends on the implementation of the encompassing semantics described in Section 4 😤. When delegating from an SPC-based TNAuthList to a set of telephone number ranges, understanding the encompassing semantics may require access to industry databases that track the numbering assets of service providers associated with a given SPC 🗂️. In some operating environments, such databases might not exist 😬. How encompassing is policed is therefore a matter outside the scope of this document and specific to operational profiles of STIR 🙃.
The use of by-reference TNAuthLists as described in Section 4 means that the TNAuthList associated with a certificate can change over time; see the security considerations of [RFC3986] for more on the implications of this property 🌀. It is considered a useful feature here due to the potential dynamism of large lists of telephone numbers, but this dynamism means that a relying party might at one point accept that a particular telephone number is associated with a certificate, and later reject it for the same certificate as the dynamic list changes 😵. Also note that if the HTTPS service housing the by-reference telephone number list is improperly secured, that too can lead to vulnerabilities 🚨. Ultimately, the CA that issued a delegated certificate populates the URL in the AIA field and is responsible for making a secure selection 🫡. Service providers acting as CAs are directed to the cautionary words about running a CA in Section 8, regarding the obligations this entails for certificate revocation and so on 📣.
13. References 📖
13.1. Normative References 💜
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.13.2. Informative References ✨
Okay, now for the bonus reading list 📚🦋 These are the references that help explain the spec but don't make anything mandatory.
[ACME-CHAL] Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME Challenges Using an Authority Token", Work in Progress, Internet-Draft, draft-ietf-acme-authority-token-06, 12 July 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-06>.
[ACME-TOKEN] Wendt, C., Hancock, D., Barnes, M., and J. Peterson, "TNAuthList profile of ACME Authority Token", Work in Progress, Internet-Draft, draft-ietf-acme-authority-token-tnauthlist-08, 27 March 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-tnauthlist-08>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, DOI 10.17487/RFC3647, November 2003, <https://www.rfc-editor.org/info/rfc3647>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, <https://www.rfc-editor.org/info/rfc7340>.
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", RFC 7375, DOI 10.17487/RFC7375, October 2014, <https://www.rfc-editor.org/info/rfc7375>.
[RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor Perales, A., and T. Fossati, "Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)", RFC 8739, DOI 10.17487/RFC8739, March 2020, <https://www.rfc-editor.org/info/rfc8739>.
[TLS-CRED] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, "Delegated Credentials for TLS", Work in Progress, Internet-Draft, draft-ietf-tls-subcerts-10, 24 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10>.
[X.509] ITU-T, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, October 2016, <https://www.itu.int/rec/T-REC-X.509>.
Acknowledgments 🫶
A huge thank-you to Ines Robles, Richard Barnes, Chris Wendt, Dave Hancock, Russ Housley, Benjamin Kaduk, and Sean Turner 💜 They gave the key input that made this document happen, and we are so grateful 🌸
Author's Address 🎀
Jon Peterson
Neustar, Inc.
Email: jon.peterson@team.neustar
📦 where this page comes from
- ietf: rfc9060 2021-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms