Re: [Acme] ACME email validation

Alexey Melnikov <> Fri, 26 June 2020 09:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 99A133A11DB for <>; Fri, 26 Jun 2020 02:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7LC-iZU8oD-N for <>; Fri, 26 Jun 2020 02:31:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7F2403A121A for <>; Fri, 26 Jun 2020 02:31:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1593163903;; s=june2016;; bh=oQ31RXVtf4PR2tsCMRx/mwrc4Tse1+Wjg4Gh7EUN1Po=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=M6KNcLYyGJkajS722icsnO2Snk8V1pjeKIzs4aJazTrnd6O6owOyeNFYFWLsV+SXCkUYq9 LGKt13/fDnKAH8QhVicRaJ7SiiTWvBwfstPy7YrrdiaLJS70SL5m3hyRjXfLwxxhVM7mFd p45jhzEf7ODJVPGfAGUiuP0viohdGPM=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Fri, 26 Jun 2020 10:31:43 +0100
To: Brian Sipos <>, Sebastian Nielsen <>, "" <>
References: <>
From: Alexey Melnikov <>
Message-ID: <>
Date: Fri, 26 Jun 2020 10:31:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------FAE49B51849999070A1643AF"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [Acme] ACME email validation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Jun 2020 09:31:47 -0000

Hi Brian,

On 19/06/2020 23:08, Brian Sipos wrote:
> Sebastian,
> Thank you very much for this clarification. This would apply to all 
> message exchange validation types then (including the one I'm looking 
> into).
> I notice that the email validation draft does not mention multiple 
> attempts from different sources, which RFC8555 does discuss briefly 
> [1]. Is there an expectation that an email validation would be 
> attempted from multiple ACME server addresses,

If you meant "ACME server IP addresses", then the answer is "yes". 
Section 10.2 text of RFC 8555 applies to the HTTP portion of validation.

If you asking whether it is a good idea for ACME server to use different 
SMTP submission servers when sending ACME challenges, then again this is 
a good idea. But because of how many email systems are configured, there 
is typically a single point in originating network where all traffic can 
be MITMed.

If you meant "ACME server email addresses", then the answer is "no". 
Even though this is not prohibited.

> or is a MITM attack on messaging not handled because of the nature of 
> email security?

Right. Although use of MTA-to-MTA TLS is becoming a new norm, which 
helps a bit.

Best Regards,


> [1] 
> <>
> ------------------------------------------------------------------------
> *From:* Sebastian Nielsen
> *Sent:* Friday, June 19, 2020 13:25
> *To:* Brian Sipos;
> *Cc:*
> *Subject:* SV: [Acme] ACME email validation
> The reason is to prevent email spoofing.
> In the case of .well-known or DNS validation, or ALPN, you publish a 
> record where ACME fetches. That can’t be spoofed, because ACME itself 
> searches for the record, you can’t send ACME a record and have it accept.
> In the email case, you instead send ACME the response back via email, 
> which could be spoofed, if you had access to only the ACME client, if 
> whole the token was given by ACME client.
> And in the second case, if whole token was given by email, it could be 
> a private key that is being used for another thing – lets say signing 
> internal certificates via HSM, where the signing system is misused to 
> gain SMIME certificates by signing the token, without having access to 
> the corresponding ACME client where the private key is installed. By 
> requiring 2 parts of a token, you ensure the client has access to BOTH 
> the email inbox AND the ACME client, AND the private key aswell.
> To ensure that the person replying to the email BOTH have access to 
> the email account AND the ACME client, he must join 2 parts of a 
> secure token, and then use his private key to calculate the value.
> *Från:* <> *För *Brian Sipos
> *Skickat:* den 19 juni 2020 00:13
> *Till:*
> *Kopia:*
> *Ämne:* [Acme] ACME email validation
> All,
> In a recent draft I created for using ACME for non-web-PKI 
> verification [1] I see that there are many similarities with an 
> earlier draft for email verification [2]. In that email protocol, the 
> challenge token is split into two parts which arrive at the email 
> validation agent through two paths: token-part1 via the validation 
> channel, and token-part2 via the ACME channel.
> Is there a technical reason why the token is split into two parts like 
> this? Is replying with the proper corresponding Key Authorization not 
> sufficient to prove ownership of the email address?
> I don't see any similar challenge token splitting in other ACME drafts 
> and I don't see anything obvious in [2] to indicate why the split is 
> useful or needed. I also didn't see any related discussion earlier on 
> the ACME mailing list.
> Thank you,
> Brian S.
> [1]
> [2]