[Acme] Perspective on validation

Phillip Hallam-Baker <phill@hallambaker.com> Sun, 06 December 2015 15:23 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2B85C1A9172 for <acme@ietfa.amsl.com>; Sun, 6 Dec 2015 07:23:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wwXWZB7F1dGW for <acme@ietfa.amsl.com>; Sun, 6 Dec 2015 07:23:02 -0800 (PST)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EBD61A913F for <acme@ietf.org>; Sun, 6 Dec 2015 07:23:02 -0800 (PST)
Received: by lfdl133 with SMTP id l133so137626066lfd.2 for <acme@ietf.org>; Sun, 06 Dec 2015 07:23:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=sM0YztrUMuX6otT6E85+Hl1cvZe3VHo+GXjz3W4wPUo=; b=1HDVs913xo2sapMcrlTmijkmjSE3ATlnMmMJt6iApwSmZa49AfePKykYAr1hR/xl7f vrfH2jFZBmwYZRKSl2z2RrCibH77UwsppiuPWV5w0uLieWMhzc+WIdcasAJYINEbOONb mitcFCeCeJXaKEUmh/NJzTMn1a9PYuiq5gDWaAve6EyIG2lNUPxJ+4UteSpHfgVSIwyr KLRU06upASPGhLocjWjCz5w0YTLC4CtVlOxzZOdxait1M1Qn9XIK/jEzhyJq4f0Udg61 T8vPwWPIng2kJegHz+QHx4lDXTyPO6Vbo68Tjj2BtJfYJw03Eig2To68c5Tdiv9OqtdE wSxQ==
MIME-Version: 1.0
X-Received: by with SMTP id h197mr12159771lfg.153.1449415380335; Sun, 06 Dec 2015 07:23:00 -0800 (PST)
Sender: hallam@gmail.com
Received: by with HTTP; Sun, 6 Dec 2015 07:23:00 -0800 (PST)
Date: Sun, 6 Dec 2015 10:23:00 -0500
X-Google-Sender-Auth: vH1Tf6eDl2LZ0YfDFf7IpqTSKdE
Message-ID: <CAMm+Lwi-j7i+Xzez8TQkTbwNRKAuNsSR8aORQe9hOUYSWxeAZA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "acme@ietf.org" <acme@ietf.org>
Content-Type: multipart/alternative; boundary=001a1140118ee084b205263c5035
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/cNXuMxMGT3IuSinaVEXN0dolIm4>
Subject: [Acme] Perspective on validation
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Dec 2015 15:23:04 -0000

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 alice@example.com,
bob@example.com, etc. and so they can get a cert for any of them. But Alice
does not control example.com but she does control alice@example.com.

So the domain name holder may be able to get an intermediate CA with
constraints to issue only client certs for *@example.com using DV
validation. Alice, an account holder can only validate for alice@example.com
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.