[cabfpub] [Ext] BR Authorized Ports, add 8443

Fri Mar 2 16:11:52 UTC 2018

??? 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.

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.

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.

More importantly though, how many validation approaches do we need? I would rather work on reducing them rather than increasing them further.

In particular, I would like CAA to become a one stop shop for telling CAs what they need to issue a cert. For example:

example.com.   IN          CAA       0 issue "comodoca.com"

example.com.   IN          CAA       128 udf "MDTXA-Y7DQJ-P7IRF-XUCRE-2Y5TH-RVNHP"

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.

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-2Y5TH-RVNHP"

These are described here.

https://tools.ietf.org/html/draft-hallambaker-udf-08

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Friday, March 2, 2018 10:52 AM
To: Phillip <philliph at comodo.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Paul Hoffman <paul.hoffman at icann.org>; Ben Wilson <ben.wilson at digicert.com>
Subject: Re: [cabfpub] [Ext] BR Authorized Ports, add 8443

On Fri, Mar 2, 2018 at 10:35 AM, Phillip via Public <public at cabforum.org <mailto:public at cabforum.org> > wrote:

To clarify what Paul said,

We need to distinguish between the use of a port for certificate validation
and the use of a port for delivery of an Internet service. The fact that we
use SSL on every port to provide a service does not mean that we should
allow that use for validation.

On what basis do you make this claim? I see no justification for the distinction, nor support for the 'fact'.

I do think we should consider adding a DNS prefix for certificate validation
though because ports are the old way to advertise services and does not
scale. We ran out of ports a long time ago and now use DNS prefixes and
.well-known HTTP services to extend the port numbers.

-----Original Message-----
From: Public [mailto:public-bounces at cabforum.org <mailto:public-bounces at cabforum.org> ] On Behalf Of Paul Hoffman
via Public
Sent: Friday, March 2, 2018 10:08 AM
To: Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> >; CA/Browser Forum Public Discussion
List <public at cabforum.org <mailto:public at cabforum.org> >

Subject: Re: [cabfpub] [Ext] BR Authorized Ports, add 8443

On Mar 1, 2018, at 7:51 AM, Ben Wilson via Public <public at cabforum.org <mailto:public at cabforum.org> >
wrote:
>
> Forwarding from Richard Wang:
>
> The current BRs say:
>
> Authorized Ports: One of the following ports: 80 (http), 443 (http), 25
(smtp), 22 (ssh).
>
> But many internal networks use the port 8443, broadly used in Apache
server, today, one of our customers uses this port and can't change to use
another port, I wish you can help to add this port 8443 to be allowed in the
BRs, thanks.

It appears that the BRs currently are talking about authorizing *services*,
not ports. That is, I would not expect to be able to put a HTTP server on
port 22 on my system and have that considered authorized by the BRs.

Any Internet service can be run on any port. Every web, SMTP, and SSH server
software configuration allows you to run on the standard ports or any port
you choose.

Two suggestions:

- Clarify the BRs to say "Authorized Services and Ports"

- Add text that says only the authorized ports may be used

If CABF folks want to allow issuance of certificates for services on ports
other than the standard ports, you will have to decide what it means to
initially offer a service on one part and then move it to another port. The
PKIX standard does not allow encoding of port numbers for services in
certificates.

--Paul Hoffman
_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org> 
https://cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org> 
https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180302/6973f58c/attachment-0003.html>