Skip to content
This repository has been archived by the owner on Apr 24, 2020. It is now read-only.

Commit

Permalink
Remove autorenewal (#67)
Browse files Browse the repository at this point in the history
For discussion. Fixes #62.
  • Loading branch information
hlandau authored and bifurcation committed May 27, 2016
1 parent d39a731 commit 56534f4
Showing 1 changed file with 8 additions and 31 deletions.
39 changes: 8 additions & 31 deletions draft-ietf-acme-acme.md
Original file line number Diff line number Diff line change
Expand Up @@ -1273,10 +1273,6 @@ with relation "up" to provide a certificate under which this certificate was
issued, and one with relation "author" to indicate the registration under which
this certificate was issued.

The server MAY include an Expires header as a hint to the client about when to
renew the certificate. (Of course, the real expiration of the certificate is
controlled by the notAfter time in the certificate itself.)

If the CA participates in Certificate Transparency (CT) {{RFC6962}}, then they
may want to provide the client with a Signed Certificate Timestamp (SCT) that
can be used to prove that a certificate was submitted to a CT log. An SCT can
Expand All @@ -1298,37 +1294,18 @@ Link: <https://example.com/acme/reg/asdf>;rel="author"
Link: <https://example.com/acme/sct/asdf>;rel="ct-sct"
Link: <https://example.com/acme/some-directory>;rel="directory"
Location: https://example.com/acme/cert/asdf
Content-Location: https://example.com/acme/cert-seq/12345

[DER-encoded certificate]
~~~~~~~~~~

A certificate resource always represents the most recent certificate issued for
the name/key binding expressed in the CSR. If the CA allows a certificate to be
renewed, then it publishes renewed versions of the certificate through the same
certificate URI.

Clients retrieve renewed versions of the certificate using a GET query to the
certificate URI, which the server should then return in a 200 (OK) response.
The server SHOULD provide a stable URI for each specific certificate in the
Content-Location header field, as shown above. Requests to stable certificate
URIs MUST always result in the same certificate.

To avoid unnecessary renewals, the CA may choose not to issue a renewed
certificate until it receives such a request (if it even allows renewal at all).
In such cases, if the CA requires some time to generate the new certificate, the
CA MUST return a 202 (Accepted) response, with a Retry-After header field that
indicates when the new certificate will be available. The CA MAY include the
current (non-renewed) certificate as the body of the response.

Likewise, in order to prevent unnecessary renewal due to queries by parties
other than the account key holder, certificate URIs should be structured as
capability URLs {{W3C.WD-capability-urls-20140218}}.

From the client's perspective, there is no difference between a certificate URI
that allows renewal and one that does not. If the client wishes to obtain a
renewed certificate, and a GET request to the certificate URI does not yield
one, then the client may initiate a new-certificate transaction to request one.
A certificate resource represents a single, immutable certificate. If the client
wishes to obtain a renewed certificate, the client initiates a new-certificate
transaction to request one.

Because certificate resources are immutable once issuance is complete, the
server MAY enable the caching of the resource by adding Expires and
Cache-Control headers specifying a point in time in the distant future. These
headers have no relation to the certificate's period of validity.

## Certificate Revocation

Expand Down

0 comments on commit 56534f4

Please sign in to comment.