Subject: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL

From: Logan Widick <[email-masked]>
Date: Thu, 30 Nov 2017 14:58:18 -0600

In the new finalizeURL approach to orders, do order objects need to contain
a CSR after a user attempted to finalize the order, or after the order is
finalized? Would the CA have to store the CSR after it's posted, or after
the certificate is issued?

>From the text, I assume that the body of the finalizeURL is a POST
containing an ACME JWS message whose payload is a JSON object with the
"csr" field. Is that correct? What would this POST look like?

I'm asking these questions because I haven't been able to find an example
of the finalizeURL POST in the draft (
https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md),
and because I see "csr" fields in some of the order objects.

I've created a branch of my fork of the GitHub repository (
https://github.com/uhhhh2/acme/tree/remove-csr-fields-from-order-and-add-example-finalize-post)
with my understanding of the new finalizeURL POST. Specifically, in this
branch, I am assuming that the CSR is not stored as part of the order. I am
also assuming that the finalizeURL POST is an ACME JWS message whose
payload is a JSON object with the "csr" field (which is in the same
base64url format it was in before finalizeURL was introduced). Am I
understanding the finalizeURL correctly?

Sincerely,

Logan Widick

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 30 Nov 2017 13:01:56 -0800

On 11/30/2017 12:58 PM, Logan Widick wrote:
> In the new finalizeURL approach to orders, do order objects need to
> contain a CSR after a user attempted to finalize the order, or after
> the order is finalized? Would the CA have to store the CSR after it's
> posted, or after the certificate is issued?
Good question. Previously, we expected that the CA had to store the CSR
because it would need the public key in order to issue. With
finalizeURL, we can get rid of that requirement. CAs are required to
record CSRs in their audit logs, but there is no formal requirement to
keep them in an online database. So my preference would be to remove the
"csr" field from order objects, since it doesn't serve any purpose.

Other thoughts?

---

From: Daniel McCarney <[email-masked]>
Date: Thu, 30 Nov 2017 17:25:45 -0500

>
>  So my preference would be to remove the "csr" field from order objects,
> since it doesn't serve any purpose.

I agree. I don't think it makes sense to echo it back to the client that
sent it. +1 to removing.

On Thu, Nov 30, 2017 at 4:01 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 Nov 2017 17:34:20 -0500

I would like to keep it around.  Part of the idea of the order and
authorization objects is to provide some possibility of accounting for how
a certificate was issued.  Removing the "csr" would remove some of that
transparency.

As Jacob points out, CAs are already required to keep around CSRs in audit
logs.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 30 Nov 2017 14:43:36 -0800

On 11/30/2017 02:34 PM, Richard Barnes wrote:
> As Jacob points out, CAs are already required to keep around CSRs in
> audit logs.

You missed an important nuance: CAs are not required to keep around CSRs
in an online database for live querying on the web. It is much more
expensive to store a CSR in a performant database than a rarely-accessed
log.

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 30 Nov 2017 22:53:39 +0000

My recollection from various CA/Browser discussions is that CAs are *not*
actually required to keep around CSRs.  Am I wrong?

Most CAs do, because it is the easiest way to log proof of possession of the
private key, and because it is useful for a variety of other auditing
activities, but other methods are possible, in principle.

In fact, I'm struggling to even find that requirement --- 3.2.1 is empty in
the latest copy of the BRs.  CSRs are only mentioned in an obscure footnote
about potential methods for calculating Request Tokens.

-Tim

-----Original Message-----
From: Acme [mailto:[email-masked]] On Behalf Of Jacob Hoffman-Andrews
Sent: Thursday, November 30, 2017 3:44 PM
To: Richard Barnes <[email-masked]>; Daniel McCarney <[email-masked]>
Cc: Logan Widick <[email-masked]>; ACME WG <[email-masked]>
Subject: Re: [Acme] Question about the new finalizeURL approach, and the
order object format after finalizeURL

> As Jacob points out, CAs are already required to keep around CSRs in 

You missed an important nuance: CAs are not required to keep around CSRs in
an online database for live querying on the web. It is much more expensive
to store a CSR in a performant database than a rarely-accessed log.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 30 Nov 2017 14:58:18 -0800

> actually required to keep around CSRs.  Am I wrong?
I may be misremembering. I thought they were required to log proof of
the subscriber's possession of the private key, but you're right that
3.2.1 is empty. So, even more reason to not make this required!