IETF Logo Mail Archive

Re: [Acme] Issuing certificates based on Simple HTTP challenges

moparisthebest <admin@moparisthebest.com> Mon, 14 December 2015 16:58 UTC

Return-Path: <admin@moparisthebest.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AEE1ACCE4 for <acme@ietfa.amsl.com>; Mon, 14 Dec 2015 08:58:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level:
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8qwlCvhgrUU for <acme@ietfa.amsl.com>; Mon, 14 Dec 2015 08:58:57 -0800 (PST)
Received: from mailer.moparscape.org (mailer.moparscape.org [144.76.72.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66CAA1ACCE2 for <acme@ietf.org>; Mon, 14 Dec 2015 08:58:56 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at burtrum.org
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=moparisthebest.com; s=2013; t=1450112315; bh=8UPyRkKTmNvlKABlrwcY8khN7sKgUK8kVzXzBSh7B4U=; h=Subject:To:References:From:Date:In-Reply-To:From; b=XcvIQF2Ckve/DwL2iRiOHSXqCLWdigF1a3nZiuprELG1liuWl1WbnTN6LDvJ9bXp5 dM6OsPBXCIJm5hjqzgfCm47h2ZBasZQwTzmP7gMB/+1MkZz1HS+VYFEYya0YqtXUWy PJlHV6+co60bS11S85QDMQQjmoZmhYyqsRl8xbtg=
To: acme@ietf.org
References: <CAF+SmEpOLoaREymVhi=qOUg2opz1vKzzNp6tGrDTZAjYSKFDkg@mail.gmail.com> <3071e2d95eaf49acac00e91d3626ccfa@usma1ex-dag1mb1.msg.corp.akamai.com> <CAF+SmEo_s8svTgwvBPqqHyhKFKCt5e-3kSpZK2dUAqapzzORiw@mail.gmail.com>
From: moparisthebest <admin@moparisthebest.com>
Message-ID: <566EF51E.2080907@moparisthebest.com>
Date: Mon, 14 Dec 2015 11:58:06 -0500
MIME-Version: 1.0
In-Reply-To: <CAF+SmEo_s8svTgwvBPqqHyhKFKCt5e-3kSpZK2dUAqapzzORiw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/nYywhnfYRjwZ3CoAYebvU6fyypg>
Subject: Re: [Acme] Issuing certificates based on Simple HTTP challenges
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: Mon, 14 Dec 2015 16:58:58 -0000

On 12/14/2015 11:53 AM, Julian Dropmann wrote:
> 
>     >This effectively means, as a domain zone admin, I have to trust every single service I define, not just to properly deliver this service, but also not to exploit his ability to obtain signed certificates in my name.
> 
>     Yes.
> 
> 
> And you are perfectly aware, that this was not the case before
> ACME-enabled CAs existed, and now applies to every single domain admin
> on this planet, right?

It always applied before as well.  In your example, your malicious blog
hoster could have just hosted un-encrypted xmpp on the default port as
well and xmpp clients that don't support SRV (which probably don't
exist? it's in the original RFC) would just happily connect there as
well, right?

v2.23.0 | Report a Bug | By Email