Re: [stir] OCSP and short-lived certs

[[e-mail]]

Hi Jack,

 

Your outline of options is very well written.  Thank you for taking the time
to write it.

 

If I understand correctly, I think I disagree with one point.

 

You said:

 

Facts about all approaches:

*	The certificate issuer has control over the TNs that the certificate
can sign over.

 

I may misunderstand, but I assume "control over the TNs" means the
certificate issuer is provably authoritative for the assignment of the TNs.
This can be true but does not have to be true and I assume in some cases it
will not be true.

 

With encouragement for correction where my suppositions are wrong or flawed,
I'll summarize use case aspects of delegate certs in the STIR/SHAKEN context
to illuminate what might be unrealistic expectations about validating TNs in
or referenced by delegate certs with or without OCSP or stapling in hopes
that the context is helpful as the group considers the options.

 

The values in a TNAuthList OID are an index into an array which specifies
the type of value in the OID (i.e., SPC, TN range, or a TN) and the
respective SPC, TN range, or TN value.  There is one index value and one
data type value per certificate.  Clause 4.1 of RFC 9060
<https://www.rfc-editor.org/rfc/rfc9060.html#name-scope-of-delegation>
"STIR Certificate Delegation" appears to permit additional TNAuthList
entries, but the SHAKEN standards do not.

 

According to the ATIS standards, TN ranges or a TN are put in a TNAuthList
(onboard in a cert or referenced elsewhere) only when the certificate is a
delegate certificate issued to a non-service provider by a service provider
who is registered with the Secure Telephone Identity (STI) Policy
Administrator (PA) and is acting in the role of a Subordinate CA (S-CA)
notably without obligation in the STI-GA Certificate Policy to acquire an
approved Certification Practice Statement (CPS) from the STI-PA.  Registered
service providers populate the TNAuthList OID with their Service Provider
Code (SPC).

 

There is no standard or governance policy framework for how provenance of
TNs is established for a service provider issuing delegate certificates.
There is nothing in the process or the cert that proves the service provider
acting in the role of Subordinate CA is authoritative for the assignment of
the TNs in or referenced by the cert.  Also, number spoofing is legal (if
not abused) and it is reasonable to assume delegate certs could be issued to
support signing of legally spoofed numbers (by non-service providers).

 

The delegate certificate subject (noun) is not subject (verb) to any
accredited form of vetting of real-world identity or reputation.  And there
are no STI Certificate Transparency Logs to help prevent either accidental
namespace overlaps, or intentional impersonation.

 

The subject (or holder) of a delegate certificate is explicitly not
authorized to use the certificate for SHAKEN call signatures per clause 6 of
ATIS-1000092
<https://access.atis.org/apps/group_public/document.php?document_id=56801> .
The primary use of delegate certificates is assumed to be for RCD (and
perhaps "div") PASSporT call signatures.  Delegate certificates for "RPH"
PASSporT call authentication might also be used by certain government
agencies, or for PSAP call-back.

 

The largest group of delegate certificate holders is anticipated to be
enterprises, and the early adopters are anticipated to be outbound call
centers who are originating calls on behalf of enterprises and whose call
originations are most prone to accidental mislabeling or call blocking by
terminating service provider anti-robocalling analytics engines.  It is
assumed that by volunteering to self-identify with RCD call authentication,
their calls can be more securely identified as compared to spoofed-versions
of calls using the same calling numbers and therefore perhaps enjoy some
decline in accidental mislabeling or call blocking.  And there is a
commercial "branded calling" aspect wherein callers using RCD might also
have name, company logo, and reason-for-calling data in (or referenced by)
the RCD PASSporT displayed to the called party.

 

It is important to note outbound call centers are using calling TNs which:

 

*	May be obtained from the call center voice service provider(s)
*	May be obtained from TN providers (e.g., Toll Free numbers)
*	May be obtained from call center enterprise (or government agency)
customers  (i.e., BYOTN)
*	May be a mix of any or all of the above
*	May be managed in a pool and used in rotation of indeterminate
periodicity for multiple enterprises (but probably not for more than one
enterprise at a time)

 

Larger enterprises often have organizations with differing outbound calling
needs (e.g., sales versus customer service) which may not coordinate
acquisition or management of TNs and independently secure various outbound
calling services.

 

It is important to note the number management and usage to better appreciate
the challenges facing an AS service managing keys and the certs acquired
from the appropriate STI-registered authoritative "owner" of TNs who are the
only entities permitted to issue delegate certificates.  Also, important to
note is some (most?) authoritative owners of TNs may have disinterest in
operating an STI S-CA service.

 

To summarize:

 

*	There are no regulatory or governance (or even "best practice)
requirements for issuance of delegate certs with provable authoritative
ownership of TNs
*	There are no requirements for STI-registered service providers
operating as an STI Subordinate Certification Authority (S-CA) to create and
submit an audited CPS for approval by the STI-PA PMA or the STI-GA Technical
Committee
*	Some authoritative and registered service providers may not want to
engage in S-CA service

 

Therefore, entrepreneurial service providers may legitimately elect to
operate an S-CA providing delegate certificates as a service.  i.e., there
is no prohibition preventing any registered service provider from minting
delegate certificates with whatever TNs or TN ranges (by value or reference)
as may be needed or desired by a customer wanting delegate certificates.

 

It is questionable what "validation" really means when validating telephone
numbers by value or by reference with or without OCSP with or without
stapling in the context of the real-world assignment and management of TNs
and issuance and use of delegate certificates.

 

I will also note some service provider engineers have observed that the
current state of standards and policy associated with issuance and use of
delegate certificates are insufficient to their VS requirements policies.
i.e., they won't trust/verify PASSporTs verified with delegate certs without
further qualification.

 

"Further qualification" can mean many things but one thing in particular it
could mean and which is directly relevant to the outbound call center
context is whether the Subject and/or other identity information as may be
encoded into a certificate extension should reflect the fact that the
outbound call center is the caller, but it is their enterprise or government
agency customer that they are representing as an agent contracted to provide
calling services on their behalf.  In a way both identities of the calling
center and their enterprise/agency are calling.

 

A useful development would be to decide how those two calling identities
should be encoded in the certificate and/or PASSporT and represented to the
called party (or parties).  One way that might be accomplished was outlined
in an informational contribution to the ATIS-1000092 v2 baseline which
described the use of ISO 17442-2 Legal Entity Identifier (LEI) Object IDs in
RFC 5280 certificates.

 

Lastly, I want to add a "+1" to Alec Fenichel's preference for the option of
using "x5c" with stapled (single TN?) short-lived certificates.

 

Thank you again for your excellent work.

 

Best regards,

 

 


 <https://www.linkedin.com/in/pierce-gorman-4330201/> 

Pierce Gorman 

Technical Staff Distinguished Member 

 <mailto:[e-mail]> [e-mail]

 


 <https://www.numeracle.com/> 

Stay Informed

 <https://www.numeracle.com/tuesday-talks> Tuesday Talks Podcast  |
<https://www.numeracle.com/insights-blog/all-articles> Insights

 

 

From: stir <[e-mail]> On Behalf Of Jack Rickard
Sent: Wednesday, January 4, 2023 4:42 AM
To: Peterson, Jon <[e-mail]>; IETF STIR Mail List
<[e-mail]>
Cc: Simon Castle <[e-mail]>
Subject: [stir] OCSP and short-lived certs

 

Hi all,

 

I wanted to summarize the pros and cons of the different options around
providing dynamic TN authorization for certificates, hopefully to clarify
exactly what the differences are and guide us towards a destination.

 

Issues these are attempting to solve:

1.	Existing certificate infrastructure doesn't cope well with rapidly
changing TN assignments (such as number portability).
2.	Some users want privacy about which numbers they own, currently they
must provide a complete list to whoever sees their certificate.
3.	The latency added by an arbitrary URI access on the call path is not
acceptable to some use-cases.

 

Facts about all approaches:

*	The certificate issuer has control over the TNs that the certificate
can sign over.
*	The certificate issuer must host a server allowing someone to
dynamically query whether an entity has permission to use a telephone
number.
*	Someone is going to have to do a dynamic lookup at some point,
making issue 3 mostly a question of cache-ability.

 

Existing by-ref using the AIA extension:

Sticking with the existing mechanism in RFC 8226 is an available option.
This is where the Authority Information Access extension is used to host the
TnAuthList on a remote server (controlled by the CA). In this solution the
AS does not need to care about the TNs it owns at all, and the VS makes
requests to the server hosted by the CA.

Pros:

*	It already exists.
*	HTTP caching headers could be used to indicate to the VS how long it
is able to cache the information for.

Cons:

*	This leaks the entire list of telephone numbers that a certificate
has authority over.
*	Any changes to TN ownership require a completely new document
meaning cache times must be reasonably short.
*	It is not required that the HTTP request contains caching
information, making caching the response difficult.
*	This partially reveals to the CA who you are calling.

 

OCSP without stapling:

draft-ietf-stir-certificates-ocsp-03 - OCSP Usage for Secure Telephone
Identity Certificates
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fdraft-ietf-stir-certificates-ocsp%2F&data=05%7C01%7Cjack
.rickard%40microsoft.com%7C28f7c73e9a4a4af57d9208dadf89668c%7C72f988bf86f141
af91ab2d7cd011db47%7C1%7C0%7C638068078488875792%7CUnknown%7CTWFpbGZsb3d8eyJW
IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
7C&sdata=A04UQdGyeXcYAb8FeoBQajcAjUeaa7twt1QknGgL5V0%3D&reserved=0> . This
extends the OCSP protocol to allow a VS to query whether a certificate has
authority over a specific originator. Note that existing implementations
would likely treat OCSP enabled certs as invalid (due to not having the
TNAuthList extension).

Pros:

*	This can easily cope with rapidly changing numbers as each request
only authorises one number for an arbitrarily short period of time.
*	We could require the nextUpdate field to be present (I think)
allowing the VS to know how long it may cache the information for.

Cons:

*	This doesn't completely solve the privacy issue; an attacker could
use the OCSP server to enumerate all TNs that a certificate owns.
*	A verifier is unlikely to be able to cache OCSP statuses, as a cache
is only useful if it sees multiple calls from the same originator.
*	This adds complexity to the ecosystem as CA's must host OCSP servers
and VSs must be enhanced to understand OCSP.

 

OCSP with stapling:

draft-peterson-stir-ocsp-staple-00 - OCSP Stapling for Secure Telephone
Identity (ietf.org)
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fdraft-peterson-stir-ocsp-staple%2F&data=05%7C01%7Cjack.r
ickard%40microsoft.com%7C28f7c73e9a4a4af57d9208dadf89668c%7C72f988bf86f141af
91ab2d7cd011db47%7C1%7C0%7C638068078488875792%7CUnknown%7CTWFpbGZsb3d8eyJWIj
oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
&sdata=Guy%2B50ZYiOpDikMB2Bo%2FYdyWvX50W1Dy3%2FWLbmozJgc%3D&reserved=0> .
This is the same as OCSP without stapling but the AS places the OCSP
response inside the PASSporT, so the VS does not have to retrieve it. Note
that existing implementations would likely treat OCSP enabled certs as
invalid (due to not having the TNAuthList extension).

Pros:

*	Rapidly changing numbers can be easily dealt with, as in OCSP
without stapling.
*	The AS is in a much better position to always have all OCSP staples
as it can be push notified of changes, and only needs to cache certificates
for numbers for which it signs outgoing calls.
*	This could completely protect the privacy of the certificate owner
as the OCSP server does not have to be accessible on the internet.

Cons:

*	This will make PASSporTs substantially larger as they must contain
the OCSP staple.
*	This adds complexity to the ecosystem as CAs must host OCSP servers
and authentication & verification services must be enhanced to understand
OCSP.

 

Short-lived certs without stapling:

The CA issues short-lived certs with restricted scopes, potentially only a
few hours and a single TN. This is already supported by the existing
standards; we may however want to specify some mechanism for obtaining these
short-lived certs programmatically. This conceptually is very similar to the
OCSP without stapling option above. 

Pros:

*	No new standards are required, and already works.
*	This allows the most flexibility around what certificates you want
to exist and how long those permissions last.
*	If you only ever issue certificates containing a single TN then this
allows complete privacy, assuming the certificate URLs are not guessable.

Cons:

*	This will add a lot of latency as a verifier is unlikely to be able
to cache these certs, as they will expire quickly and may not be reused to
the same destination.
*	Obtaining short lived certs is difficult as the AS and CA will need
an API, we may be able to help by specifying something here. (A suggestion
is ACME STAR although implementations generally use custom APIs here
currently)

 

Short-lived certs with stapling:

This is identical to short-lived certs without stapling but the AS puts part
of the certificate chain into the PASSporT; only the leaf needs to be
stapled as the rest of the chain is more easily cached. This conceptually is
very similar to OCSP with stapling.

Pros:

*	This is likely backwards compatible with existing implementations;
they would just have to retrieve the certificate rather than using the
stapled one.
*	This allows the most flexibility around what certificates you want
to exist and how long those permissions last.
*	If you only ever issue certificates containing a single TN then this
allows complete privacy, assuming the certificate URLs are not guessable.
*	The AS is in a much better position to always have all required
certs as it can be push notified of changes, and only needs to cache
certificates for numbers for which it signs outgoing calls.

Cons:

*	This will make PASSporTs a lot larger (larger even than OCSP
stapling) as they will contain at least one certificate.
*	This adds complexity to the ecosystem as authenticators & CAs must
communicate (again possibly ACME STAR) and verification services must be
enhanced to understand stapled certs.

 

 

Thanks for reading if you got this far! I'd appreciate your opinion as these
all look similar; I believe we need one of the stapling options, but there
is little difference between the two options.

 

Jack