Subject: [stir] Choice of STIR signature algorithm

From: John Mattsson <[email-masked]>
Date: Tue, 5 Apr 2016 14:36:49 +0000

I think there are several strong reasons to change the default signature
algorithm in draft-ietf-stir-rfc4474bis and draft-ietf-stir-passport. The
current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using SHA-256), but
I cannot find any number for MTI/Recommended/Minimum/Default key length.

1. RSA signing is extremely slow compared to modern alternatives. On a
Core i5-6600, ES256 (ECDSA using P-256 and SHA-256) is 21 times faster
than RSA-2048, and Ed25519 is 67 times faster
(https://bench.cr.yp.to/results-sign.html). As RSA-2048 is normally
classified as roughly 112-bit security (RFC3766, NIST, ENISA), a more fair
comparison is with RSA-3072, and then ES256 is 52 times faster and Ed25519
is 169 times faster.

2. RSA signatures are much larger than their ECC counterparts. RSA-2048
signatures are 256 bytes and RSA-3072 signatures are 384 bytes, while
ES256 and Ed25519 signatures are only 64 bytes.

3. PKCS1-v1_5 is not a very good algorithm. It has no security proofs, no
advantages, is disrecommended by ENISA (European Union Agency for Network
and Information Security), and has been replaced in TLS 1.3. I do not
think this is the algorithm we should use in STIR.

I think the right algorithm choice for STIR is ES256 or Ed25519.
Signature processing is likely the main burden for the Authentication
Service, and changing from RSA to ECC significantly reduces the amount of
hardware needed, and therefore the cost. A single 3.3 Ghz Skylake core can
do only 400 RSA-3072 or 1,000 RSA-2048 signatures per second, but 21,000
ES256 or 68,000 Ed25519 signatures per second. RSA verification is a bit
faster than ECC, but the different is much smaller that for signing,
RSA-3072 verifications are e.g. twice as fast as Ed25519 verifications.

Cheers,
John

------------------------------------------------------------------
JOHN MATTSSON
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator
Senior Researcher, Security

---

From: Sean Turner <[email-masked]>
Date: Tue, 5 Apr 2016 13:20:23 -0300

> I think the right algorithm choice for STIR is ES256 or Ed25519.

I agree.

spt

---

From: Chris Wendt <[email-masked]>
Date: Tue, 5 Apr 2016 14:08:49 -0300

I’m supportive of that, I can try to remember to bring it up in the session on passport this afternoon as well to discuss.

-Chris

> On Apr 5, 2016, at 1:20 PM, Sean Turner <[email-masked]> wrote:
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 5 Apr 2016 17:27:20 +0000

I can support as well

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards 
AT&T
Cell: 609-903-3360
Email: [email-masked]

> On Apr 5, 2016, at 1:09 PM, Chris Wendt <[email-masked]> wrote:
>

---

From: John Mattsson <[email-masked]>
Date: Tue, 5 Apr 2016 17:42:59 +0000

On 05/04/16 14:08, "Chris Wendt" <[email-masked]> wrote:

>I’m supportive of that, I can try to remember to bring it up in the
>session on passport this afternoon as well to discuss.

Please do, good to get discussion.

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 5 Apr 2016 18:07:54 +0000

To date we have not moved this to EC because (at least as far as I understand things) many elements of web PKI, including many CAs, don't support these algorithms yet. If our assessment of that is changing, then let's revisit it. 

Jon Peterson
Neustar, Inc. 

Sent from my iPad

> On Apr 5, 2016, at 11:37 AM, John Mattsson <[email-masked]> wrote:
>

---

From: John Mattsson <[email-masked]>
Date: Tue, 5 Apr 2016 20:04:52 +0000

I think that this has changed, and will change even more until STIR is
deployed. According to notary.icsi.berkeley.edu/#statistics 23 % of all
TLS connections are currently setup with ECDSA certificates. One example
is https://en.wikipedia.org. And we don’t need unanimous support from all
CAs; it is enough that ECDSA certificates are fairly easy to get.

(Ed25519 certificates are probably hard to get unless you run your own CA).

John

On 05/04/16 15:07, "Peterson, Jon" <[email-masked]> wrote:

>To date we have not moved this to EC because (at least as far as I
>understand things) many elements of web PKI, including many CAs, don't
>support these algorithms yet. If our assessment of that is changing, then
>let's revisit it. 
>
>Jon Peterson
>Neustar, Inc. 
>
>Sent from my iPad
>

---

From: Richard Shockey <[email-masked]>
Date: Tue, 05 Apr 2016 16:46:19 -0400

And on a nation state basis my assumption would be that something like ECC256 would be a requirement for the computational load factor if nothing else.

Its certainly how I would write a STIR RFP for a CA if this were for the carriers in the NANP. Setting one or two SHOULD supports seem sensible. I would not set the requirement to MUST. 

— 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

---

From: Russ Housley <[email-masked]>
Date: Tue, 5 Apr 2016 17:55:43 -0400

There was just a discussion of this point in the STIR session at IETF 95.  The sense of the room is to require verification of both RSA and ECC signatures.  This allows the use of existing infrastructure, and allows rapid movement to ECC as soon as that infrastructure is readily available

Russ

---

From: Richard Shockey <[email-masked]>
Date: Tue, 05 Apr 2016 18:47:56 -0400

Well I would have to insist that such a statement is SHOULD verify, either or both, how it deploys and under what conditions are still probably a nation-state matter certainly if they are used with E.164 plan.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 6 Apr 2016 13:09:56 -0300

To be clear, the suggestion is must implement, not must use. 
Specifically, for _this_ part of the conversation, its that the code in 
a verifier must be _able_ to verify presented with either.

---

From: Richard Shockey <[email-masked]>
Date: Wed, 06 Apr 2016 21:11:07 -0400

Implement is one thing, must use in verification is another.  I won’t support MUST be able to verify. 

This is shaping up to be another TLS food fight re SIP PBX’s and the carriers re SIP Connect and we all know where that went. Nowhere. Must support use ..well maybe. 

— 
Richard Shockey
Shockey Consulting LLC

---

From: Eric Burger <[email-masked]>
Date: Thu, 7 Apr 2016 06:43:32 -0300

The statement that using ECDSA at the single MTI would hold up STIR deployment is factually incorrect. It is not a changing view that CA’s do ECDSA. Major CA’s have been doing ECDSA for over a year.

Personally, going from RSA to ECDSA is a minor pain for me because my RSA code is running. However, I expect my ECDSA code to be running next week. Thus, I might have a selfish incentive to say, “Do RSA now and we will do ECDSA in phase never.” However, I would much rather have a well-implemented, useful, and scalable implementation than a weak, already obsolete, and resource intensive implementation.

If one is trying to slow down the adoption of STIR by saying we could not possibly use modern, scalable crypto, or trying to slow down the adoption of STIR by saying that we need a more complex protocol that is statistically more likely to have bugs, that is a losing argument IMHO. To quote someone from the room, I would not want to be the person standing in front of the FCC explaining why STIR is not up to IETF standards. I would rather be the person who is explaining why STIR is the appropriate solution for VoIP caller ID spoofing mitigation.

> On Apr 5, 2016, at 5:04 PM, John Mattsson <[email-masked]> wrote:
>

---

From: Eric Burger <[email-masked]>
Date: Thu, 7 Apr 2016 06:45:11 -0300

Learning from SIP Connect, having one and only one MTI ensures some interoperability. It also allows us to demonstrate interoperability between now and when the regulators do their thing and regulate. Better yet, the regulators are more likely to say, “Use what you’ve got” if what we have is up to modern crypto standards.

> On Apr 6, 2016, at 10:11 PM, Richard Shockey <[email-masked]> wrote:
> 
> 
>

---

From: Chris Wendt <[email-masked]>
Date: Thu, 7 Apr 2016 09:04:36 -0300

Hi Richard,

I’m not sure that is the right perspective to look at this.

EC has good properties, especially when it comes to CPU, but also from it’s cryptographic strength.  I care a lot about the CPU part, from a cost point of view, so i think that is number 1 priority.

But, RSA256 is there today as most commonly used, so it’s hard to not include.

I think the consensus was that RSA256 comes mostly free in many of the likely implementations out there.

I would argue EC does as well, but i’ll give the benefit of the doubt to say, not everyone is completely comfortable with it or may need some more time to have a production grade implementation perhaps.

We do need to recognize that as time goes on, the best practice will change so the number of algorithms will follow a similar path that the TLS world is dealing with, so this isn’t the end of the story either.

Two MTI today, likely more tomorrow, or deprecated algorithms as well.

This is reality, so let’s look at it more in that light.

-Chris

---

From: Richard Shockey <[email-masked]>
Date: Thu, 07 Apr 2016 20:43:25 -0400

>EC has good properties, especially when it comes to CPU, but also from it’s cryptographic strength.  I care a lot about the CPU part, from a cost point of view, so i think that is number 1 priority.

ca
RS> Of course there is no argument about that. In a US/CA NANP carrier implementation environment I would assume its mandated. If you started to look at how a NANP STIR RFP would be constructed you would put severe constraints on options. And on costs.. Well no one, certainly not your employer,  is going to pay 500M a year for this or even 140M if you know what I mean. :-) 

>But, RSA256 is there today as most commonly used, so it’s hard to not include.

RS> MUST support but do not mandate implementation. We’ll deal with that when we start to look at the national specific deployment options. Chris what I want to see is a protocol and nothing else. Please insert implementable examples in the drafts. Where do you see this in the INVITE with actually examples.  I will raise hell if I don’t see this in the future. Jon’s draft is rhetoric and nothing else it is non implementable. 

>I would argue EC does as well, but i’ll give the benefit of the doubt to say, not everyone is completely comfortable with it or may need some more time to have a production grade implementation perh…

RS> I still think the TLS issue in SIPConnect is applicable. The IETF can bark all it wants but in the end if the industry will not support it will not deploy and there is way too much ideology and political correctness in the way some protocols are developed.

>We do need to recognize that as time goes on, the best practice will change so the number of algorithms will follow a similar path that the TLS world is dealing with, so this isn’t the end of the st…

RS> Agreed but STIR with your new concepts has a great chance of actually deploying. Do not burden it by defining constraints you know our industry will not accept.

---

From: John Mattsson <[email-masked]>
Date: Mon, 11 Apr 2016 13:19:04 +0000

I don’t know why so much of the discussion during the Tuesday meeting was
about root certificates. As Eric pointed out on the mail, it is not hard
to get a ECDSA certificate as Digicert, Entrust, Globalising, Symantec,
Certicom, Comodo, and soon Let’s encrypt will happily give you one. As
Russ pointed out most (or all) of these ECDSA certificates will be signed
by a RSA root certificate. But root certificates and verification of the
credentials seems to be out of scope of STIR and does not affect the
PASSporT object. As far as I understand, the only thing STIR should
specify is verification of the PASSporT object.

If we mandate RSA in addition to ECC (which I don’t think is necessary,
but do not oppose), then I think that RS256 (PKCS1-v1_5) is the wrong
algorithm. Both TLS 1.3 (draft-ietf-tls-tls13) and IPSec
(draft-ietf-ipsecme-rfc4307bis) are replacing PKCS1-v1_5 with PSS (JOSE
alg PS256). If STIR uses RSA, it should do the same.

If STIR uses RS256 (PKCS1-v1_5) for backward compatibility (which I don’t
see as necessary as RFC4474 is not deployed) then this should be clearly
stated, and RS256 (PKCS1-v1_5) should be NOT RECOMMENDED.

Cheers,
John

On 07/04/16 21:43, "stir on behalf of Richard Shockey"
<[email-masked] on behalf of [email-masked]> wrote:

>>EC has good properties, especially when it comes to CPU, but also from
>>it’s cryptographic strength.  I care a lot about the CPU part, from a
>>cost point of view, so i think that is number 1 priority.
>
>ca
>RS> Of course there is no argument about that. In a US/CA NANP carrier
>implementation environment I would assume its mandated. If you started to
>look at how a NANP STIR RFP would be constructed you would put severe
>constraints on options. And on costs.. Well no one, certainly not your
>employer,  is going to pay 500M a year for this or even 140M if you know
>what I mean. :-) 
>
>
>
>>
>RS> MUST support but do not mandate implementation. We’ll deal with that
>when we start to look at the national specific deployment options. Chris
>what I want to see is a protocol and nothing else. Please insert
>implementable examples in the drafts. Where do you see this in the INVITE
>with actually examples.  I will raise hell if I don’t see this in the
>future. Jon’s draft is rhetoric and nothing else it is non implementable.
>
>
>>
>>I would argue EC does as well, but i’ll give the benefit of the doubt to
>>say, not everyone is completely comfortable with it or may need some
>>more time to have a production grade implementation perhaps.
>
>RS> I still think the TLS issue in SIPConnect is applicable. The IETF can
>bark all it wants but in the end if the industry will not support it will
>not deploy and there is way too much ideology and political correctness
>in the way some protocols are developed.
>
>
>>
>>We do need to recognize that as time goes on, the best practice will
>>change so the number of algorithms will follow a similar path that the
>>TLS world is dealing with, so this isn’t the end of the story either.
>
>
>RS> Agreed but STIR with your new concepts has a great chance of actually
>deploying. Do not burden it by defining constraints you know our industry
>will not accept. 
>
>
>>
>>> This is shaping up to be another TLS food fight re SIP PBX’s and the
>>>carriers re SIP Connect and we all know where that went. Nowhere. Must
>>>support use ..well maybe.
>>> 
>>> 
>>> — 
>>> Richard Shockey
>>> Shockey Consulting LLC
>>> On 4/6/16, 12:09 PM, "stir on behalf of Robert Sparks"
>>><[email-masked] on behalf of [email-masked]> wrote:
>>> 
>>>>> Well I would have to insist that such a statement is SHOULD verify,
>>>>>either or both, how it deploys and under what conditions are still
>>>>>probably a nation-state matter certainly if they are used with E.164
>>>>>plan.
>>>>> 
>>>>> 
>>>>> On 4/5/16, 5:55 PM, "stir on behalf of Russ Housley"
>>>>><[email-masked] on behalf of [email-masked]> wrote:
>>>>> 
>>>>>> There was just a discussion of this point in the STIR session at
>>>>>>IETF 95.  The sense of the room is to require verification of both
>>>>>>RSA and ECC signatures.  This allows the use of existing
>>>>>>infrastructure, and allows rapid movement to ECC as soon as that
>>>>>>infrastructure is readily available
>>>>>> 
>>>>>> Russ
>>>>>> 
>>>>>> 
>>>>>>> And on a nation state basis my assumption would be that something
>>>>>>>like ECC256 would be a requirement for the computational load
>>>>>>>factor if nothing else.
>>>>>>> 
>>>>>>> Its certainly how I would write a STIR RFP for a CA if this were
>>>>>>>for the carriers in the NANP. Setting one or two SHOULD supports
>>>>>>>seem sensible. I would not set the requirement to MUST.
>>>>>>> 
>>>>>>> —
>>>>>>> Richard Shockey
>>>>>>> Shockey Consulting LLC
>>>>>>> On 4/5/16, 4:04 PM, "stir on behalf of John Mattsson"
>>>>>>><[email-masked] on behalf of [email-masked]>
>>>>>>>wrote:
>>>>>>> 
>>>>>>>>>> On Apr 5, 2016, at 11:37 AM, John Mattsson
>>>>>>>>>><[email-masked]>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> algorithm in draft-ietf-stir-rfc4474bis and
>>>>>>>>>>draft-ietf-stir-passport.
>>>>>>>>>> The
>>>>>>>>>> current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using
>>>>>>>>>>SHA-256),
>>>>>>>>>> but
>>>>>>>>>> classified as roughly 112-bit security (RFC3766, NIST, ENISA),
>>>>>>>>>>a more
>>>>>>>>>> fair
>>>>>>>>>> comparison is with RSA-3072, and then ES256 is 52 times faster
>>>>>>>>>>and
>>>>>>>>>> Ed25519
>>>>>>>>>> is 169 times faster.
>>>>>>>>>> 
>>>>>>>>>> 3. PKCS1-v1_5 is not a very good algorithm. It has no security
>>>>>>>>>>proofs,
>>>>>>>>>> no
>>>>>>>>>> advantages, is disrecommended by ENISA (European Union Agency
>>>>>>>>>>for
>>>>>>>>>> Network
>>>>>>>>>> Service, and changing from RSA to ECC significantly reduces the
>>>>>>>>>>amount
>>>>>>>>>> of
>>>>>>>>>> hardware needed, and therefore the cost. A single 3.3 Ghz
>>>>>>>>>>Skylake core
>>>>>>>>>> can

---

From: Chris Wendt <[email-masked]>
Date: Tue, 12 Apr 2016 12:31:34 -0400

Hi John,

I’d be happy to get RS256 and ES256 with a preference to the later.

To add PS256, i’d defer to others opinions.

RS256 has a simple advantage that it’s commonly implemented in most JWT libraries today.  But that’s not necessarily a a great justification.

Beyond that, particularly after creating some example tokens and seeing the very compact size of the signature, I have a big preference for ES256 as the default from the size and CPU advantage, so I’m less opinionated on PS256 as another option or replacing RS256.

Just as a preview:

ES256 based token:
eyJ0eXAiOiJwYXNzcG9ydCIsImFsZyI6IkVTMjU2IiwieDV1IjoiaHR0cHM6Ly9j
ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNydCJ9
.
eyJpYXQiOiIxNDQzMjA4MzQ1Iiwib3RuIjoiMTIxNTU1NTEyMTIiLCJkdXJpIjoi
c2lwOmFsaWNlQGV4YW1wbGUuY29tIn0
.
KK89q2RFY-BkKQQhiB0z6-fIaFUy6NDyUboKXOix9XnYLxTCjdw1UHjCbw4CefeK
wH_t7W-bnGlZz4pI-rMjfQ

RS256 based token:
eyJ0eXAiOiJwYXNzcG9ydCIsImFsZyI6IlJTMjU2IiwieDV1IjoiaHR0cHM6Ly9j
ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNydCJ9
.
eyJpYXQiOiIxNDQzMjA4MzQ1Iiwib3RuIjoiMTIxNTU1NTEyMTIiLCJkdXJpIjoi
c2lwOmFsaWNlQGV4YW1wbGUuY29tIn0
.
AaeXRqm7kHnkZu2j6cQmDCiomZRiaE55bYWhFgnX8xMqpBFq96M0xgMM5OLa9_LM
rkuKv2ivK5GZz8OlFrmAirucRlAh8YdUkj5Cr5xPRr-gg9acD9jqJUnQ-ZxpL1yq
-FFVLhvpbsE5NMPHXUp5lpt62rD-S0NlhwHNCeMqZHxt6T5BmZBXITEd1PRRij_6
FhE3wxWEhZMthWJuEbcPpRMZDu-R7lTNddn62nUKjn3s00R3gm25Dto5Z0dzfQpA
ysJvnbc1QRimfsYqJPUFc57lnglVLf4WrpeZCc8-LcoXeSr_dseDgsrmg2EuHmn5
h1nTOmLgF16ZHm121ZVjiXz2sMFvs9RaIxw0AFkM7rnV56OxAFCRuzMNldiEVf8p
lRZVvqZ4BfVQlCNXNyyVgPOUtNr3ta6yD2H0oANQvvHtwjuSwB9Kruj4Wsu5N7Ik
i4MBs6SWJDmcUV-NW_AHYLaao-IvFVe4oCkJNjsqwwXuLv1TO2sDHdc5sQO5zm21
019PPxw1udHVtywsRVNKLo0RzE0TqYUF7XclCDur7MMOx9SnStV2PFIM7Jejyn9x
54RtJEjOnchaSalfIFr_UXqXgVmRZVTzLDQIlcmHjlhhLnCnNx3sYsAANen8Y8jt
fgJ2ewjGotB4Lq8VYe1FacBKKk0VyCfImXba0u1hB8Q

-Chris

> On Apr 11, 2016, at 9:19 AM, John Mattsson <[email-masked]> wrote:
>

---

From: Richard Shockey <[email-masked]>
Date: Tue, 12 Apr 2016 16:35:09 -0400

Excellent discussion.  But what I will insist on in further draft revisions is less rhetoric and more implementation examples. Do this .. look for that. Were working on how to display the data to the UA> 

We have to show where in the INVITE this stuff SHOULD be inserted and what it might look like to give guidance to implementers on what to look for. The rest is policy and we are not going there .not now not ever. 

I could care less about root CA issues since no one in the IETF is going to decide those problems if target address involves E.164 within national boundries. No one is going to tell the US, British, Swedish or French governments how the plan to secure their voice networks. The body of law here is indisputable.

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Apr 2016 16:57:32 -0400

> specify is verification of the PASSporT object.

We will need to say that the validation will include RFC 5280 path validation to a trust anchor.  This means that the signature on each certificate will be validated.  So, for quite some time we will need to be able to validate RSA PKCS#1 v1.5 signatures, either on the PASSporT object or on a certificate, even if we state a strong preference for ECDSA.

Russ

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 13 Apr 2016 20:48:40 +0000

I'll expose the depth of my ignorance by mentioning that I am hopeful that whatever credentials are used, they can be cached in the call processing servers using them.

Real-time call processing tens of thousands of calls per second during the busy hour in an environment where post-dial delay is monitored very critically (as one example) means that we don't want to add (iterative?) query/response flows to certificate authority systems whose capacity, availability, and performance we have no control over.

I suspect every single person reading this e-mail has personal experience with folks who've been frustrated in one way or another by application security based on certificates.

I am staunchly in favor of a very circumspect approach to their use in authenticating calling party numbers in calls signaled in SIP.

Pierce Gorman

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: April 12, 2016 3:58 PM
To: John Mattsson <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] Choice of STIR signature algorithm

> I don't know why so much of the discussion during the Tuesday meeting
> was about root certificates. As Eric pointed out on the mail, it is
> not hard to get a ECDSA certificate as Digicert, Entrust, Globalising,
> Symantec, Certicom, Comodo, and soon Let's encrypt will happily give
> you one. As Russ pointed out most (or all) of these ECDSA certificates
> will be signed by a RSA root certificate. But root certificates and
> verification of the credentials seems to be out of scope of STIR and
> does not affect the PASSporT object. As far as I understand, the only
> thing STIR should specify is verification of the PASSporT object.

Russ

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Richard Shockey <[email-masked]>
Date: Wed, 13 Apr 2016 18:38:01 -0400

Duh.. Pierce there is no question in my mind that all we want from STIR is the protocol and where it sits in the INVITE.  Beyond that STIR is done. Shut it down. Quickly please. 

We need  examples to enable implementers to code correctly within either The CSCF or TAS which is my earlier point. I could care less where these exist in the documents but if you are Nokia, Ericcson, Genband etc the existing documents are insufficient in my judgement. To much rhetoric and too little examples. 

How we deploy this in the NANP is a separate and totally political issue. I may have to personally deal with this within this in the NANC. 

What the British et al want to do is their problem, though we need to coordinate and be extremely sensitive on how our friends at OFCOM, CRTC, ARCEP, FICORA think. Its their numbers. But that is not a IETF problem.

— 
Richard Shockey
Shockey Consulting LLC

---

From: Chris Wendt <[email-masked]>
Date: Thu, 14 Apr 2016 19:29:43 -0400

Hi Pierce,

Exactly why we are very clearly advocating the ability to start with a slow and steady approach both in ATIS and IETF, until we can build up operational experience and efficiencies at a large scale.

Certificate cachability is key starting out, may even want proactive caching or push strategies if possible (did i hear somebody say distributed registries?) :)
Also want to make sure initial deployment doesn’t block call processing for any potential certificate retrieval issues or problems, until we build more confidence in the system.

-Chris

> On Apr 13, 2016, at 4:48 PM, Gorman, Pierce A [CTO] <[email-masked]> wrote:
> 
> From: Russ Housley [mailto:[email-masked] <mailto:[email-masked]>]
> To: John Mattsson <[email-masked] <mailto:[email-masked]>>
> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>