Hi Pierce,
Happy to jump on a call. We've done a lot of work around automation of certificate management for SIP connectivity outside of the ATIS ALIII work, and we previously discounted ACME due to the inherent complexity brought about by the Domain Validation mechanism, and the fact that it was speficically designed for Web (HTTPS) connections, rather than SIP over TLS or other protocols.
RFC8555 mandates Domain Validation be carried out through 1 of 2 options (RFC8737 adds a 3rd option), but each of these brings unique challenges:
- HTTP-01 - This mechanism uses HTTP requests to the ACME Client (in our case, that'd be an SBC run by the AVSP) in order to validate the requestor is the same entity as listed against the FQDN in the request. The issue here is that, because the SBC is not a web server, you'd need to run a web server against every SIP interface on the SBC. If you have 100's of interconnects, this would end up with a significant performance hit. Additionally, as it's running on port 80, you're making the SBC more vulnerable to discovery through port scanning, and providing a whole new server layer that needs to be secured. My recommendation is that this method be explicitly excluded from the ALIII specs for the SIP over TLS certificates for these reasons.
- DNS-01 - This mechanism requires the ACME Client to publish a TXT record with the token to the DNS server, which the ACME Server can verify. However the RFC does not specify any mechanism for the publication of the TXT record. This can lead to messy implementation as each DNS provider uses bespoke API's for DNS zone management. The best solution we would have here is to mandate that these updates use the DNS UPDATE method outlined in RFC2136. I believe this would be the most feasible method for Domain Validation of a SIP endpoint for ACME, as it doesn't open any additional ports on the SBC, and does not require any significant additional resources to be running on the SBC. However, while most DNS providers should support RFC2136, there's no guarantee that they do.
- TLS-ALPN-01 - This was introduced in RFC8737 as an alternate mechanism for Domain Validation. It validates the domain using a TLS handshake, which makes it a little better than HTTP-01 (as it's agnostic to the application protocol) but it mandates that this handshake be performed against port 443 on the SBC. This would of course make the SBC vulnerable to discovery through port scanning on the public internet. Additionally, support from Public CA's is very limited. It appears that LetsEncrypt support it, but doesn't look like other major CA's like DigiCert, Sectigo etc do (yet).
The other option could be to mandate the use of a different certificate management protocol, such as CMPv2, that doesn't use this Domain Validation mechanism (as that's being handled out of band in the spec anyway).
Please let me know if you want to discuss in a call.
Regards,
Chris
------------------------------
-
Chris Telford
Solutions Architect
Oracle Communications
chris.telford@oracle.com+44.207.562.5645
------------------------------
Original Message:
Sent: 06-18-2026 11:09:33 AM
From: Pierce Gorman
Subject: IPNNI-2026-00076R000.docx uploaded
Thank you Chris. Your feedback is helpful. If you'd like to have a meeting or send me more details on the concerns, I'm happy to collaborate.
CAUTION: This email has originated outside of Numeracle. Please do not click on any links or open any attachments unless you can confirm the sender and you know the content is safe.
Hi there, We have some pretty serious concerns around the proposal to use ACME to automate certificates used to encrypt SIP connections, as... -posted to the "ATIS/SIP Forum IP-NNI Task Force" community
| | Re: IPNNI-2026-00076R000.docx uploaded | | | | | | Hi there, We have some pretty serious concerns around the proposal to use ACME to automate certificates used to encrypt SIP connections, as there are questions around the Domain Validation mechanism within ACME that have not been addressed in this draft. While the use of ACME for STIR/SHAKEN communications makes sense (as this is done over HTTPS), ACME was not designed for use with non-HTTPS protocols, and the Domain Validation options available within the standard each present their own unique challenges to the SIP stack implementing them. If this is not the appropriate method for raising these concerns, please direct me to how we can discuss this. Regards, Chris | | | Reply to Group Online View Thread Recommend Forward | |
Original Message:
Sent: 05-27-2026 05:01:04 PM
From: Pierce Gorman
Subject: IPNNI-2026-00076R000.docx uploaded
Submitter's message
Contribution for Section 4.3.1 "AVSP TLS Certificates" of ALIII Requirement Standard
Also added two entries relevant to the contribution in Section 3.1 "Definitions":
* ALIII Authorization Token (AAT)
* Approved Voice Service Provider
-- Pierce Gorman
| Document Name: IPNNI-2026-00076R000.docx
Description
Contribution for Section 4.3.1 "AVSP TLS Certificates" of ALIII Requirement
Standard
Also added two entries relevant to the contribution in Section 3.1
"Definitions":
* ALIII Authorization Token (AAT)
* Approved Voice Service Providers
Download Latest Revision
Public Download Link
Submitter: Pierce Gorman
Group: ATIS/SIP Forum IP-NNI Task Force
Folder: 2026
Date submitted: 2026-05-27 21:01:04 | | |
| |