ACME must include certificate acceptance step

[bdaehlie]

Section 4.5.1 of our CPS, which cannot be changed, states:

"Upon Issuance of a Certificate naming the Applicant/Subscriber as the holder of the Certificate,
reviews the Certificate to ensure that all information included in it is accurate, and to expressly
indicate Acceptance or rejection of the Certificate;"

This can be an automated review by a client, but we must enforce via ACME that clients expressly indicates acceptance or rejection. If a client rejects, or does not explicitly accept, then the certificate must be revoked.

[jsha]

Do we have a period of time after which the certificate must be revoked if not explicitly accepted? Minutes, hours, days?

[bdaehlie]

I don't think a particular amount of time is mandated, maybe we should just revoke when the TCP connection from the client terminates, or after some length of time, whichever is sooner.

[jsha]

The easiest thing to do is a batch process that looks for all unconfirmed certificates older than a certain amount, say an hour, and revokes them. I can make the necessary changes.

[bdaehlie]

I like easy.

[jsha]

In the latest version of our CPS, https://letsencrypt.org/ISRG-CPS-Draft-May-5-2015.pdf, this is now section 5.5.1:

5.5.1 Subscriber Private Key and Certificate Usage
Upon Issuance of a Certificate naming the Applicant/Subscriber as the holder of the Certificate,
reviews the Certificate to ensure that all information included in it is accurate, and to expressly
indicate Acceptance or rejection of the Certificate;

But above that we have:

5.4.1 Conduct Constituting Certificate Acceptance
The following conduct constitutes certificate acceptance:
• Downloading a Certificate or installing a Certificate from a message attaching it; or
• Failure of the Subscriber to object to the Certificate or its content.
By Accepting a DV-SSL Certificate or Administrative Certificate, the Applicant/Subscriber warrants that all of the information provided by it and included in the Certificate, and all representations made by the Applicant as part of the application and I&A process, are true and not misleading.

These seem to be in conflict. If 5.4.1 trumps, we don't need to modify the protocol, since we can rely on 'Failure of the Subscriber to object to the Certificate or its content.' But I'm guessing 5.5.1 trumps based on past conversations, so we should probably fix 5.5.1.

[approachings]

Section 5.4.1 defines "certificate acceptance" with a clause trusting the Applicant/Subscriber to pre-
validate their information and confirm by non-response.

"Downloading a Certificate or installing a Certificate from a message attaching it; or non-objection"

It would follow that any further mention of acceptance should hold to this definition unless further defined.

Section 5.5.1 as such refers to "Acceptance" with the in-place definition inclusive of non-objection. The Applicant/Subscriber should be presented with an opportunity to object. Foregoing objection, whether at the close of a connection or time period, constitutes acceptance.

[diafygi]

Couldn't this be solved by returning a "receipt" json body with the 201 Created response from POST /new-cert that contains the summary information for the cert? The response already contains a Location: ... header, so the user could review the "receipt", then go download the certificate at the Location: ... endpoint if they like the receipt.

Example:

POST /acme/new-cert HTTP/1.1
{
  "csr": "5jNudRx6Ye4HzKEqT5...FS6aKdZeGsysoCo4H9P",
}
/* Signed as JWS */

HTTP/1.1 201 Created
Content-Type: application/json
Location: https://example.com/acme/cert/asdf

{
  "certSerial": "asdf",
  "certSubject": "CN=example.com",
  "certSubjectAltNames": ["DNS www.example.com", "DNS example.com"],
  "issuerSubject": "OU=Let's Encrypt",
  "issuerSerial": "123123",
  "issuerLink": "https://example.com/acme/ca-cert",
  "notAfter": "2016-01-01...",
  "notBefore": "2015-01-01...",
}

Then, if you like what you see, you can download the cert.

GET /acme/cert/asdf HTTP/1.1

HTTP/1.1 200 OK
Content-Type: application/pkix-cert
Link: <https://example.com/acme/ca-cert>;rel="up";title="issuer"

[DER-encoded certificate]

Dunno if there's a standard way to display a certificate in json, so I just threw something together for a receipt that would meet the requirements for an adequate "review".

[jsha]

We've confirmed that, based on our CPS, we don't actually need to do this. Yay!