<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 2, 2018 at 11:11 AM, Phillip <span dir="ltr"><<a href="mailto:philliph@comodo.com" target="_blank">philliph@comodo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_5337851204740303527WordSection1"><p class="MsoNormal">??? I think it is fairly clear that with the necessary privs, I can request a TCP/IP socket on any port (other than 0) and then bind a TLS provider to it.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">The point I am making is that the fact the subscriber might use the certificate on port 8443 or for that matter on any port in the range [1,65535] does not mean that the validation process should allow other ports.</p></div></div></blockquote><div><br></div><div>It sounds like we're in violent agreement here, which is why we have an authorized ports list.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_5337851204740303527WordSection1"><p class="MsoNormal">I currently have >40 TCP/IP sockets open on this Windows box and two thirds of them have https on them. And that is just my development environment. I suspect most of them are due to Docker or the Linux VMs.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">More importantly though, how many validation approaches do we need? I would rather work on reducing them rather than increasing them further.</p></div></div></blockquote><div><br></div><div>And 64KB should be enough for everybody, no one will need more than one monitor, XGA is plenty resolution, etc.</div><div><br></div><div>I would not obsess about the number of validation methods, I would rather us focus on ensuring a consistent level of assurance, and then work to help ensure that anyone and everyone on the Web can easily get a certificate and facilitate greater adoption of encryption.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_5337851204740303527WordSection1"><p class="MsoNormal"><u></u></p><p class="MsoNormal">In particular, I would like CAA to become a one stop shop for telling CAs what they need to issue a cert. For example:</p></div></div></blockquote><div><br></div><div>OK, at least it's easier to know where we disagree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_5337851204740303527WordSection1"><p class="MsoNormal"><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><a href="http://example.com" target="_blank">example.com</a>.   IN          CAA       0 issue "<a href="http://comodoca.com" target="_blank">comodoca.com</a>"<u></u><u></u></p><p class="MsoNormal"><a href="http://example.com" target="_blank">example.com</a>.   IN          CAA       128 udf "MDTXA-Y7DQJ-P7IRF-XUCRE-<wbr>2Y5TH-RVNHP"<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">The above record would prevent a CA from issuing a cert unless they understand the semantics of the UDF record. So this is the only validation approach permitted.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">The UDF record requires that any cert request be signed or countersigned according to a security policy that has the UDF fingerprint "MDTXA-Y7DQJ-P7IRF-XUCRE-<wbr>2Y5TH-RVNHP"<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">These are described here.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><a href="https://tools.ietf.org/html/draft-hallambaker-udf-08" target="_blank">https://tools.ietf.org/html/<wbr>draft-hallambaker-udf-08</a><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal" style="margin-left:.5in"><b>From:</b> Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>] <br><b>Sent:</b> Friday, March 2, 2018 10:52 AM<br><b>To:</b> Phillip <<a href="mailto:philliph@comodo.com" target="_blank">philliph@comodo.com</a>>; CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Cc:</b> Paul Hoffman <<a href="mailto:paul.hoffman@icann.org" target="_blank">paul.hoffman@icann.org</a>>; Ben Wilson <<a href="mailto:ben.wilson@digicert.com" target="_blank">ben.wilson@digicert.com</a>></p><div><div class="h5"><br><b>Subject:</b> Re: [cabfpub] [Ext] BR Authorized Ports, add 8443<u></u><u></u></div></div><p></p><div><div class="h5"><p class="MsoNormal" style="margin-left:.5in"><u></u> <u></u></p><div><p class="MsoNormal" style="margin-left:.5in"><u></u> <u></u></p><div><p class="MsoNormal" style="margin-left:.5in"><u></u> <u></u></p><div><p class="MsoNormal" style="margin-left:.5in">On Fri, Mar 2, 2018 at 10:35 AM, Phillip via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal" style="margin-left:.5in">To clarify what Paul said,<br><br>We need to distinguish between the use of a port for certificate validation<br>and the use of a port for delivery of an Internet service. The fact that we<br>use SSL on every port to provide a service does not mean that we should<br>allow that use for validation.<u></u><u></u></p></blockquote><div><p class="MsoNormal" style="margin-left:.5in"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin-left:.5in">On what basis do you make this claim? I see no justification for the distinction, nor support for the 'fact'.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:.5in"> <u></u><u></u></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"><p class="MsoNormal" style="margin-left:.5in">I do think we should consider adding a DNS prefix for certificate validation<br>though because ports are the old way to advertise services and does not<br>scale. We ran out of ports a long time ago and now use DNS prefixes and<br>.well-known HTTP services to extend the port numbers.<br><br><br><span class="m_5337851204740303527im">-----Original Message-----</span><br><span class="m_5337851204740303527im">From: Public [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@<wbr>cabforum.org</a>] On Behalf Of Paul Hoffman</span><br><span class="m_5337851204740303527im">via Public</span><br><span class="m_5337851204740303527im">Sent: Friday, March 2, 2018 10:08 AM</span><br><span class="m_5337851204740303527im">To: Ben Wilson <<a href="mailto:ben.wilson@digicert.com" target="_blank">ben.wilson@digicert.com</a>>; CA/Browser Forum Public Discussion</span><br><span class="m_5337851204740303527im">List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span><u></u><u></u></p><div><div><p class="MsoNormal" style="margin-left:.5in">Subject: Re: [cabfpub] [Ext] BR Authorized Ports, add 8443<br><br>On Mar 1, 2018, at 7:51 AM, Ben Wilson via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br>wrote:<br>><br>> Forwarding from Richard Wang:<br>><br>> The current BRs say:<br>><br>> Authorized Ports: One of the following ports: 80 (http), 443 (http), 25<br>(smtp), 22 (ssh).<br>><br>> But many internal networks use the port 8443, broadly used in Apache<br>server, today, one of our customers uses this port and can't change to use<br>another port, I wish you can help to add this port 8443 to be allowed in the<br>BRs, thanks.<br><br>It appears that the BRs currently are talking about authorizing *services*,<br>not ports. That is, I would not expect to be able to put a HTTP server on<br>port 22 on my system and have that considered authorized by the BRs.<br><br>Any Internet service can be run on any port. Every web, SMTP, and SSH server<br>software configuration allows you to run on the standard ports or any port<br>you choose.<br><br>Two suggestions:<br><br>- Clarify the BRs to say "Authorized Services and Ports"<br><br>- Add text that says only the authorized ports may be used<br><br>If CABF folks want to allow issuance of certificates for services on ports<br>other than the standard ports, you will have to decide what it means to<br>initially offer a service on one part and then move it to another port. The<br>PKIX standard does not allow encoding of port numbers for services in<br>certificates.<br><br>--Paul Hoffman<br>______________________________<wbr>_________________<br>Public mailing list<br><a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br><br>______________________________<wbr>_________________<br>Public mailing list<br><a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><u></u><u></u></p></div></div></blockquote></div><p class="MsoNormal" style="margin-left:.5in"><u></u> <u></u></p></div></div></div></div></div></div></blockquote></div><br></div></div>