Subject: [Acme] Perspective on validation

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 6 Dec 2015 10:23:00 -0500

The discussion on validation on different ports suggests that we have the
wrong understanding of what validation is for.

All that is required to validate a certificate holder under the Basic
Requirements is to prove they have control over a domain. This is also the
minimum required.

The port number is irrelevant, either you have control or you don't.

This is even more important when you try to extend ACME to email. Because
then you end up with a hierarchy.

The domain name holder for example.com controls [email-masked],
[email-masked], etc. and so they can get a cert for any of them. But Alice
does not control example.com but she does control [email-masked].

So the domain name holder may be able to get an intermediate CA with
constraints to issue only client certs for [email-masked] using DV
validation. Alice, an account holder can only validate for [email-masked]
and can only get an EE cert.

We seem to keep re-opening discussions on this topic as new people join in.

ACME validation is also necessarily constrained to issue for public CAs.
the problem is very different if you are doing a private, internal CA. You
can get much stronger validation, much more easily because you control the
horizontal and the vertical.

ACME is developing a certificate validation and provisioning protocol for
an infrastructure that was originally designed 25 years ago. The basic
principles of the WebPKI were established and fixed in deployed code in
1995. Trying to redefine how that system works twenty years later without a
major requirement driving the change is futile.

X.509 is not tied to a particular layer in the stack. But the WebPKI is
tied to the application layer. Strictly speaking it was conceived as being
the interface between layer 7 and 8. The interface between the Internet and
the 'real' world back in the days before the Internet was the real world.
Port numbers are a transport layer concept.