On Wed, Dec 2, 2015 at 10:17 AM, Richard Barnes <[email protected]> wrote: > I agree that we're converging on some rough consensus, but I would > frame it (again) slightly differently: > > 1. ACME needs to validate domain control, not domain+port control, > because (1) there is no current mechanism for issuing certificates for > domain+port (vs. just domain), and (2) the primary use cases for ACME > right now (DV certs, and possibly OV/EV) don't have any notion of > ports. >
Again, I think you are missing the real problem here. Let us say we have a new protocol to run over port 666 that is actually a Web service under the covers. Hosting provider has a host that supports the following Web Sites that belong to different parties: example.com malicious.com The hosting provider allows any form of executable to run on the host (10.6.6.6) that does not interfere with apache which has 80 & 443 reserved. [This is typical] Mallet controls malicious.com. He uploads an executable that opens a server on port 666. Applies for a cert for example.com:666 CA tries to validate example.com:666 Resolves A record for example.com -> 10.6.6.6 Makes ACME validation request to http://example.com:666/ Mallet's server can ignore the HostName: field in the HTTP interaction because it is his server. He can now get a cert for example.com:666 So the problem here is not merely that there is no such thing as a 'port bound' certificate. The problem is that there is no way to validate a cert for a single port. My objection to this validation mechanism would stand even if there was a port restriction option available in PKIX. And indeed we should have that type of capability just for reasons of least privilege.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
