Secure Telephone Identity Revisited                             C. Wendt
Internet-Draft                                                  R. Sliwa
Intended status: Informational                               Somos, Inc.
Expires: 9 January 2025                                      A. Fenichel
                                                              TransNexus
                                                           V. A. Gaikwad
                                                                  Twilio
                                                             8 July 2024


                      STI Certificate Transparency
              draft-wendt-stir-certificate-transparency-02

Abstract

   This document describes a framework for the use of the Certificate
   Transparency (CT) protocol for publicly logging the existence of
   Secure Telephone Identity (STI) certificates as they are issued or
   observed.  This allows any interested party that is part of the STI
   eco-system to audit STI certification authority (CA) activity and
   audit both the issuance of suspect certificates and the certificate
   logs themselves.  The intent is for the establishment of a level of
   trust in the STI eco-system that depends on the verification of
   telephone numbers requiring and refusing to honor STI certificates
   that do not appear in a established log.  This effectively
   establishes the precedent that STI CAs must add all issued
   certificates to the logs and thus establishes unique association of
   STI certificates to an authorized provider or assignee of a telephone
   number resource.  The primary role of CT in the STI ecosystem is for
   verifiable trust in the avoidance of issuance of unauthorized
   duplicate telephone number level delegate certificates or provider
   level certificates.  This provides a robust auditable mechanism for
   the detection of unauthorized creation of certificate credentials for
   illegitimate spoofing of telephone numbers or service provider codes
   (SPC).

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://appliedbits.github.io/draft-wendt-stir-certificate-
   transparency/draft-wendt-stir-certificate-transparency.html.  Status
   information for this document may be found at
   https://datatracker.ietf.org/doc/draft-wendt-stir-certificate-
   transparency/.





Wendt, et al.            Expires 9 January 2025                 [Page 1]

RFC 2                            STI CT                        July 2024


   Discussion of this document takes place on the Secure Telephone
   Identity Revisited Working Group mailing list (mailto:stir@ietf.org),
   which is archived at https://mailarchive.ietf.org/arch/browse/stir/.
   Subscribe at https://www.ietf.org/mailman/listinfo/stir/.

   Source for this draft and an issue tracker can be found at
   https://github.com/appliedbits/draft-wendt-stir-certificate-
   transparency.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 9 January 2025.

Copyright Notice

   Copyright (c) 2024 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) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  The Use of Certificate Transparency for STI Certificates  . .   5
   4.  Submitters  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Certificates  . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Log Format and Operation  . . . . . . . . . . . . . . . . . .   6



Wendt, et al.            Expires 9 January 2025                 [Page 2]

RFC 2                            STI CT                        July 2024


   6.  STIR Authentication Services  . . . . . . . . . . . . . . . .   6
   7.  PASSporT Claim "sct" Definition and Usage . . . . . . . . . .   6
   8.  Clients . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Submission and Handling of SCTs . . . . . . . . . . . . .   7
     8.2.  Example API Calls for Step-by-Step Flow . . . . . . . . .   8
     8.3.  Monitor . . . . . . . . . . . . . . . . . . . . . . . . .   9
       8.3.1.  Monitor Workflow  . . . . . . . . . . . . . . . . . .   9
     8.4.  Auditing  . . . . . . . . . . . . . . . . . . . . . . . .  11
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  JSON Web Token Claim . . . . . . . . . . . . . . . . . .  12
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Certificate Transparency (CT) aims to mitigate the problem of mis-
   issued certificates by providing append-only logs of issued
   certificates.  The logs do not themselves prevent mis-issuance, but
   ensure that interested parties (particularly those named in
   certificates or certificate chains) can detect such mis-issuance.
   [RFC9162] describes the core protocols and mechanisms for use of CT
   for the purposes of public TLS server certificates associated with a
   domain name as part of the public domain name system (DNS).  This
   document describes a conceptually similar framework that directly
   borrows concepts like transparency receipts in the form of SCPs but
   also is more opinionated about the process and procedures for when
   the receipt is generated and how it is used outside of the
   certificate.  This framework is defined for the specific use with
   Secure Telephone Identity (STI) certificates [RFC8226] and delegate
   certificates [RFC9060].

   Telephone numbers (TNs) and their management and assignment by
   telephone service providers and Responsible Organizations (RespOrgs)
   for toll-free numbers share many similarities to the Domain Name
   System (DNS) where there is a global uniqueness and established
   association of telephone numbers to regulatory jurisdictions that
   manage the allocation and assignment of telephone numbers under
   country codes and a set of numeric digits for routing telephone calls
   and messages over telephone networks.  STI Certificates use a
   TNAuthList extension defined in [RFC8226] to specifically associate
   either telephone service providers or telephone numbers to the
   issuance of STI certificates and certificate change that are intended
   to represent the authorized right to use a telephone number.  This
   trusted association can be establish via mechanisms such as Authority
   tokens for TNAuthList defined in [RFC9448].  Certificate transparency
   is generally meant to provide a publicly verifiable and auditable



Wendt, et al.            Expires 9 January 2025                 [Page 3]

RFC 2                            STI CT                        July 2024


   representation of the creation of certificates in order to establish
   transparency and trust to interested parties as part of a stir
   related eco-system.

   There is three primary actors in the certificate transparency
   framework.  There is the STI Certification Authorities (CAs) that
   submit all certificates to be issued to one or more log services.
   The log services are network services that implement the protocol
   operations for submissions of STI certificates and subsequent
   queries.  They are hosted by interested parties in the STI ecosystem
   and can accept certificate log submissions from any other CA
   participant.  The second role is the monitors that play the role of
   monitoring the CT logs to check for potential mis-issuance as well as
   auditing of the log services.  This role can be played by any STI
   ecosystem participant interested in the trust of the ecosystem or the
   integrity of the telephone number or provider level certificates
   produced in the eco-system.  CT provides a mechanism of a receipt or
   Signed Certificate Timestamp (SCT) that is provided as a result of
   submitting a certificate to the append-only log.  The third actor
   role in the certificate transparency framework is the eco-system
   participants that can send and receive receipt(s) or SCT(s) to prove
   and validate that a certificate was submitted to a log(s) and
   optionally query the log directly for further validation.

   The details that follow in this document will detail the specific
   protocols and framework for Certificate Transparency associated with
   STI certificates.  Most of the details borrow many of the concepts of
   certificate transparency defined in [RFC9162] used in Web PKI
   environments, but provides a specific framework designed for STI
   certificates and their specific issuance and usage in a
   telecommunications environments.

   This general mechanism could also be used for transparently logging
   other important stir related metadata associations perhaps via
   JWTClaimConstraints defined in [RFC8226] and [RFC9118] or other ways
   defined in potential future extensions of this document.

2.  Conventions and Definitions

   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.







Wendt, et al.            Expires 9 January 2025                 [Page 4]

RFC 2                            STI CT                        July 2024


3.  The Use of Certificate Transparency for STI Certificates

   CT log(s) contains certificate chains, which can be submitted by any
   CA authorized in a STIR eco-system.  It is expected that these CAs
   will contribute all their newly issued certificates to one or more
   logs.  Note, in [RFC9162] it is possible for certificate holders to
   directly contribute their own certificate chains or interested third
   parties, however because in stir eco-systems that generally consist
   of entities that are authorized to be assigned telephone number
   resources, this does not seem to be a likely scenario.  Generally,
   many stir eco-systems have a controlled set of CAs that are
   authorized to participate as valid trust anchors.  It is required
   that each chain ends with a trust anchor that is accepted by the log
   which would include those authorized trust anchors or a subset of
   them.  When a chain is accepted by a log, a signed timestamp is
   returned, which is later used to provide evidence to STIR
   verification services (VS), defined in [RFC8224], that the chain has
   been submitted.  A VS can thus require that all certificates they
   accept as valid are accompanied by signed timestamps.

   Those concerned about mis-issuance of stir certificates can monitor
   the logs, asking them regularly for all new entries, and can thus
   check whether the providers or telephone numbers for which they are
   responsible have had certificates issued that they did not expect.
   What they do with this information, particularly when they find that
   a mis-issuance has happened, is beyond the scope of this document.
   However, broadly speaking, because many existing STI ecosystems have
   a connection to regulated and industry environments that govern the
   issuance of STI certificates, they can invoke existing mechanisms for
   dealing with issues such as mis-issued certificates, such as working
   with the CA to get the certificate revoked or with maintainers of
   trust anchor lists to get the CA removed.

4.  Submitters

   Submitters submit certificates to logs for public auditing.  In order
   to enable attribution of each logged certificate to its issuer, each
   submission MUST be accompanied by all additional certificates
   required to verify the chain up to an accepted trust anchor.  The
   trust anchor (a root or intermediate CA certificate) MAY be omitted
   from the submission.

   If a log accepts a submission, it will return a Signed Certificate
   Timestamp (SCT) (see Section 4.8 [RFC9162]).







Wendt, et al.            Expires 9 January 2025                 [Page 5]

RFC 2                            STI CT                        July 2024


4.1.  Certificates

   Any entity, generally a STIR CA, can submit [RFC8226] defined
   certificates or [RFC9060] defined delegate certificates or similarly
   defined STIR certificates to a log.  Since it is anticipated that
   verification services could reject certificates that are not logged,
   it is expected that certificate issuers and subjects will be strongly
   motivated to submit them.

5.  Log Format and Operation

   A log is a single, append-only, merkel-tree type of log of submitted
   certificate entries.  Log procedures are RECOMMENDED to follow
   similar procedures and formats defined in Section 4 of [RFC9162], but
   in general only are required to follow the API interfaces defined in
   this document.

6.  STIR Authentication Services

   STIR Authentication Services [RFC8224] MUST present one or more SCTs
   from one or more logs by the inclusion of an array of SCTs as a 'sct'
   claim in the signed PASSporT defined in the next section of this
   document.

7.  PASSporT Claim "sct" Definition and Usage

   This document defines a new JSON Web Token claim for "sct", Signed
   Certificate Timestamp, the value of which is a JSON object that can
   contains an array of one or more Signed Certificate Timestamps
   defined in [RFC9162], Section 4.8 corresponding to SCTs provided by
   different CT logs the certificate may have been submitted to.

   Example PASSporT with SCT Claim:

   {
      "dest":{"tn":["12155550131"]},
      "iat":"1443208345",
      "orig":{"tn":"12155550121"},
      "sct": ["base64-encoded-sct1", "base64-encoded-sct2"]
   }

8.  Clients

   There are various different functions clients of logs might perform.
   In this document, the client generally refers to the STI verification
   service defined in [RFC8224], or more generally an entity that
   performs the verification of a PASSporT defined in [RFC8225].  We
   describe here some typical clients and how they should function.



Wendt, et al.            Expires 9 January 2025                 [Page 6]

RFC 2                            STI CT                        July 2024


8.1.  Submission and Handling of SCTs

   1.  STI-CA/STI-SCA Submits STI Certificate to Transparency Logs:

   *  Step 1: The STI Certificate Authority (STI-CA) or STI Subordinate
      Certificate Authority (STI-SCA) issues a new STI certificate.

   *  Step 2: The STI-CA/STI-SCA submits the issued STI certificate to
      one or more transparency logs using the 'submit-entry' API.

   API Call:
   POST <Base URL>/ct/v2/submit-entry
   Content-Type: application/json
   {
      "submission": "base64-encoded-sti-certificate",
      "type": 1,
      "chain": [
         "base64-encoded-CA-cert-1",
         "base64-encoded-CA-cert-2"
      ]
   }

   Expected Response:
   {
      "sct": "base64-encoded-sct",
      "sth": "base64-encoded-signed_tree_head",
      "inclusion": "base64-encoded-inclusion_proof"
   }

   1.  Transparency Log Generates SCT:

   *  Step 3: Each transparency log processes the submission and
      generates a Signed Certificate Timestamp (SCT).

   *  Step 4: The transparency log returns the SCT to the STI-CA/STI-
      SCA.

   1.  STI-CA/STI-SCA Passes SCT(s) to STI-AS:

   *  Step 5: The STI-CA/STI-SCA passes the generated SCT(s) to the STI
      Authentication Service (STI-AS).  This can be done via a non-
      prescriptive method such as including SCT(s) in the certificate
      issuance metadata or through a separate communication channel.

   1.  STI-AS Includes SCTs in sct Claim:

   *  Step 6: The STI-AS includes the SCTs in the sct claim of the
      PASSporT (Personal Assertion Token) when signing a call identity.



Wendt, et al.            Expires 9 January 2025                 [Page 7]

RFC 2                            STI CT                        July 2024


   *  Step 7: If some logs are slow to respond, their SCTs may be
      skipped to ensure timely processing.

   1.  STI-VS Verifies PASSporT and SCTs:

   *  Step 8: The STI Verification Service (STI-VS) receives the signed
      PASSporT from the STI-AS.

   *  Step 9: The STI-VS verifies that the PASSporT contains matching
      SCTs for the certificate it was signed with.  The STI-VS checks
      for the presence of SCT(s) and trusts them for quick verification.

   *  Step 10: In the background, a separate process can periodically
      gather and verify the SCTs with the transparency logs to ensure
      their validity and integrity.

8.2.  Example API Calls for Step-by-Step Flow

   1.  Submit Entry to Log:

   POST <Base URL>/ct/v2/submit-entry
   Content-Type: application/json
   {
      "submission": "base64-encoded-sti-certificate",
      "type": 1,
      "chain": [
         "base64-encoded-CA-cert-1",
         "base64-encoded-CA-cert-2"
      ]
   }

   1.  Retrieve Latest STH (optional for background process):

   GET <Base URL>/ct/v2/get-sth

   Expected Response:
   {
      "sth": "base64-encoded-signed_tree_head_v2"
   }

   1.  Retrieve Merkle Inclusion Proof by Leaf Hash (optional for
       background process):









Wendt, et al.            Expires 9 January 2025                 [Page 8]

RFC 2                            STI CT                        July 2024


GET <Base URL>/ct/v2/get-proof-by-hash?hash=base64-encoded-hash&tree_size=tree-size

Expected Response:
{
   "inclusion": "base64-encoded-inclusion_proof_v2",
   "sth": "base64-encoded-signed_tree_head_v2"
}

   1.  Retrieve Entries and STH from Log (optional for background
       process):

   GET <Base URL>/ct/v2/get-entries?start=0&end=99

   Expected Response:
   {
      "entries": [
         {
            "log_entry": "base64-encoded-log-entry",
            "submitted_entry": {
               "submission": "base64-encoded-sti-certificate",
               "chain": [
                  "base64-encoded-CA-cert-1",
                  "base64-encoded-CA-cert-2",
                  "base64-encoded-trust-anchor-cert"
               ]
            },
            "sct": "base64-encoded-sct"
         }
      ],
      "sth": "base64-encoded-signed_tree_head_v2"
   }

8.3.  Monitor

   Monitors in the STIR/SHAKEN Certificate Transparency (CT) framework
   play a crucial role in maintaining the integrity and trust of the
   ecosystem.  They ensure that no certificates are mis-issued,
   particularly concerning the TNAuthList field, which lists the
   telephone numbers an entity is authorized to use.

8.3.1.  Monitor Workflow

   1.  Initialize Monitor:

   *  Step 1: Set up the Monitor to periodically query the transparency
      logs for new entries.  The Monitor must be configured with the
      base URL of each log it intends to monitor.




Wendt, et al.            Expires 9 January 2025                 [Page 9]

RFC 2                            STI CT                        July 2024


   *  Step 2: Configure the Monitor with a list of telephone numbers
      (TNs) and associated entities to track.

   1.  Retrieve Latest STH:

   *  Step 3: The Monitor retrieves the latest Signed Tree Head (STH)
      from each log to determine the current state of the log.

   API Call:

   GET <Base URL>/ct/v2/get-sth

   Expected Response:
   {
      "sth": "base64-encoded-signed_tree_head_v2"
   }

   1.  Retrieve New Entries from Log:

   *  Step 4: Using the STH, the Monitor retrieves new entries from the
      log that have been added since the last known state.

   API Call:

GET <Base URL>/ct/v2/get-entries?start=last_known_index&end=current_sth_index

Expected Response:
{
   "entries": [
      {
         "log_entry": "base64-encoded-log-entry",
         "submitted_entry": {
            "submission": "base64-encoded-sti-certificate",
            "chain": [
               "base64-encoded-CA-cert-1",
               "base64-encoded-CA-cert-2",
               "base64-encoded-trust-anchor-cert"
            ]
         },
         "sct": "base64-encoded-sct"
      }
   ],
   "sth": "base64-encoded-signed_tree_head_v2"
}

   1.  Decode and Verify Certificates:





Wendt, et al.            Expires 9 January 2025                [Page 10]

RFC 2                            STI CT                        July 2024


   *  Step 5: Decode each retrieved certificate and verify its validity
      using the provided certificate chain.  Extract the entity name and
      TNAuthList from the certificate.

   1.  Check for Mis-issuance:

   *  Step 6: Compare the TNAuthList and entity name from the newly
      issued certificate with the Monitor's configured list.  Alarm if a
      certificate is issued in the name of a different entity for the
      same TNs.

  Example Pseudocode:

  for entry in entries:
     certificate = decode_base64(entry["submitted_entry"]["submission"])
     tn_auth_list = extract_tn_auth_list(certificate)
     entity_name = extract_entity_name(certificate)

     for tn in tn_auth_list:
        if tn in monitor_configured_tn_list:
           if monitor_configured_tn_list[tn] != entity_name:
                 raise Alarm(f"Mis-issued Certificate: {tn} assigned to
                 {entity_name}")

   1.  Alarm and Reporting:

   *  Step 7: If a mis-issuance is detected, raise an alarm and log the
      details for further investigation and notify relevant stakeholders
      to rectify any confirmed mis-issuance.

   1.  Maintain State and Continuity:

   *  Step 8: Update the Monitor's last known state with the current STH
      index to ensure continuity in monitoring.

8.4.  Auditing

   Auditing ensures that the current published state of a log is
   reachable from previously published states that are known to be good
   and that the promises made by the log, in the form of SCTs, have been
   kept.  Audits are performed by monitors or STI Verification Services.

9.  Security Considerations

   TODO Security

10.  IANA Considerations




Wendt, et al.            Expires 9 January 2025                [Page 11]

RFC 2                            STI CT                        July 2024


10.1.  JSON Web Token Claim

   This document requests that the IANA add three new claims to the JSON
   Web Token Claims registry as defined in [RFC7519].

   Claim Name: "sct"

   Claim Description: Signed Certificate Timestamp

   Change Controller: IESG

   Specification Document(s): [RFCThis]

11.  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/rfc/rfc2119>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7519>.

   [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/rfc/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/rfc/rfc8224>.

   [RFC8225]  Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
              Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
              <https://www.rfc-editor.org/rfc/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/rfc/rfc8226>.

   [RFC9060]  Peterson, J., "Secure Telephone Identity Revisited (STIR)
              Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
              September 2021, <https://www.rfc-editor.org/rfc/rfc9060>.





Wendt, et al.            Expires 9 January 2025                [Page 12]

RFC 2                            STI CT                        July 2024


   [RFC9118]  Housley, R., "Enhanced JSON Web Token (JWT) Claim
              Constraints for Secure Telephone Identity Revisited (STIR)
              Certificates", RFC 9118, DOI 10.17487/RFC9118, August
              2021, <https://www.rfc-editor.org/rfc/rfc9118>.

   [RFC9162]  Laurie, B., Messeri, E., and R. Stradling, "Certificate
              Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
              December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.

   [RFC9448]  Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
              "TNAuthList Profile of Automated Certificate Management
              Environment (ACME) Authority Token", RFC 9448,
              DOI 10.17487/RFC9448, September 2023,
              <https://www.rfc-editor.org/rfc/rfc9448>.

Acknowledgments

   The authors would like to thank the authors and contributors to the
   protocols and ideas around Certificate Transparency [RFC9162] which
   sets the basis for the STI eco-system to adopt in a very straight
   forward way, providing trust and transparency in the telephone number
   world.

Authors' Addresses

   Chris Wendt
   Somos, Inc.
   United States of America
   Email: chris@appliedbits.com


   Rob Sliwa
   Somos, Inc.
   United States of America
   Email: robjsliwa@gmail.com


   Alec Fenichel
   TransNexus
   United States of America
   Email: alec.fenichel@transnexus.com


   Vinit Anil Gaikwad
   Twilio
   United States of America
   Email: vanilgaikwad@twilio.com




Wendt, et al.            Expires 9 January 2025                [Page 13]