<p><a href="https://gerrit.asterisk.org/c/asterisk/+/15822">View Change</a></p><p>3 comments:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.asterisk.org/c/asterisk/+/15822/3/configs/samples/stir_shaken.conf.sample">File configs/samples/stir_shaken.conf.sample:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/c/asterisk/+/15822/3/configs/samples/stir_shaken.conf.sample@25">Patch Set #3, Line 25:</a> </p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><pre style="font-family: monospace,monospace; white-space: pre-wrap;">; A certificate store is used to examine, and load all certificates found in a<br>; given directory. When using this type the public key URL is generated based<br>; upon the filename, and variable substitution.<br></pre></blockquote></p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">This functionality isn't yet implemented (we've got an issue for it), but these will be for our own storage, not the ones coming in since we don't have any control over that.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">Not sure I understand about is not having control.  Don't we decide where to put certs we've retrieved?</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/c/asterisk/+/15822/3/configs/samples/stir_shaken.conf.sample@51">Patch Set #3, Line 51:</a> </p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><pre style="font-family: monospace,monospace; white-space: pre-wrap;">; URL to the public certificate. Must be of type X509. This will be put in the identity header<br>; when signing.<br>;public_key_url=http://mycompany.com/alice.pem<br></pre></blockquote></p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">This is different from path. Path is the location of the private cert that we use to sign on outbound. The public_key_url is what we put in the Identity header to let the remote end know where to download the public certificate.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">Yep, I meant to say that the key has to be the one that generated the cert.<br>I'm still confuses as to how this relates to both path and public_key_url in the store.</p></li></ul></li><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.asterisk.org/c/asterisk/+/15822/3/res/res_stir_shaken.c">File res/res_stir_shaken.c:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/c/asterisk/+/15822/3/res/res_stir_shaken.c@618">Patch Set #3, Line 618:</a> <code style="font-family:monospace,monospace">   if (public_key_is_expired(public_key_url)) {</code></p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">Yeah, Richard is right here. There's a chance that it could be expired on the server itself. Nothing to do with us in that case, but a valid scenario.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">Yeah this is confusing.  Expired refers to the cache settings in the HTTP response headers, should the sender choose to add them.  It's like a DNS TTL.  'Retrieve from us once an hour in case we replaced the cert".  The other check is the valid dates of the cert we received in the HTTP response payload. It could also be "expired".  In fact, it could expire while we have it cached. 😊</p><p style="white-space: pre-wrap; word-wrap: break-word;">Maybe they should be renamed to cache_expiry and cert_expiry to avoid any further confusion.</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.asterisk.org/c/asterisk/+/15822">change 15822</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.asterisk.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.asterisk.org/c/asterisk/+/15822"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: asterisk </div>
<div style="display:none"> Gerrit-Branch: 16 </div>
<div style="display:none"> Gerrit-Change-Id: Ia00b20835f5f976e3603797f2f2fb19672d8114d </div>
<div style="display:none"> Gerrit-Change-Number: 15822 </div>
<div style="display:none"> Gerrit-PatchSet: 3 </div>
<div style="display:none"> Gerrit-Owner: Benjamin Keith Ford <bford@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Friendly Automation </div>
<div style="display:none"> Gerrit-Reviewer: George Joseph <gjoseph@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Joshua Colp <jcolp@sangoma.com> </div>
<div style="display:none"> Gerrit-CC: Richard Mudgett <rmudgett@digium.com> </div>
<div style="display:none"> Gerrit-Comment-Date: Mon, 03 May 2021 12:10:34 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Comment-In-Reply-To: George Joseph <gjoseph@digium.com> </div>
<div style="display:none"> Comment-In-Reply-To: Benjamin Keith Ford <bford@digium.com> </div>
<div style="display:none"> Comment-In-Reply-To: Richard Mudgett <rmudgett@digium.com> </div>
<div style="display:none"> Gerrit-MessageType: comment </div>