Re: [stir] OCSP and short-lived certs

[[e-mail]]

That sounds good as long as EE cert issuance policies and AS systems are
sensibly configured and as long as incidence of multi-PASSporT INVITEs are
almost always SHAKEN+RCD or SHAKEN+DIV.  And that may be the case.

 

 

From: Alec Fenichel <[e-mail]> 
Sent: Friday, January 13, 2023 1:42 PM
To: [e-mail]; 'Jack Rickard' <[e-mail]>;
'Peterson, Jon' <[e-mail]>; 'IETF STIR Mail List'
<[e-mail]>
Cc: 'Simon Castle' <[e-mail]>
Subject: Re: [stir] OCSP and short-lived certs

 

The x5c claim is optional and primarily useful for short lived certificates.
If using long lived certificates with deep chains for CRL management, I
would not expect x5c to be used.

 

I think x5c could be useful for service provider certificates used for
SHAKEN PASSporTs. Service providers can use short lived certificates as
well.

 

Sincerely,

 

Alec Fenichel

Chief Technology Officer

 <https://transnexus.com/> TransNexus

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

 <tel:[phone]> [phone]

 

From: [e-mail] <mailto:[e-mail]>
<[e-mail] <mailto:[e-mail]> >
Date: Friday, January 13, 2023 at 14:31
To: Alec Fenichel <[e-mail]
<mailto:[e-mail]> >, 'Jack Rickard'
<[e-mail] <mailto:[e-mail]> >,
'Peterson, Jon' <[e-mail]
<mailto:[e-mail]> >, 'IETF STIR Mail List' <[e-mail]
<mailto:[e-mail]> >
Cc: 'Simon Castle' <[e-mail]
<mailto:[e-mail]> >
Subject: RE: [stir] OCSP and short-lived certs

4 certs is the shortest possible delegate cert chain although only the CA
intermediate, Subordinate CA (SCA), and VoIP Entity End Entity (VE EE) certs
are downloaded from a CR by a VS.

 

CA Root => CA Intermediate => SCA Intermediate => VE EE

 

Assuming short-lived certs are not mandatory, I expect 5 or 6 certs in a
delegate cert chain (with 4 or 5 to be downloaded) could be common.

 

For example, assume a service provider in the role of SCA wants to manage
VoIP Entity certs in a VE sub-chain for the purpose of being able to revoke
all certs for a VE with a single CRL entry.

 

CA Root => CA Intermediate => SCA Intermediate 1 => SCA Intermediate 2 => VE
EE 

 

Building on this example, a large enterprise or government agency VoIP
Entity might also request an Intermediate cert in order to manage its own
subset of EE certs.

 

CA Root => CA Intermediate => SCA Intermediate 1 => SCA Intermediate 2 => VE
Intermediate 1 => VE EE 

 

If we constrain the stapling to delegate certs only, it might be OK.

 

If we expect stapling to be used with SP EE certs for SHAKEN, and/or "div"
and/or "RPH", and/or VE EE with "RCD", stapling could perhaps become a
problem.

 

Pierce

 

 

 

From: stir <[e-mail] <mailto:[e-mail]> > On Behalf
Of Alec Fenichel
Sent: Friday, January 13, 2023 12:56 PM
To: Jack Rickard <[e-mail]
<mailto:[e-mail]> >; Peterson, Jon
<jon.peterson=[e-mail]
<mailto:jon.peterson=[e-mail]> >; IETF STIR Mail List
<[e-mail] <mailto:[e-mail]> >
Cc: Simon Castle <[e-mail]
<mailto:[e-mail]> >
Subject: Re: [stir] OCSP and short-lived certs

 

Hey Jack,

 

In my experience, the size of SIP INVITEs has not been a significant
problem.

 

I also worry about cache poisoning with this cache method.

 

I think the advantages (simplicity and compatibility with existing
libraries) of using the full chain (without the root) out way the
disadvantages (larger PASSporT size).

 

Sincerely,

 

Alec Fenichel

Chief Technology Officer

 
<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransnexu
s.com%2F&data=05%7C01%7Calec.fenichel%40transnexus.com%7C2faa300563ab4c293bf
f08daf59ccbdf%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C63809235107036862
5%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qPgbTXzc8xXGrAC0yl72zR%2BVgDtXy9aa4ES
ZEOHfYhw%3D&reserved=0> TransNexus

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

 <tel:[phone]> [phone]

 

From: Jack Rickard <[e-mail]
<mailto:[e-mail]> >
Date: Friday, January 13, 2023 at 10:21
To: Alec Fenichel <[e-mail]
<mailto:[e-mail]> >, Peterson, Jon
<jon.peterson=[e-mail]
<mailto:jon.peterson=[e-mail]> >, IETF STIR Mail List
<[e-mail] <mailto:[e-mail]> >
Cc: Simon Castle <[e-mail]
<mailto:[e-mail]> >
Subject: RE: OCSP and short-lived certs

I don't think Example 1 is a problem as you cache by Subject and Key ID not
Issuer and Key ID, and those certs have different subjects.

Example 2 is a pain, I think the answer is that you need to cache multiple
certs per key and then just try all of them, this theoretically could get
very complex (although in practice is likely to remain simple) as you
essentially end up needing to do a graph search. TnAuthList hierarchy could
make it even more of a pain.

 

This does all feel nasty, and after an internal discussion I might be
worrying too much about the size of the invite, but I don't know for sure. I
would be happy to just use x5c as it currently exists, if someone can
confidently say this 2-3x increase in the size of an identity isn't going to
be a problem.

 

Jack

 

From: Alec Fenichel <[e-mail]
<mailto:[e-mail]> > 
Sent: Tuesday, January 10, 2023 7:11 PM
To: Jack Rickard <[e-mail]
<mailto:[e-mail]> >; Peterson, Jon
<jon.peterson=[e-mail]
<mailto:jon.peterson=[e-mail]> >; IETF STIR Mail List
<[e-mail] <mailto:[e-mail]> >
Cc: Simon Castle <[e-mail]
<mailto:[e-mail]> >
Subject: [EXTERNAL] Re: OCSP and short-lived certs

 

I think there are some issues with that cache key logic.

 

 

Example 1:

 

Let's say there is a root certificate, R1:

                Subject: Root 1

                Issuer: Root 1

                Subject Key ID: root1

                Authority Key ID: root1

 

Let's say there are two 2 intermediate certificates, I1 and I2, that use the
same key pair but different Subject DNs:

                I1:

                                Subject: Intermediate 1

                                Issuer: Root 1

                                Subject Key ID: intermediate1

                                Authority Key ID: root1

                I2:

                                Subject: Intermediate 2

                                Issuer: Root 1

                                Subject Key ID: intermediate1

                                Authority Key ID: root1

 

Let's say there are two 2 end-entity certificates, E1 and E2:

                E1:

                                Subject: End-entity 1

                                Issuer: Intermediate 1

                                Subject Key ID: end1

                                Authority Key ID: intermediate1

 

                E2:

                                Subject: End-entity 2

                                Issuer: Intermediate 2

                                Subject Key ID: end2

                                Authority Key ID: intermediate1

 

When you receive E1 for the first time, how would you I1 in such a way that
it does not conflict with I2 when you receive E2? I1 and I2 have the same
Issuer and Subject Key ID.

 

 

 

 

Example 2:

 

Let's say there is a root certificate, R1:

                Subject: Root 1

                Issuer: Root 1

                Subject Key ID: root1

                Authority Key ID: root1

 

Let's say there are two 2 intermediate certificates, I1 and I2, that use the
same key pair, the same Subject DN, but have different CP versions:

                I1:

                                Subject: Intermediate 1

                                Issuer: Root 1

                                Subject Key ID: intermediate1

                                Authority Key ID: root1

                                CP: 1

                I2:

                                Subject: Intermediate 1

                                Issuer: Root 1

                                Subject Key ID: intermediate1

                                Authority Key ID: root1

                                CP: 2

 

Let's say there are two 2 end-entity certificates, E1 and E2:

                E1:

                                Subject: End-entity 1

                                Issuer: Intermediate 1

                                Subject Key ID: end1

                                Authority Key ID: intermediate1

                                CP: 1

 

                E2:

                                Subject: End-entity 2

                                Issuer: Intermediate 1

                                Subject Key ID: end2

                                Authority Key ID: intermediate1

                                CP: 2

 

I1 does not form a valid chain for E2 because the CPs are different. How
would you cache I1 and I2 in such a way that they don't conflict, but you
are also able to determine the cache key with just E1 or E2?

 

 

Sincerely,

 

Alec Fenichel

Chief Technology Officer

 
<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransnexu
s.com%2F&data=05%7C01%7Calec.fenichel%40transnexus.com%7C2faa300563ab4c293bf
f08daf59ccbdf%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C63809235107036862
5%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qPgbTXzc8xXGrAC0yl72zR%2BVgDtXy9aa4ES
ZEOHfYhw%3D&reserved=0> TransNexus

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

 <tel:[phone]> [phone]

 

From: Jack Rickard < <mailto:[e-mail]>
[e-mail]>
Date: Tuesday, January 10, 2023 at 13:35
To: Alec Fenichel < <mailto:[e-mail]>
[e-mail]>, Peterson, Jon <
<mailto:jon.peterson=[e-mail]>
jon.peterson=[e-mail]>, IETF STIR Mail List <
<mailto:[e-mail]> [e-mail]>
Cc: Simon Castle < <mailto:[e-mail]>
[e-mail]>
Subject: RE: OCSP and short-lived certs

I agree it makes things more complicated, and you need and application-level
(or plausibly domain-level) cache. However, OpenSSL can already do this (see
<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.opens
sl.org%2Fdocs%2Fman3.1%2Fman3%2FX509_STORE_CTX_set0_untrusted.html&data=05%7
C01%7Calec.fenichel%40transnexus.com%7C2faa300563ab4c293bff08daf59ccbdf%7C8e
2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C638092351070368625%7CUnknown%7CTWFp
bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
C3000%7C%7C%7C&sdata=5X5EDdQ5%2B25beAY2egQR589U%2Bay%2BbdNL6zXbfikqNv8%3D&re
served=0> /docs/man3.1/man3/X509_STORE_CTX_set0_untrusted.html
(openssl.org)), you cache based on the issuer name and subject key
identifier, as you can't change either of those without having to re-issue
the child cert.

 

I agree this is not ideal. It's possible that including the entire chain is
fine, but my gut reaction is that it will be unacceptably large.

 

Jack

 

From: Alec Fenichel < <mailto:[e-mail]>
[e-mail]> 
Sent: Tuesday, January 10, 2023 5:43 PM
To: Jack Rickard < <mailto:[e-mail]>
[e-mail]>; Peterson, Jon <
<mailto:jon.peterson=[e-mail]>
jon.peterson=[e-mail]>; IETF STIR Mail List <
<mailto:[e-mail]> [e-mail]>
Cc: Simon Castle < <mailto:[e-mail]>
[e-mail]>
Subject: [EXTERNAL] Re: OCSP and short-lived certs

 

Jack,

 

My concern with partial chains is that it dramatically increases the
complexity.

 

How do you cache (it is no longer an HTTP cache but an application-level
cache)? Specifically, what is the cache key and value? You need to be able
to deterministically construct the cache key for both the end-entity and
intermediate certificate. Certificates can be re-issued with the same or
different CN as well as the same or different key pair.

 

This likely would prevent the use of existing libraries for JWT validation
and caching.

 

Sincerely,

 

Alec Fenichel

Chief Technology Officer

 
<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransnexu
s.com%2F&data=05%7C01%7Calec.fenichel%40transnexus.com%7C2faa300563ab4c293bf
f08daf59ccbdf%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C63809235107036862
5%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qPgbTXzc8xXGrAC0yl72zR%2BVgDtXy9aa4ES
ZEOHfYhw%3D&reserved=0> TransNexus

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

 <tel:[phone]> [phone]

 

From: Jack Rickard < <mailto:[e-mail]>
[e-mail]>
Date: Tuesday, January 10, 2023 at 12:09
To: Alec Fenichel < <mailto:[e-mail]>
[e-mail]>, Peterson, Jon <
<mailto:jon.peterson=[e-mail]>
jon.peterson=[e-mail]>, IETF STIR Mail List <
<mailto:[e-mail]> [e-mail]>
Cc: Simon Castle < <mailto:[e-mail]>
[e-mail]>
Subject: RE: OCSP and short-lived certs

This is roughly what I was picturing, although I do suspect including the
whole chain would be too big, and we'd need the "x5u" and "x5c" option
(where x5c contains a partial chain).

 

From: Alec Fenichel < <mailto:[e-mail]>
[e-mail]> 
Sent: Friday, January 6, 2023 4:26 PM
To: Peterson, Jon < <mailto:jon.peterson=[e-mail]>
jon.peterson=[e-mail]>; Jack Rickard <
<mailto:[e-mail]> [e-mail]>; IETF STIR
Mail List < <mailto:[e-mail]> [e-mail]>
Cc: Simon Castle < <mailto:[e-mail]>
[e-mail]>
Subject: [EXTERNAL] Re: OCSP and short-lived certs

 

I think "Short-lived certs with stapling" is extremely easy to add support
for and we should allow it. Either in addition to or instead of the "x5u"
claim with the URL of the certificate chain, we should allow the "x5c" claim
with the chain of certificates. In order to keep in compliance with existing
JWS behavior, I think we should just include the full chain (excluding the
root just like we do for "x5u"). If we want to only include the leaf, then
we would need to require the "x5u" to have the full chain and the "x5c" to
have just the leaf.

 

 

 

Example with "x5u":

 

{

  "alg": "ES256",

  "ppt": "shaken",

  "typ": "passport",

  "x5u": "
<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcertifica
tes.clearip.com%2F908bf82d-0ce7-4c00-a9e8-84a0c1b5cd01%2Fcc54a11039de67bacd9
b6019443cecdb.pem&data=05%7C01%7Calec.fenichel%40transnexus.com%7C2faa300563
ab4c293bff08daf59ccbdf%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C63809235
1070368625%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=d%2FIQ%2B7KLOmVEZ%2FjHhiggk5
%2FXVAoOoJn%2Fz%2FN45AvfgT8%3D&reserved=0>
https://certificates.clearip.com/908bf82d-0ce7-4c00-a9e8-84a0c1b5cd01/cc54a1
1039de67bacd9b6019443cecdb.pem"

}

{

  "attest": "C",

  "dest": {

    "tn": [

      "18609653208"

    ]

  },

  "iat": 1668548175,

  "orig": {

    "tn": "14077600036"

  },

  "origid": "2de926c8-2be8-44c6-8e9c-0258a407b018"

}

 

 

 

Example with "x5c":

 

{

  "alg": "ES256",

  "ppt": "shaken",

  "typ": "passport",

  "x5c": [

 
"MIIC+DCCAp6gAwIBAgIQejOopoqGo5lSxqy0y95LDDAKBggqhkjOPQQDAjBnMQswCQYDVQQGEwJ
VUzEZMBcGA1UEChMQVHJhbnNOZXh1cywgSW5jLjEPMA0GA1UECxMGU0hBS0VOMSwwKgYDVQQDEyN
UcmFuc05leHVzLCBJbmMuIFNIQUtFTiBJc3N1aW5nIENBMzAeFw0yMjExMTMyMDMxMjlaFw0yMjE
xMjAyMDMxMjhaMFUxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZUcmFuc05leHVzIERldmVsb3BtZW5
0MQ8wDQYDVQQLEwZTSEFLRU4xFDASBgNVBAMTC1NIQUtFTiA1MThKMFkwEwYHKoZIzj0CAQYIKoZ
Izj0DAQcDQgAEax9FyDGmdfjAES9quPIDg5nPordCq3QiAj1MkWX3ptRQSxD8U3AziaUeqJC/vuF
v47JVsO0rxHvwzza/zqkx16OCATwwggE4MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMB0
GA1UdDgQWBBQIqucXuD9WMdR1sUEPu7rLsFw1+DAfBgNVHSMEGDAWgBS7lt4xEs3TlpmEpDYwYDz
XUoF9JzAXBgNVHSAEEDAOMAwGCmCGSAGG/wkBAQMwgaYGA1UdHwSBnjCBmzCBmKA6oDiGNmh0dHB
zOi8vYXV0aGVudGljYXRlLWFwaS5pY29uZWN0aXYuY29tL2Rvd25sb2FkL3YxL2NybKJapFgwVjE
UMBIGA1UEBwwLQnJpZGdld2F0ZXIxCzAJBgNVBAgMAk5KMRMwEQYDVQQDDApTVEktUEEgQ1JMMQs
wCQYDVQQGEwJVUzEPMA0GA1UECgwGU1RJLVBBMBYGCCsGAQUFBwEaBAowCKAGFgQ1MThKMAoGCCq
GSM49BAMCA0gAMEUCIQDszGSsxrW+dDq5SwuZe/xoW8yO6gMVW503owuYuchH5wIgV2+59q2m9mV
51t8hIxidKLMgnlLqJ5rre/KLSegGVOI=",

 
"MIIC8TCCApigAwIBAgIQaeMkSbXPfDSfEkC20T6VZTAKBggqhkjOPQQDAjBkMQswCQYDVQQGEwJ
VUzEZMBcGA1UEChMQVHJhbnNOZXh1cywgSW5jLjEPMA0GA1UECxMGU0hBS0VOMSkwJwYDVQQDEyB
UcmFuc05leHVzLCBJbmMuIFNIQUtFTiBSb290IENBMTAeFw0yMTA4MjAwMDAwMDBaFw0zMTA4MTk
yMzU5NTlaMGcxCzAJBgNVBAYTAlVTMRkwFwYDVQQKExBUcmFuc05leHVzLCBJbmMuMQ8wDQYDVQQ
LEwZTSEFLRU4xLDAqBgNVBAMTI1RyYW5zTmV4dXMsIEluYy4gU0hBS0VOIElzc3VpbmcgQ0EzMFk
wEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEedxAVLKoKQD8g8QPsb9EqRyITRIDArijIRVn1QSXV3O
h7H5HsWihLlTqgbnVM7zF/nXicWvV/kkgvIKOfmCpW6OCAScwggEjMA8GA1UdEwEB/wQFMAMBAf8
wDgYDVR0PAQH/BAQDAgAGMB0GA1UdDgQWBBS7lt4xEs3TlpmEpDYwYDzXUoF9JzAfBgNVHSMEGDA
WgBSajEoZn2TEXjO2KYwWyqe4EEsuWzAXBgNVHSAEEDAOMAwGCmCGSAGG/wkBAQMwgaYGA1UdHwS
BnjCBmzCBmKA6oDiGNmh0dHBzOi8vYXV0aGVudGljYXRlLWFwaS5pY29uZWN0aXYuY29tL2Rvd25
sb2FkL3YxL2NybKJapFgwVjEUMBIGA1UEBwwLQnJpZGdld2F0ZXIxCzAJBgNVBAgMAk5KMRMwEQY
DVQQDDApTVEktUEEgQ1JMMQswCQYDVQQGEwJVUzEPMA0GA1UECgwGU1RJLVBBMAoGCCqGSM49BAM
CA0cAMEQCIGgZROhV4BF/KGMwnKGbSUJ0VMdMavpq1jSifXhtc7B3AiA6ODY5dkKtrUbywLLH+ZJ
X1UnDad6FZwwQVQpUD0oZHA=="

  ]

}

{

  "attest": "C",

  "dest": {

    "tn": [

      "18609653208"

    ]

  },

  "iat": 1668548175,

  "orig": {

    "tn": "14077600036"

  },

  "origid": "2de926c8-2be8-44c6-8e9c-0258a407b018"

}

 

 

 

Example with both "x5u" and "x5c" (for backwards compatibility with VSs that
don't support "x5c"):

 

{

  "alg": "ES256",

  "ppt": "shaken",

  "typ": "passport",

  "x5u": "
<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcertifica
tes.clearip.com%2F908bf82d-0ce7-4c00-a9e8-84a0c1b5cd01%2Fcc54a11039de67bacd9
b6019443cecdb.pem&data=05%7C01%7Calec.fenichel%40transnexus.com%7C2faa300563
ab4c293bff08daf59ccbdf%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C63809235
1070368625%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=d%2FIQ%2B7KLOmVEZ%2FjHhiggk5
%2FXVAoOoJn%2Fz%2FN45AvfgT8%3D&reserved=0>
https://certificates.clearip.com/908bf82d-0ce7-4c00-a9e8-84a0c1b5cd01/cc54a1
1039de67bacd9b6019443cecdb.pem"

  "x5c": [

 
"MIIC+DCCAp6gAwIBAgIQejOopoqGo5lSxqy0y95LDDAKBggqhkjOPQQDAjBnMQswCQYDVQQGEwJ
VUzEZMBcGA1UEChMQVHJhbnNOZXh1cywgSW5jLjEPMA0GA1UECxMGU0hBS0VOMSwwKgYDVQQDEyN
UcmFuc05leHVzLCBJbmMuIFNIQUtFTiBJc3N1aW5nIENBMzAeFw0yMjExMTMyMDMxMjlaFw0yMjE
xMjAyMDMxMjhaMFUxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZUcmFuc05leHVzIERldmVsb3BtZW5
0MQ8wDQYDVQQLEwZTSEFLRU4xFDASBgNVBAMTC1NIQUtFTiA1MThKMFkwEwYHKoZIzj0CAQYIKoZ
Izj0DAQcDQgAEax9FyDGmdfjAES9quPIDg5nPordCq3QiAj1MkWX3ptRQSxD8U3AziaUeqJC/vuF
v47JVsO0rxHvwzza/zqkx16OCATwwggE4MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMB0
GA1UdDgQWBBQIqucXuD9WMdR1sUEPu7rLsFw1+DAfBgNVHSMEGDAWgBS7lt4xEs3TlpmEpDYwYDz
XUoF9JzAXBgNVHSAEEDAOMAwGCmCGSAGG/wkBAQMwgaYGA1UdHwSBnjCBmzCBmKA6oDiGNmh0dHB
zOi8vYXV0aGVudGljYXRlLWFwaS5pY29uZWN0aXYuY29tL2Rvd25sb2FkL3YxL2NybKJapFgwVjE
UMBIGA1UEBwwLQnJpZGdld2F0ZXIxCzAJBgNVBAgMAk5KMRMwEQYDVQQDDApTVEktUEEgQ1JMMQs
wCQYDVQQGEwJVUzEPMA0GA1UECgwGU1RJLVBBMBYGCCsGAQUFBwEaBAowCKAGFgQ1MThKMAoGCCq
GSM49BAMCA0gAMEUCIQDszGSsxrW+dDq5SwuZe/xoW8yO6gMVW503owuYuchH5wIgV2+59q2m9mV
51t8hIxidKLMgnlLqJ5rre/KLSegGVOI=",

 
"MIIC8TCCApigAwIBAgIQaeMkSbXPfDSfEkC20T6VZTAKBggqhkjOPQQDAjBkMQswCQYDVQQGEwJ
VUzEZMBcGA1UEChMQVHJhbnNOZXh1cywgSW5jLjEPMA0GA1UECxMGU0hBS0VOMSkwJwYDVQQDEyB
UcmFuc05leHVzLCBJbmMuIFNIQUtFTiBSb290IENBMTAeFw0yMTA4MjAwMDAwMDBaFw0zMTA4MTk
yMzU5NTlaMGcxCzAJBgNVBAYTAlVTMRkwFwYDVQQKExBUcmFuc05leHVzLCBJbmMuMQ8wDQYDVQQ
LEwZTSEFLRU4xLDAqBgNVBAMTI1RyYW5zTmV4dXMsIEluYy4gU0hBS0VOIElzc3VpbmcgQ0EzMFk
wEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEedxAVLKoKQD8g8QPsb9EqRyITRIDArijIRVn1QSXV3O
h7H5HsWihLlTqgbnVM7zF/nXicWvV/kkgvIKOfmCpW6OCAScwggEjMA8GA1UdEwEB/wQFMAMBAf8
wDgYDVR0PAQH/BAQDAgAGMB0GA1UdDgQWBBS7lt4xEs3TlpmEpDYwYDzXUoF9JzAfBgNVHSMEGDA
WgBSajEoZn2TEXjO2KYwWyqe4EEsuWzAXBgNVHSAEEDAOMAwGCmCGSAGG/wkBAQMwgaYGA1UdHwS
BnjCBmzCBmKA6oDiGNmh0dHBzOi8vYXV0aGVudGljYXRlLWFwaS5pY29uZWN0aXYuY29tL2Rvd25
sb2FkL3YxL2NybKJapFgwVjEUMBIGA1UEBwwLQnJpZGdld2F0ZXIxCzAJBgNVBAgMAk5KMRMwEQY
DVQQDDApTVEktUEEgQ1JMMQswCQYDVQQGEwJVUzEPMA0GA1UECgwGU1RJLVBBMAoGCCqGSM49BAM
CA0cAMEQCIGgZROhV4BF/KGMwnKGbSUJ0VMdMavpq1jSifXhtc7B3AiA6ODY5dkKtrUbywLLH+ZJ
X1UnDad6FZwwQVQpUD0oZHA=="

  ]

 

}

{

  "attest": "C",

  "dest": {

    "tn": [

      "18609653208"

    ]

  },

  "iat": 1668548175,

  "orig": {

    "tn": "14077600036"

  },

  "origid": "2de926c8-2be8-44c6-8e9c-0258a407b018"

}

 

 

 

Sincerely,

 

Alec Fenichel

Chief Technology Officer

 
<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransnexu
s.com%2F&data=05%7C01%7Calec.fenichel%40transnexus.com%7C2faa300563ab4c293bf
f08daf59ccbdf%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C63809235107036862
5%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qPgbTXzc8xXGrAC0yl72zR%2BVgDtXy9aa4ES
ZEOHfYhw%3D&reserved=0> TransNexus

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

 <tel:[phone]> [phone]

 

From: stir < <mailto:[e-mail]> [e-mail]> on behalf
of Peterson, Jon < <mailto:jon.peterson=[e-mail]>
jon.peterson=[e-mail]>
Date: Friday, January 6, 2023 at 09:25
To: Jack Rickard < <mailto:[e-mail]>
[e-mail]>, IETF STIR Mail List < <mailto:[e-mail]>
[e-mail]>
Cc: Simon Castle < <mailto:[e-mail]>
[e-mail]>
Subject: Re: [stir] OCSP and short-lived certs

 

A good analysis. Of things that are new here, I recall I've seen short-lived
with stapling proposed before, which is potentially an interesting spin on
things.

 

A couple points I'd add:

 

In terms of the problem statement, I'd hesitate to call the risk of
revealing a list of TNs a "privacy" issue - it's not that the privacy of
some person is compromised by it. It's more a corporate security and
competition issue. Not to say that makes it an invalid concern.

 

I'm not sure why the AIA method reveals to the CA who you are calling, even
partially? I mean, it reveals something (probably not much, just the VS)
about who received calls, but it's unclear how the CA could correlate that
with callers, and likely even callees. And the revelation that does happen
would be the same for all non-stapled approaches, wouldn't it?

 

Support for OCSP seems to be pretty common in the world of PKI - I think
some SHAKEN certs in the wild have OCSP in them already - so I don't think
OCSP support itself such a heavy lift. The lift is doing the extension that
we're specifying here, which we will have to do whether we staple or no.

 

Also you might cite the short-lived draft:

 

https://datatracker.ietf.org/doc/html/draft-peterson-stir-certificates-short
lived-03

 

. though as we've been trying to get OCSP over the hump, it hasn't gotten a
ton of energy behind it recently. If you're interested in working on porting
the staple mechanism that I've been working on for OCSP into short-lived,
I'd definitely be up for that.

 

But to your point about getting us to a destination: at a high level, I
think there are use cases where the RFC 8226 AIA mechanism works for just
fine - while some enterprises have number ranges that change frequently,
others have numbering resources that are stable for decades. I don't think
there's any good reason for us to tell people not to do that, if it works
for me. There may be very sophisticated actors that are open to dynamic
short-lived certs, even down to the single TN level, and others who might
find that a bit much. And OCSP can coexist with any of this, with or without
our extension. So I guess. I'm looking at this like we're building multiple
mechanisms, and not really inclined to take anything off the table at this
point. Even if we believe that short-lived at the single TN level with
stapling would be the most technically elegant solution, getting ACME STAR
up looks like a much heavier lift to me than getting OCSP working, say. 

 

Jon Peterson

Neustar (a TransUnion Company)

 

From: Jack Rickard < <mailto:[e-mail]>
[e-mail]>
Date: Wednesday, January 4, 2023 at 5:43 AM
To: "Peterson, Jon" < <mailto:[e-mail]>
[e-mail]>, IETF STIR Mail List < <mailto:[e-mail]>
[e-mail]>
Cc: Simon Castle < <mailto:[e-mail]>
[e-mail]>
Subject: 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. 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). 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