Internet DRAFT - draft-wendt-stir-certificate-transparency
draft-wendt-stir-certificate-transparency
Secure Telephone Identity Revisited C. Wendt
Internet-Draft R. Sliwa
Intended status: Informational Somos, Inc.
Expires: 5 September 2024 4 March 2024
STI Certificate Transparency
draft-wendt-stir-certificate-transparency-00
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, in a manner that allows anyone to audit STI certification
authority (CA) activity and notice the issuance of suspect
certificates as well as to audit the certificate logs themselves.
The intent is establish a level of trust in the STI eco-system that
verification of calls would required and refuse to honor STI
certificates that do not appear in a log, effectively forcing STI CAs
to add all issued certificates to the logs, establishing trust that
STI certificates are unique to the authorized provider or assignee of
a telephone number resource. The primary role of certificate
transparency in the STI ecosystem is the avoidance of issuance of
unauthorized or duplicate provider level certificates or, of
particular importance, telephone number level delegate certificates.
This provides a robust mechanism for the detection of unauthorized
creation of certificate credentials for illegitimate spoofing of
telephone numbers.
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/.
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/.
Wendt & Sliwa Expires 5 September 2024 [Page 1]
RFC 0 STI CT March 2024
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 5 September 2024.
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 . . 4
4. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 5
5. Log Format and Operation . . . . . . . . . . . . . . . . . . 5
6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 6
7. STI Certification Authorities . . . . . . . . . . . . . . . . 6
8. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. STI Verification Service . . . . . . . . . . . . . . . . 6
8.1.1. Receiving SCTs and Inclusion Proofs . . . . . . . . . 6
Wendt & Sliwa Expires 5 September 2024 [Page 2]
RFC 0 STI CT March 2024
8.1.2. Reconstructing the TBSCertificate . . . . . . . . . . 6
8.1.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 6
8.1.4. Fetching Inclusion Proofs . . . . . . . . . . . . . . 7
8.1.5. Validating Inclusion Proofs . . . . . . . . . . . . . 7
8.1.6. Evaluating Compliance . . . . . . . . . . . . . . . . 7
8.2. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.3. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Normative References . . . . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Certificate Transparency (CT) aims to mitigate the problem of
misissued certificates by providing append-only logs of issued
certificates. The logs do not themselves prevent misissuance, but
they ensure that interested parties (particularly those named in
certificates or certificate chains) can detect such misissuance.
This general mechanism that could also be used for transparently
logging metadata associations via JWTClaimConstraints defined in
[RFC8226] and [RFC9118] or potentially other ways defined in future
extensions of this document.
[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 the direct use of the same fundamental protocols
and processes of certificate transparency but applies them to 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 globally unique 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
Wendt & Sliwa Expires 5 September 2024 [Page 3]
RFC 0 STI CT March 2024
public representation of the creation of certificates in order for
the eco-system of interested parties to provide a publicly verifiable
log of certificates created by Certification Authorities to protect
against misissuance of certificates that may be misrepresenting
information.
There is three primary actors in the certificate transparency
framework. There is the STI certification authorities that submit
all created certificates to logs, this could be to one or more log
services. The log services are network services that implement the
protocol operations for submissions of STI certificates and queries.
They are hosted by interested parties in the STI ecosystem and can
accept certificate log submissions from any other CA participant.
Monitors play the role of monitoring the CT logs to check for
potential misissuance. This role can be played by any STI ecosystem
participant that is interested in the trust of the ecosystem.
The details that follow in this document will try to provide a high
level overview of the use of Certificate Transparency for STI
certificates. It will provide high level details with assumptions
that the details of the use of Merkel Tree and API interfaces largely
follow [RFC9162] protocols and only when there is specific details
and differences to [RFC9162] will that be defined normatively.
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.
3. The Use of Certificate Transparency for STI Certificates
Each log contains certificate chains, which can be submitted by
anyone. It is expected that STI CAs will contribute all their newly
issued certificates to one or more logs; however, it is possible for
certificate holders can also directly contribute their own
certificate chains, as can interested third parties. In order to
avoid logs being rendered useless by the submission of large numbers
of spurious certificates, it is required that each chain ends with a
trust anchor that is accepted by the log. A log may also limit the
length of the chain it is willing to accept; such chains must also
end with an acceptable trust anchor. When a chain is accepted by a
log, a signed timestamp is returned, which can later be 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
Wendt & Sliwa Expires 5 September 2024 [Page 4]
RFC 0 STI CT March 2024
timestamps once certificate transparency is well established in the
ecosystem to maintain trust.
Those who are concerned about misissuance of provider or TN-based
delegate certificates can monitor the logs, asking them regularly for
all new entries, and can thus check whether domains 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 misissuance 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 misissued
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]). The submitter SHOULD
validate the returned SCT, as described in Section 8.1 of [RFC9162],
if they understand its format and they intend to use it to construct
an STI certificate.
4.1. Certificates
Any entity can submit a certificate (Section 5.1 of [RFC9162]) to a
log. Since it is anticipated that STIR 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 Merkle Tree of submitted certificate
entries. Log procedures MUST follow log format and operation
procedures defined in Section 4 of [RFC9162].
Author note: Do we need a separate IANA registry for Log OIDs
specific to STI eco-system?
Wendt & Sliwa Expires 5 September 2024 [Page 5]
RFC 0 STI CT March 2024
6. Log Client Messages
Log Client Messages and API MUST follow same protocols, formats and
procedures as described in Section 5 of [RFC9162]
Author Note: I don't believe this is any parallel to TLS servers
directly participating in CT in the STI world
7. STI Certification Authorities
The Transparency Information X.509v3 extension including rules of
inclusion in OCSP responses MUST follow descriptions and procedures
defined in Section 7 of [RFC9162].
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.
8.1. STI Verification Service
8.1.1. Receiving SCTs and Inclusion Proofs
STI Verification Services receive SCTs and inclusion proofs in
certificates.
8.1.2. Reconstructing the TBSCertificate
Validation of an SCT for a certificate (where the type of the
TransItem is x509_sct_v2) uses the unmodified TBSCertificate
component of the certificate.
8.1.3. Validating SCTs
In order to make use of a received SCT, the STI Verification Service
MUST first validate it as follows:
Compute the signature input by constructing a TransItem of type
x509_entry_v2, depending on the SCT's TransItem type. The
TimestampedCertificateEntryDataV2 structure is constructed in the
following manner: timestamp is copied from the SCT. tbs_certificate
is the reconstructed TBSCertificate portion of the server
certificate, as described in Section 8.1.2 of [RFC9162].
issuer_key_hash is computed as described in Section 4.7 of [RFC9162].
sct_extensions is copied from the SCT. Verify the SCT's signature
Wendt & Sliwa Expires 5 September 2024 [Page 6]
RFC 0 STI CT March 2024
against the computed signature input using the public key of the
corresponding log, which is identified by the log_id. The required
signature algorithm is one of the log's parameters. If the STI
Verification Service does not have the corresponding log's
parameters, it cannot attempt to validate the SCT. When evaluating
compliance (see Section 8.1.6 of [RFC9162]), the STI Verification
Service will consider only those SCTs that it was able to validate.
Note that SCT validation is not a substitute for the normal
validation of the server certificate and its chain.
8.1.4. Fetching Inclusion Proofs
When a STI Verification Service has validated a received SCT but does
not yet possess a corresponding inclusion proof, the STI Verification
Service MAY request the inclusion proof directly from a log using
get-proof-by-hash (Section 5.4 of [RFC9162]) or get-all-by-hash
(Section 5.5 of [RFC9162]).
8.1.5. Validating Inclusion Proofs
When a STI Verification Service has received, or fetched, an
inclusion proof (and an STH), it SHOULD proceed to verify the
inclusion proof to the provided STH. The STI Verification Service
SHOULD also verify consistency between the provided STH and an STH it
knows about.
If the STI Verification Service holds an STH that predates the SCT,
it MAY, in the process of auditing, request a new STH from the log
(Section 5.2 of [RFC9162]) and then verify it by requesting a
consistency proof (Section 5.3 of [RFC9162]). Note that if the STI
Verification Service uses get-all-by-hash, then it will already have
the new STH.
8.1.6. Evaluating Compliance
It is up to a client's local policy to specify the quantity and form
of evidence (SCTs, inclusion proofs, or a combination) needed to
achieve compliance and how to handle noncompliance.
8.2. Monitor
Monitors watch logs to check for correct behavior, for certificates
of interest, or for both. For example, a monitor may be configured
to report on all certificates that apply to a specific domain name
when fetching new entries for consistency validation.
Wendt & Sliwa Expires 5 September 2024 [Page 7]
RFC 0 STI CT March 2024
A monitor MUST at least inspect every new entry in every log it
watches, and it MAY also choose to keep copies of entire logs.
8.3. 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
This document has no IANA actions, yet.
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>.
[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 & Sliwa Expires 5 September 2024 [Page 8]
RFC 0 STI CT March 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
Wendt & Sliwa Expires 5 September 2024 [Page 9]
