[stir] OCSP and short-lived certs

[Jack Rickard <[e-mail]>]

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%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-stir-certificates-ocsp%2F&data=05%7C01%7Cjack.rickard%40microsoft.com%7C28f7c73e9a4a4af57d9208dadf89668c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068078488875792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%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%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-peterson-stir-ocsp-staple%2F&data=05%7C01%7Cjack.rickard%40microsoft.com%7C28f7c73e9a4a4af57d9208dadf89668c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638068078488875792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%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