Re: [Acme] Sending documents or arbitrary files via ACME from server to client?

"Reimer Karlsen-Masur, DFN-CERT" <karlsen-masur@dfn-cert.de> Wed, 15 July 2015 08:50 UTC

Return-Path: <karlsen-masur@dfn-cert.de>
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 239A71A8938 for <acme@ietfa.amsl.com>; Wed, 15 Jul 2015 01:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.339
X-Spam-Level:
X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 Riw5fYhVgy_o for <acme@ietfa.amsl.com>; Wed, 15 Jul 2015 01:50:45 -0700 (PDT)
Received: from mail1.dfn-cert.de (mail1.dfn-cert.de [IPv6:2001:638:714:2811:5::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855E31A893A for <acme@ietf.org>; Wed, 15 Jul 2015 01:50:39 -0700 (PDT)
Message-ID: <55A61EDC.4030706@dfn-cert.de>
Date: Wed, 15 Jul 2015 10:50:36 +0200
From: "Reimer Karlsen-Masur, DFN-CERT" <karlsen-masur@dfn-cert.de>
MIME-Version: 1.0
To: Ted Hardie <ted.ietf@gmail.com>
References: <55A39567.7030602@dfn-cert.de> <CA+9kkMCtBwcACE_jusOuY5C7HSi+8VOJxNOF6f4tqm0B3_NnnQ@mail.gmail.com>
In-Reply-To: <CA+9kkMCtBwcACE_jusOuY5C7HSi+8VOJxNOF6f4tqm0B3_NnnQ@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030203020705000503040300"
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/_SCVv4GGFh0BKwRYPEImg-DYEVY>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] Sending documents or arbitrary files via ACME from server to client?
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: Wed, 15 Jul 2015 08:50:47 -0000

Ted Hardie wrote on 13.07.2015 18:19:
> On Mon, Jul 13, 2015 at 3:39 AM, Reimer Karlsen-Masur, DFN-CERT <
> karlsen-masur@dfn-cert.de> wrote:
> 
>> Hi,
>>
>> I read the latest draft-barnes-acme-03.txt and have a question:
>>
>> Is there an option for the ACME server to "send" or provide the ACME client
>> a file, e.g. a PDF document that contains an invoice, contract, form etc. I
>> think this is not possible with the current draft ACME spec but I want to
>> be
>> sure that I have not overseen that option.
>>
>>
> I understand that the ACME server could email such a file/document to the
>> email address that is associated with the registration object, but that
>> seems out of band to the ACME protocol and I'd like to avoid OoB
>> communication.
>>
>>
> ​The document currently has this text:
> 
>       The ACME client periodically contacts the CA to get updated
>       certificates, stapled OCSP responses, or whatever else would be
>       required to keep the server functional and its credentials up-to-
>       date.

Other than in the quote above I did not find the spot in the draft where
"stapled OCSP responses, or whatever else would be required to keep the
server functional and its credentials up-to-date" are send or pulled.
 ​
> I suppose a bill or contract could fall under this rubric.  That's a
> pull-based, rather than push-based mechanism, though, and I'm not sure what

I assume it could be the "agreement" string in a "registration object" with
an URI/URL to download the subscriber agreement (T&Cs).

> your actual requirements are, as the email mechanism looks to me like it
> should work unless the client loses access to the email address (which
> obviously has other problems).
> 
> Can you unpack your concern a bit?
>
> Do you need this to work before the
> cert is issued so that receipt of payment is required before issuance, for
> example?

I'd like the client to be able to get/pull the subscriber agreement (well
that is at least mentioned in the registration object), a bill and or
payment receipt and a contract (application form) per certificate directly
from the ACME server.

If those documents are sent out of band by email, it leaves room for fake
bills/contracts etc, since some bad party could just email faked docs with
false data to arbitrary server admin mail adresses and try to get the money,
or get an application form signed and returned. Server admins may not expect
*and* validate S/MIME and/or PDF signatures under these kinds of docs when
they arrive by email, so the server admin may have difficulties to detect
fake/fraud docs.

If any of those admins who did get certs via an ACME workflow fall for this
scam, the damage is done.

Thanks for further comments,

Reimer