<div dir="ltr">Since we've had some known issues with the current STIR/SHAKEN implementation and since we discovered a few more during the latest OpenSIPIt get-together, we've decided to do a re-evaluation and refactor.  Some of that refactor you've already seen in the recent addition of libjwt to the third-party infrastructure in the source tree.  That addition has already allowed us to eliminate over 1000 lines of custom code in Asterisk itself.  We have more to do though and need your help with some of it.<div><br></div><div>Attestation:</div><div><br></div><div>Thanks to libjwt, we now have attestation working to the point where we're using the correct caller-id TN and other open-source stirt/shaken implementations can  successfully validate our passport signature and decode the proper passport fields.  Huzzah!  We still have some plumbing work to do though since the current method of associating TNs and certs is neither flexible nor efficient.  There are a number of good possibilities to make this better and we should have some design ideas to share later this week.</div><div><br></div><div>Verification:</div><div><br></div><div>The verification process ultimately depends on two pieces of data...the orig_tn in the passport received in the incoming Identity header, and the certificate we retrieve from the URL also in the passport.  Right now, we have verification working right up to the point where we have to verify them against each other.  It sounds weird but there's a lot of other verification that has to happen before we get to the point of actually verifying the TN against the cert (passport signature validation, passport dates, cert validity dates, cert trust, etc).  Anyway, there are a number of ways a certificate can indicate it has authority over the TN...</div><div><ol><li>The cert can contain a TNAuthList X.509 extension containing a single TN.  No -brainer.  If the TN in the orig_tn passport field doesn't match the TN in the cert, it's a fail.</li><li>The cert can contain a TNAuthList X.509 extension containing a TN range.  Also a no-brainer.  The orig_tn is either in the range or not.<br></li><li>The cert can contain a URL in an "authorityInfoAccess" X.509 extension.  From RFC8226...  " A verifier would then follow the URI to ascertain whether the TNs in the list are authorized for use by the caller".   Since the list is supposed to be in the same form as the TNAuthList, that should work fine.</li><li>The cert can contain a TNAuthList X.509 extension containing a Service Provider Code.  Uhm, OK.  What are we supposed to do with that?  I can't find any RFC or ATIS document that describes how you match a TN to an SPC.  There are some hints that a trusted-well-known service _might_ be made available where you could get a list of TNs by SPC, or better yet, a service where you can submit a specific TN and get back the SPC, but I can find no actual documentation to that effect.  What's worse, ATIS-10000080.v005 specifically states that for an end-entity certificate... "The TNAuthList shall contain a single SPC value. The SPC value shall contain only numbers and uppercase letters. The TNAuthList shall <b>not contain any TNs or TN ranges</b>. ".  Nice.</li></ol><div>OK, here's where we need your help....   Does anyone have any real-world examples of certificates, TNAuthLists, documents, etc.  that would allow us to actually implement and test items 3, and especially 4, above?   I can find absolutely none.</div></div><div><br></div><div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><font color="#073763" style="--darkreader-inline-color: #94ccf7;">George Joseph</font></div><div style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><font color="#073763" style="--darkreader-inline-color: #94ccf7;">Asterisk Software Developer</font></div><div style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><font color="#073763" style="--darkreader-inline-color: #94ccf7;">Sangoma Technologies</font></div><div style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><font color="#073763" style="--darkreader-inline-color: #94ccf7;">Check us out at <a href="http://www.sangoma.com/" style="color:rgb(17,85,204)" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org/" style="color:rgb(17,85,204)" target="_blank">www.asterisk.org</a></font></div></div></div></div></div>