<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hey Aaron,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If there is a concern with expanding existing methods to support this, then perhaps we should create a new one specifically for this. That way we could enumerate the permitted ports (and other rules/checks) for this method without opening up existing methods to possible weaknesses. Maybe that was your intent towards the end of your email, but was not sure.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Doug<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Validation <validation-bounces@cabforum.org> <b>On Behalf Of </b>Aaron Gable via Validation<br><b>Sent:</b> Friday, October 28, 2022 12:25 PM<br><b>To:</b> Ben Wilson <bwilson@mozilla.com>; CA/Browser Forum Validation SC List <validation@cabforum.org><br><b>Subject:</b> Re: [cabf_validation] New TLS-ALPN Validation Method<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>A reply on that thread does bring up the very good point that it has (appropriately) become harder to add new validation methods such as variants on ACME's TLS-ALPN-01 because they can no longer fall under "any other method".<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>It seems like support for this at the BRs level would require two changes:<o:p></o:p></p></div><div><p class=MsoNormal>First, we'd need to expand the definition of "Authorized Port" to include any port pointed at by an SVBC, HTTPS, or other future SVBC-compatible Resource Record's "port" SvcParamKey.<o:p></o:p></p></div><div><p class=MsoNormal>Second, we'd need to expand BRs 3.2.2.4.20 (TLS Using ALPN) to not solely reference RFC 8737 (ACME TLS-ALPN-01), but instead operate more like BRs 3.2.2.4.7 (DNS Change), allowing multiple different specific implementations to comply as long as they meet certain criteria. Perhaps in this case the criteria would place limitations on the ALPN protocol negotiated, and the contents of the certificate presented in the TLS handshake.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>These are both changes that explicitly widen the scope of validation methods acceptable under the BRs, which goes against the general desire to make validation methods stricter in all ways. So they'd need to be carefully considered. But it may be worthwhile to establish a generic "TLS Using ALPN" that multiple implementations can satisfy, similar to how "DNS Change" works today.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Aaron<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Fri, Oct 28, 2022 at 1:08 AM Ben Wilson via Validation <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal>Thoughts with regard to the following?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><a href="https://mailarchive.ietf.org/arch/msg/acme/dIfbBLij_SCeXKoE47tpIVkavTs/" target="_blank">https://mailarchive.ietf.org/arch/msg/acme/dIfbBLij_SCeXKoE47tpIVkavTs/</a><o:p></o:p></p></div><div><pre>Right now, most of ACME’s validation methods can only be used by clients with IP addresses in A/AAAA records corresponding to the identifier, as well as specific open ports. This is perfectly acceptable for most use cases right now, but it becomes problematic when managing certificates for the likes of HTTP alternative services or SVBC/HTTPS targets. Such configurations require a certificate for the original identifier, but (usually) do not share the same IP addresses.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>dns-01 sidesteps this limitation, but is often less secure since it usually requires credentials for DNS zone modifications to be accessible by clients.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>I don’t think it is too early to start thinking about more practical solutions, in advance of draft-ietf-dnsop-svcb-httpssvc being finalized. Perhaps a new form of TLS-ALPN method that uses an SVBC/HTTPS record instead of 443/tcp and A/AAAA records? It would need to ignore the normal precedence rules, as they would preclude lower-priority targets from getting certificates.<o:p></o:p></pre></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>_______________________________________________<br>Validation mailing list<br><a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a><br><a href="https://lists.cabforum.org/mailman/listinfo/validation" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a><o:p></o:p></p></blockquote></div></div></body></html>