Re: [Acme] Last Call: <draft-ietf-acme-email-smime-08.txt> (Extensions to Automatic Certificate Mana

Sebastian Nielsen <sebastian@sebbe.eu> Thu, 25 June 2020 21:41 UTC

Return-Path: <sebastian@sebbe.eu>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A843A1032; Thu, 25 Jun 2020 14:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sebbe.eu
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 20PbXYrKGS50; Thu, 25 Jun 2020 14:41:19 -0700 (PDT)
Received: from dns2.sebbe.eu (dns2.sebbe.eu [IPv6:2001:470:dff1:1:10::2]) (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 1336F3A1031; Thu, 25 Jun 2020 14:41:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sebbe.eu; s=root; h=Date:Cc:To:From; bh=mJtcczac88s2VqQBcHnsXYXcSPOtttQK6uFhI5KW8Gk=; b=ldWz3UjnWBzhbb957Y5w2eiFQ9mvzgMFwk2YjHn3aDVUoOk3geUow5OmnDcRZA2ZA7n5+OadjP UwxbInIpuL+9K+tWY1/G0S/HJOgg0x3cP7Qf6Hbh6Hhqn03S4fOfgSF1jy2Q1OGi4CR9ojoLBDzj4 Di8ClKfdP579d8LYpkKI=;
Received: from localhost ([127.0.0.1] helo=sebastian-desktop) by sebbe.eu with esmtp (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from <sebastian@sebbe.eu>) id 1joZbv-001yqz-Lc; Thu, 25 Jun 2020 23:40:43 +0200
Received: from [192.168.4.100] (helo=DESKTOPVB5MBIV) by sebbe.eu with esmtpa (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from <sebastian@sebbe.eu>) id 1joZbv-001yqw-6g; Thu, 25 Jun 2020 23:40:43 +0200
From: Sebastian Nielsen <sebastian@sebbe.eu>
To: 'S Moonesamy' <sm+ietf@elandsys.com>, 'Alexey Melnikov' <alexey.melnikov@isode.com>
Cc: rdd@cert.org, acme@ietf.org, draft-ietf-acme-email-smime@ietf.org, acme-chairs@ietf.org
Message-ID: <005801d64b39$472da0c0$d588e240$@sebbe.eu>
In-Reply-To: <6.2.5.6.2.20200625123422.0ee35bb8@elandnews.com>
References: <159311144759.26518.18413097757444174694@ietfa.amsl.com> <6.2.5.6.2.20200625123422.0ee35bb8@elandnews.com>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----=_Part_174_1259991985.1593121243617"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQI0erMzUvcq7Qc4yWdGHDhNyGTkygFTPcP7qCLg/MA=
X-Encryption-Target: external
Date: Thu, 25 Jun 2020 23:40:43 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/F02OMpEKhzIgK-cVPtBjUguQbcw>
Subject: Re: [Acme] Last Call: <draft-ietf-acme-email-smime-08.txt> (Extensions to Automatic Certificate Mana
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 25 Jun 2020 21:41:22 -0000

1: Of course DKIM can be used to validate the authenticity of the email such
as it has been sent from the specified domain.

2: Validation response messages should NOT be forwarded! Normally, you would
send a response message like from sebastian@sebbe.eu to
certvalidate@ca.example.org
Of course, if ca.example.org is in full control of all email servers, they
can easily do the validation at the leaf server ca.example.org, and then
forward the email message to a internal server for SMIME issuance, for
example by adding a encrypted and signed header with the validation, or
communicating out-of-band - for example with a MySQL server, that the
message X is propely SPF and DKIM validated.

The type of forwarding SPF don't work with, would be if
certvalidate@ca.example.org was forwarded to lets say
suspicious.ca@gmail.com then if I send a validation reponse to
certvalidate@ca.example.org from sebastian@sebbe.eu , validation would fail
@ GMAIL when they receive the message from ca.example.org which is a server
not on my authorization list.

And a CA running an email server that forwards to an server they are not in
full control of, is a HUGE security risk for SMIME issuance - unless they
have proper agreements in place - for example a subCA that forwards their
validations to the main CA, but still want a "branded" email adress for
their ACME validations - but then their agreements could easily include that
the subCA should do the validations at the leaf server, and then add
information to the email that allows the main CA to see that SPF and DKIM
was propely validated.
Or include the client IP in the message, signed securely, so the main CA can
validate SPF.

-----Ursprungligt meddelande-----
Från: acme-bounces@ietf.org <acme-bounces@ietf.org> För S Moonesamy
Skickat: den 25 juni 2020 21:59
Till: Alexey Melnikov <alexey.melnikov@isode.com>
Kopia: rdd@cert.org; acme@ietf.org; draft-ietf-acme-email-smime@ietf.org;
acme-chairs@ietf.org
Ämne: Re: [Acme] Last Call: <draft-ietf-acme-email-smime-08.txt> (Extensions
to Automatic Certificate Mana

Hi Alexey,
At 11:57 AM 25-06-2020, The IESG wrote:
>The IESG has received a request from the Automated Certificate 
>Management Environment WG (acme) to consider the following document: - 
>'Extensions to Automatic Certificate Management Environment for end
>    user S/MIME certificates'
>   <draft-ietf-acme-email-smime-08.txt> as Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits 
>final comments on this action. Please send substantive comments to the

In Section 3.1, there is the following in Point 3 and 5: "The message MAY
contain Reply-To header field."  Is the duplication a mistake?

Point 6 states that its purpose is to "prove authenticity of a challenge
message".  How does DKIM prove authenticity [1]?

Why is there a requirement that the message has to pass DMARC validation?
Has forwarding been taken into account [2]?

Regards,
S. Moonesamy

1. Please see Section 5.4 of RFC 6376.
2. That does not work well with SPF. 

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme