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

From: "Reimer Karlsen-Masur, DFN-CERT" <[email-masked]>
Date: Mon, 13 Jul 2015 12:39:35 +0200

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.

Any insight is much appreciated, thanks,

Reimer

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Jul 2015 09:19:06 -0700

> seems out of band to the ACME protocol and I'd like to avoid OoB
​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.

​
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
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?  That's going to get complicated pretty fast, honestly, so I'm not
sure it would be in scope.

regards,

Ted

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: "Reimer Karlsen-Masur, DFN-CERT" <[email-masked]>
Date: Wed, 15 Jul 2015 10:50:36 +0200

>       required to keep the server functional and its credentials up-to-

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.
 ​
> 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).

> Can you unpack your concern a bit?
>
> Do you need this to work before the
> 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