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