On Fri, Mar 2, 2018 at 11:11 AM, Phillip <phill...@comodo.com> wrote:

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

It sounds like we're in violent agreement here, which is why we have an
authorized ports list.


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

And 64KB should be enough for everybody, no one will need more than one
monitor, XGA is plenty resolution, etc.

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.


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

OK, at least it's easier to know where we disagree.


>
>
> 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:sle...@google.com]
> *Sent:* Friday, March 2, 2018 10:52 AM
> *To:* Phillip <phill...@comodo.com>; CA/Browser Forum Public Discussion
> List <public@cabforum.org>
> *Cc:* Paul Hoffman <paul.hoff...@icann.org>; Ben Wilson <
> ben.wil...@digicert.com>
>
> *Subject:* Re: [cabfpub] [Ext] BR Authorized Ports, add 8443
>
>
>
>
>
>
>
> On Fri, Mar 2, 2018 at 10:35 AM, Phillip via Public <public@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-boun...@cabforum.org] On Behalf Of Paul
> Hoffman
> via Public
> Sent: Friday, March 2, 2018 10:08 AM
> To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public
> Discussion
> List <public@cabforum.org>
>
> Subject: Re: [cabfpub] [Ext] BR Authorized Ports, add 8443
>
> On Mar 1, 2018, at 7:51 AM, Ben Wilson via Public <public@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@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
> _______________________________________________
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Reply via email to