< draft-ietf-acme-star-05.txt   draft-ietf-acme-star-06.txt >
ACME Working Group Y. Sheffer ACME Working Group Y. Sheffer
Internet-Draft Intuit Internet-Draft Intuit
Intended status: Standards Track D. Lopez Intended status: Standards Track D. Lopez
Expires: September 5, 2019 O. Gonzalez de Dios Expires: January 2, 2020 O. Gonzalez de Dios
A. Pastor Perales A. Pastor Perales
Telefonica I+D Telefonica I+D
T. Fossati T. Fossati
ARM ARM
March 04, 2019 July 01, 2019
Support for Short-Term, Automatically-Renewed (STAR) Certificates in Support for Short-Term, Automatically-Renewed (STAR) Certificates in
Automated Certificate Management Environment (ACME) Automated Certificate Management Environment (ACME)
draft-ietf-acme-star-05 draft-ietf-acme-star-06
Abstract Abstract
Public-key certificates need to be revoked when they are compromised, Public-key certificates need to be revoked when they are compromised,
that is, when the associated private key is exposed to an that is, when the associated private key is exposed to an
unauthorized entity. However the revocation process is often unauthorized entity. However the revocation process is often
unreliable. An alternative to revocation is issuing a sequence of unreliable. An alternative to revocation is issuing a sequence of
certificates, each with a short validity period, and terminating this certificates, each with a short validity period, and terminating this
sequence upon compromise. This memo proposes an ACME extension to sequence upon compromise. This memo proposes an ACME extension to
enable the issuance of short-term and automatically renewed (STAR) enable the issuance of short-term and automatically renewed (STAR)
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2019. This Internet-Draft will expire on January 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1.1. Name Delegation Use Case . . . . . . . . . . . . . . . . 4 1.1. Name Delegation Use Case . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Conventions used in this document . . . . . . . . . . . . 4 1.3. Conventions used in this document . . . . . . . . . . . . 4
2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Refresh . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Refresh . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Termination . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Termination . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 7
3.1. ACME Extensions . . . . . . . . . . . . . . . . . . . . . 7 3.1. ACME Extensions . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Extending the Order Resource . . . . . . . . . . . . 7 3.1.1. Extending the Order Resource . . . . . . . . . . . . 7
3.1.2. Canceling a Recurrent Order . . . . . . . . . . . . . 9 3.1.2. Canceling a Recurrent Order . . . . . . . . . . . . . 8
3.2. Capability Discovery . . . . . . . . . . . . . . . . . . 10 3.2. Capability Discovery . . . . . . . . . . . . . . . . . . 9
3.3. Fetching the Certificates . . . . . . . . . . . . . . . . 10 3.3. Fetching the Certificates . . . . . . . . . . . . . . . . 10
3.4. Negotiating an unauthenticated GET . . . . . . . . . . . 12 3.4. Negotiating an unauthenticated GET . . . . . . . . . . . 12
3.5. Computing notBefore and notAfter of STAR Certificates . . 12 3.5. Computing notBefore and notAfter of STAR Certificates . . 12
3.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 13
4. Operational Considerations . . . . . . . . . . . . . . . . . 14 4. Operational Considerations . . . . . . . . . . . . . . . . . 14
4.1. The Meaning of "Short Term" and the Impact of Skewed 4.1. The Meaning of "Short Term" and the Impact of Skewed
Clocks . . . . . . . . . . . . . . . . . . . . . . . . . 14 Clocks . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Impact on Certificate Transparency (CT) Logs . . . . . . 15 4.2. Impact on Certificate Transparency (CT) Logs . . . . . . 15
4.3. Dependability . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Dependability . . . . . . . . . . . . . . . . . . . . . . 15
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 7 skipping to change at page 3, line 7
5.1.1. ACME Server with STAR extension . . . . . . . . . . . 16 5.1.1. ACME Server with STAR extension . . . . . . . . . . . 16
5.1.2. STAR Proxy . . . . . . . . . . . . . . . . . . . . . 16 5.1.2. STAR Proxy . . . . . . . . . . . . . . . . . . . . . 16
5.2. Level of Maturity . . . . . . . . . . . . . . . . . . . . 17 5.2. Level of Maturity . . . . . . . . . . . . . . . . . . . . 17
5.3. Coverage . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. Coverage . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4. Version Compatibility . . . . . . . . . . . . . . . . . . 17 5.4. Version Compatibility . . . . . . . . . . . . . . . . . . 17
5.5. Licensing . . . . . . . . . . . . . . . . . . . . . . . . 17 5.5. Licensing . . . . . . . . . . . . . . . . . . . . . . . . 17
5.6. Implementation experience . . . . . . . . . . . . . . . . 17 5.6. Implementation experience . . . . . . . . . . . . . . . . 17
5.7. Contact Information . . . . . . . . . . . . . . . . . . . 18 5.7. Contact Information . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. New Error Types . . . . . . . . . . . . . . . . . . . . . 18 6.1. New Error Types . . . . . . . . . . . . . . . . . . . . . 18
6.2. New fields in Order Objects . . . . . . . . . . . . . . . 18 6.2. New fields in Order Objects . . . . . . . . . . . . . . . 19
6.3. New fields in the "meta" Object within a Directory Object 19 6.3. New fields in the "meta" Object within a Directory Object 19
6.4. Not-Before and Not-After HTTP Headers . . . . . . . . . . 19 6.4. Not-Before and Not-After HTTP Headers . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7.1. Denial of Service Considerations . . . . . . . . . . . . 19 7.1. No revocation . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Privacy Considerations . . . . . . . . . . . . . . . . . 20 7.2. Denial of Service Considerations . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Document History . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 22
A.1. draft-ietf-acme-star-05 . . . . . . . . . . . . . . . . . 23 Appendix A. Document History . . . . . . . . . . . . . . . . . . 24
A.2. draft-ietf-acme-star-04 . . . . . . . . . . . . . . . . . 23 A.1. draft-ietf-acme-star-06 . . . . . . . . . . . . . . . . . 24
A.3. draft-ietf-acme-star-03 . . . . . . . . . . . . . . . . . 23 A.2. draft-ietf-acme-star-05 . . . . . . . . . . . . . . . . . 24
A.4. draft-ietf-acme-star-02 . . . . . . . . . . . . . . . . . 23 A.3. draft-ietf-acme-star-04 . . . . . . . . . . . . . . . . . 24
A.5. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 23 A.4. draft-ietf-acme-star-03 . . . . . . . . . . . . . . . . . 24
A.6. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 24 A.5. draft-ietf-acme-star-02 . . . . . . . . . . . . . . . . . 24
A.7. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 24 A.6. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 24
A.8. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 24 A.7. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 25
A.9. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 24 A.8. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 25
A.10. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 24 A.9. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 A.10. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 25
A.11. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The ACME protocol [I-D.ietf-acme-acme] automates the process of The ACME protocol [RFC8555] automates the process of issuing a
issuing a certificate to a named entity (an Identifier Owner or IdO). certificate to a named entity (an Identifier Owner or IdO).
Typically, but not always, the identifier is a domain name. Typically, but not always, the identifier is a domain name.
If the IdO wishes to obtain a string of short-term certificates If the IdO wishes to obtain a string of short-term certificates
originating from the same private key (see [Topalovic] about why originating from the same private key (see [Topalovic] about why
using short-lived certificates might be preferable to explicit using short-lived certificates might be preferable to explicit
revocation), she must go through the whole ACME protocol each time a revocation), she must go through the whole ACME protocol each time a
new short-term certificate is needed - e.g., every 2-3 days. If done new short-term certificate is needed - e.g., every 2-3 days. If done
this way, the process would involve frequent interactions between the this way, the process would involve frequent interactions between the
registration function of the ACME Certification Authority (CA) and registration function of the ACME Certification Authority (CA) and
the identity provider infrastructure (e.g.: DNS, web servers), the identity provider infrastructure (e.g.: DNS, web servers),
therefore making the issuance of short-term certificates exceedingly therefore making the issuance of short-term certificates exceedingly
dependent on the reliability of both. dependent on the reliability of both.
This document presents an extension of the ACME protocol that This document presents an extension of the ACME protocol that
optimizes this process by making short-term certificates first class optimizes this process by making short-term certificates first class
objects in the ACME ecosystem. Once the order for a string of short- objects in the ACME ecosystem. Once the order for a string of short-
term certificates is accepted, the CA is responsible for publishing term certificates is accepted, the CA is responsible for publishing
the next certificate at an agreed upon URL before the previous one the next certificate at an agreed upon URL before the previous one
expires. The IdO can terminate the automatic renewal before the expires. The IdO can terminate the automatic renewal before the
natural deadline, if needed - e.g., on key compromise. negotiated deadline, if needed - e.g., on key compromise.
For a more generic treatment of STAR certificates, readers are For a more generic treatment of STAR certificates, readers are
referred to [I-D.nir-saag-star]. referred to [I-D.nir-saag-star].
1.1. Name Delegation Use Case 1.1. Name Delegation Use Case
The proposed mechanism can be used as a building block of an The proposed mechanism can be used as a building block of an
efficient name-delegation protocol, for example one that exists efficient name-delegation protocol, for example one that exists
between a CDN or a cloud provider and its customers between a CDN or a cloud provider and its customers
[I-D.ietf-acme-star-delegation]. At any time, the service customer [I-D.ietf-acme-star-delegation]. At any time, the service customer
skipping to change at page 5, line 19 skipping to change at page 5, line 19
o Has a short validity, e.g., 24 to 72 hours. Note that the exact o Has a short validity, e.g., 24 to 72 hours. Note that the exact
definition of "short" depends on the use case; definition of "short" depends on the use case;
o Is automatically renewed by the CA for a certain period of time; o Is automatically renewed by the CA for a certain period of time;
o Is downloadable from a (highly available) location. o Is downloadable from a (highly available) location.
Other than that, the ACME protocol flows as usual between IdO and CA. Other than that, the ACME protocol flows as usual between IdO and CA.
In particular, IdO is responsible for satisfying the requested ACME In particular, IdO is responsible for satisfying the requested ACME
challenges until the CA is willing to issue the requested challenges until the CA is willing to issue the requested
certificate. Per normal ACME processing, the IdO is given back an certificate. Per normal ACME processing, the IdO is given back an
order URL for the issued STAR certificate to be used in subsequent Order resource associated with the STAR certificate to be used in
interaction with the CA (e.g., if the certificate needs to be subsequent interaction with the CA (e.g., if the certificate needs to
terminated.) be terminated.)
The bootstrap phase ends when the IdO obtains a confirmation from the The bootstrap phase ends when the ACME CA updates the Order resource
ACME CA that includes a star-certificate endpoint. to include the URL for the issued STAR certificate.
2.2. Refresh 2.2. Refresh
The CA issues the initial certificate, typically when the The CA issues the initial certificate after the authorization
authorization is done. It then automatically re-issues the completes successfully. It then automatically re-issues the
certificate using the same CSR (and therefore the same identifier and certificate using the same CSR (and therefore the same identifier and
public key) before the previous one expires, and publishes it to the public key) before the previous one expires, and publishes it to the
URL that was returned to the IdO at the end of the bootstrap phase. URL that was returned to the IdO at the end of the bootstrap phase.
The certificate user, which could be either the IdO itself or a The certificate user, which could be either the IdO itself or a
delegated third party, as described in delegated third party, as described in
[I-D.ietf-acme-star-delegation], obtains the certificate [I-D.ietf-acme-star-delegation], obtains the certificate
(Section 3.3) and uses it. (Section 3.3) and uses it.
The refresh process (Figure 1) goes on until either: The refresh process (Figure 1) goes on until either:
skipping to change at page 6, line 15 skipping to change at page 6, line 15
Certificate ACME/STAR Certificate ACME/STAR
User Server User Server
| Retrieve cert | [...] | Retrieve cert | [...]
|---------------------->| | |---------------------->| |
| +------. / | +------. /
| | | / | | | /
| | Automatic renewal : | | Automatic renewal :
| | | \ | | | \
| |<-----' \ | |<-----' \
| Retrieve cert | | | Retrieve cert | |
|---------------------->| 72 hours |---------------------->| short validity period
| | | | | |
| +------. / | +------. /
| | | / | | | /
| | Automatic renewal : | | Automatic renewal :
| | | \ | | | \
| |<-----' \ | |<-----' \
| Retrieve cert | | | Retrieve cert | |
|---------------------->| 72 hours |---------------------->| short validity period
| | | | | |
| +------. / | +------. /
| | | / | | | /
| | Automatic renewal : | | Automatic renewal :
| | | \ | | | \
| |<-----' \ | |<-----' \
| | | | | |
| [...] | [...] | [...] | [...]
Figure 1: Auto renewal Figure 1: Auto renewal
skipping to change at page 7, line 42 skipping to change at page 7, line 42
3.1. ACME Extensions 3.1. ACME Extensions
This protocol extends the ACME protocol, to allow for recurrent This protocol extends the ACME protocol, to allow for recurrent
Orders. Orders.
3.1.1. Extending the Order Resource 3.1.1. Extending the Order Resource
The Order resource is extended with the following attributes: The Order resource is extended with the following attributes:
{
"recurrent": true,
"recurrent-start-date": "2016-01-01T00:00:00Z",
"recurrent-end-date": "2017-01-01T00:00:00Z",
"recurrent-certificate-validity": 604800,
"recurrent-certificate-predate": 432000,
"recurrent-certificate-get": true
}
o recurrent (required, boolean): MUST be true for STAR certificates. o recurrent (required, boolean): MUST be true for STAR certificates.
o recurrent-start-date (optional, string): the earliest date of o recurrent-start-date (optional, string): the earliest date of
validity of the first certificate issued, in [RFC3339] format. validity of the first certificate issued, in [RFC3339] format.
When omitted, the start date is as soon as authorization is When omitted, the start date is as soon as authorization is
complete. complete.
o recurrent-end-date (required, string): the latest date of validity o recurrent-end-date (required, string): the latest date of validity
of the last certificate issued, in [RFC3339] format. of the last certificate issued, in [RFC3339] format.
o recurrent-certificate-validity (required, integer): the maximum o recurrent-certificate-validity (required, integer): the maximum
validity period of each STAR certificate, an integer that denotes validity period of each STAR certificate, an integer that denotes
a number of seconds. This is a nominal value which does not a number of seconds. This is a nominal value which does not
include any extra validity time which is due to pre-dating. The include any extra validity time which is due to pre-dating. The
skipping to change at page 8, line 31 skipping to change at page 8, line 20
the notBefore field that would otherwise appear in the STAR the notBefore field that would otherwise appear in the STAR
certificates is pre-dated by the specified number of seconds. See certificates is pre-dated by the specified number of seconds. See
also Section 4.1. also Section 4.1.
o recurrent-certificate-get (optional, boolean): see Section 3.4. o recurrent-certificate-get (optional, boolean): see Section 3.4.
These attributes are included in a POST message when creating the These attributes are included in a POST message when creating the
Order, as part of the "payload" encoded object. They are returned Order, as part of the "payload" encoded object. They are returned
when the Order has been created, and the ACME server MAY adjust them when the Order has been created, and the ACME server MAY adjust them
at will, according to its local policy (see also Section 3.2). at will, according to its local policy (see also Section 3.2).
The optional notBefore and notAfter fields MUST NOT be present in a The optional notBefore and notAfter fields defined in Section 7.1.3
STAR Order. If they are included, the server MUST return an error of [RFC8555] MUST NOT be present in a STAR Order. If they are
with status code 400 "Bad Request" and type "malformedRequest". included, the server MUST return an error with status code 400 "Bad
Request" and type "malformedRequest".
ACME defines the following values for the Order resource's status: Section 7.1.6 of [RFC8555] defines the following values for the Order
"pending", "ready", "processing", "valid", and "invalid". In the resource's status: "pending", "ready", "processing", "valid", and
case of recurrent Orders, the status MUST be "valid" as long as STAR "invalid". In the case of recurrent Orders, the status MUST be
certificates are being issued. We add a new status value: "valid" as long as STAR certificates are being issued. We add a new
"canceled", see Section 3.1.2. status value: "canceled", see Section 3.1.2.
A STAR certificate is by definition a mutable resource. Instead of A STAR certificate is by definition a mutable resource. Instead of
overloading the semantics of the "certificate" key, this document overloading the semantics of the "certificate" attribute, this
defines a new key "star-certificate" to be used instead of document defines a new attribute "star-certificate" to be used
"certificate". instead of "certificate".
o star-certificate (optional, string): A URL for the (rolling) STAR o star-certificate (optional, string): A URL for the (rolling) STAR
certificate that has been issued in response to this Order. certificate that has been issued in response to this Order.
3.1.2. Canceling a Recurrent Order 3.1.2. Canceling a Recurrent Order
An important property of the recurrent Order is that it can be An important property of the recurrent Order is that it can be
canceled by the IdO, with no need for certificate revocation. To canceled by the IdO, with no need for certificate revocation. To
cancel the Order, the ACME client sends a POST to the Order URL: cancel the Order, the ACME client sends a POST to the Order URL as
shown in Figure 3.
POST /acme/order/TOlocE8rfgo HTTP/1.1 POST /acme/order/TOlocE8rfgo HTTP/1.1
Host: example.org Host: example.org
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
"protected": base64url({ "protected": base64url({
"alg": "ES256", "alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg", "kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "5XJ1L3lEkMG7tR6pA00clA", "nonce": "5XJ1L3lEkMG7tR6pA00clA",
"url": "https://example.com/acme/order/TOlocE8rfgo" "url": "https://example.com/acme/order/TOlocE8rfgo"
}), }),
"payload": base64url({ "payload": base64url({
"status": "canceled" "status": "canceled"
}), }),
"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
} }
The server MUST NOT issue any additional certificates for this order, Figure 3: Canceling a Recurrent Order
beyond the certificate that is available for collection at the time
of deletion. After a successful cancellation, the server MUST NOT issue any
additional certificates for this order.
Immediately after the order is canceled, the server: Immediately after the order is canceled, the server:
o MUST update the status of the order resource to "canceled" and o MUST update the status of the order resource to "canceled" and
MUST set an appropriate "expires" date; MUST set an appropriate "expires" date;
o MUST respond with 403 (Forbidden) to any requests to the star- o MUST respond with 403 (Forbidden) to any requests to the star-
certificate endpoint. The response SHOULD provide additional certificate endpoint. The response SHOULD provide additional
information using a problem document [RFC7807] with type information using a problem document [RFC7807] with type
"urn:ietf:params:acme:error:recurrentOrderCanceled". "urn:ietf:params:acme:error:recurrentOrderCanceled".
Issuing a cancellation for an order that is not in "valid" state is Issuing a cancellation for an order that is not in "valid" state is
not allowed. A client MUST NOT send such a request, and a server not allowed. A client MUST NOT send such a request, and a server
MUST return an error response with status code 400 (Bad Request) and MUST return an error response with status code 400 (Bad Request) and
type "urn:ietf:params:acme:error:recurrentCancellationInvalid". type "urn:ietf:params:acme:error:recurrentCancellationInvalid".
Explicit certificate revocation using the revokeCert interface Explicit certificate revocation using the revokeCert interface
(Section 7.6 of [I-D.ietf-acme-acme]) is not supported for STAR (Section 7.6 of [RFC8555]) is not supported for STAR certificates. A
certificates. A server receiving a revocation request for a STAR server receiving a revocation request for a STAR certificate MUST
certificate MUST return an error response with status code 403 return an error response with status code 403 (Forbidden) and type
(Forbidden) and type
"urn:ietf:params:acme:error:recurrentRevocationNotSupported". "urn:ietf:params:acme:error:recurrentRevocationNotSupported".
3.2. Capability Discovery 3.2. Capability Discovery
In order to support the discovery of STAR capabilities, The directory In order to support the discovery of STAR capabilities, the directory
object of an ACME STAR server is extended with the following object defined in Section 9.7.6 of [RFC8555] is extended with the
attributes inside the "meta" field: following attributes inside the "meta" field:
o star-enabled (required, boolean): indicates STAR support. An ACME o star-enabled (required, boolean): indicates STAR support. An ACME
STAR server MUST include this key, and MUST set it to true if the STAR server MUST include this attribute, and MUST set it to true
feature is enabled. if the feature is enabled.
o star-min-cert-validity (required, integer): minimum acceptable o star-min-cert-validity (required, integer): minimum acceptable
value for recurrent-certificate-validity, in seconds. value for recurrent-certificate-validity, in seconds.
o star-max-renewal (required, integer): maximum delta between o star-max-renewal (required, integer): maximum delta between
recurrent-end-date and recurrent-start-date, in seconds. recurrent-end-date and recurrent-start-date, in seconds.
o star-allow-certificate-get (optional, boolean): see Section 3.4. o star-allow-certificate-get (optional, boolean): see Section 3.4.
An example directory object advertising STAR support with one day An example directory object advertising STAR support with one day
star-min-cert-validity and one year star-max-renewal, and supporting star-min-cert-validity and one year star-max-renewal, and supporting
certificate fetching with an HTTP GET: certificate fetching with an HTTP GET is shown in Figure 4.
{ {
"new-nonce": "https://example.com/acme/new-nonce", "new-nonce": "https://example.com/acme/new-nonce",
"new-account": "https://example.com/acme/new-account", "new-account": "https://example.com/acme/new-account",
"new-order": "https://example.com/acme/new-order", "new-order": "https://example.com/acme/new-order",
"new-authz": "https://example.com/acme/new-authz", "new-authz": "https://example.com/acme/new-authz",
"revoke-cert": "https://example.com/acme/revoke-cert", "revoke-cert": "https://example.com/acme/revoke-cert",
"key-change": "https://example.com/acme/key-change", "key-change": "https://example.com/acme/key-change",
"meta": { "meta": {
"terms-of-service": "https://example.com/acme/terms/2017-5-30", "terms-of-service": "https://example.com/acme/terms/2017-5-30",
"website": "https://www.example.com/", "website": "https://www.example.com/",
"caa-identities": ["example.com"], "caa-identities": ["example.com"],
"star-enabled": true, "star-enabled": true,
"star-min-cert-validity": 86400, "star-min-cert-validity": 86400,
"star-max-renewal": 31536000, "star-max-renewal": 31536000,
"star-allow-certificate-get": true "star-allow-certificate-get": true
} }
} }
Figure 4: Directory object with STAR support
3.3. Fetching the Certificates 3.3. Fetching the Certificates
The certificate is fetched from the star-certificate endpoint with The certificate is fetched from the star-certificate endpoint with
POST-as-GET as per [I-D.ietf-acme-acme] Section 7.4.2, unless client POST-as-GET as per [RFC8555] Section 7.4.2, unless client and server
and server have successfully negotiated the "unauthenticated GET" have successfully negotiated the "unauthenticated GET" option
option described in Section 3.4. In such case, the client can simply described in Section 3.4. In such case, the client can simply issue
issue a GET to the star-certificate resource without authenticating a GET to the star-certificate resource without authenticating itself
itself to the server as illustrated in the following example: to the server as illustrated in Figure 5.
GET /acme/cert/mAt3xBGaobw HTTP/1.1 GET /acme/cert/mAt3xBGaobw HTTP/1.1
Host: example.org Host: example.org
Accept: application/pem-certificate-chain Accept: application/pem-certificate-chain
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/pem-certificate-chain Content-Type: application/pem-certificate-chain
Link: <https://example.com/acme/some-directory>;rel="index" Link: <https://example.com/acme/some-directory>;rel="index"
Not-Before: Mon, 1 Feb 2016 00:00:00 GMT Not-Before: Mon, 1 Feb 2016 00:00:00 GMT
Not-After: Mon, 8 Feb 2016 00:00:00 GMT Not-After: Mon, 8 Feb 2016 00:00:00 GMT
skipping to change at page 11, line 25 skipping to change at page 11, line 25
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
[End-entity certificate contents] [End-entity certificate contents]
-----END CERTIFICATE----- -----END CERTIFICATE-----
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
[Issuer certificate contents] [Issuer certificate contents]
-----END CERTIFICATE----- -----END CERTIFICATE-----
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
[Other certificate contents] [Other certificate contents]
-----END CERTIFICATE----- -----END CERTIFICATE-----
Figure 5: Fetching a STAR certificate with unauthenticated GET
The Server SHOULD include the "Not-Before" and "Not-After" HTTP The Server SHOULD include the "Not-Before" and "Not-After" HTTP
headers in the response. When they exist, they MUST be equal to the headers in the response. When they exist, they MUST be equal to the
respective fields inside the end-entity certificate. Their format is respective fields inside the end-entity certificate. Their format is
"HTTP-date" as defined in Section 7.1.1.2 of [RFC7231]. Their "HTTP-date" as defined in Section 7.1.1.2 of [RFC7231]. Their
purpose is to enable client implementations that do not parse the purpose is to enable client implementations that do not parse the
certificate. certificate.
To improve robustness, the next certificate MUST be made available by To improve robustness, the next certificate MUST be made available by
the ACME CA at the URL pointed by "star-certificate" at the latest the ACME CA at the URL pointed by "star-certificate" at the latest
halfway through the lifetime of the currently active certificate. It halfway through the lifetime of the currently active certificate. It
skipping to change at page 12, line 19 skipping to change at page 12, line 20
In order to enable the name delegation workflow defined in In order to enable the name delegation workflow defined in
[I-D.ietf-acme-star-delegation] as well as to increase the [I-D.ietf-acme-star-delegation] as well as to increase the
reliability of the STAR ecosystem (see Section 4.3 for details), this reliability of the STAR ecosystem (see Section 4.3 for details), this
document defines a mechanism that allows a server to advertise document defines a mechanism that allows a server to advertise
support for accessing star-certificate resources via unauthenticated support for accessing star-certificate resources via unauthenticated
GET (instead of, or in addition to, POST-as-GET), and a client to GET (instead of, or in addition to, POST-as-GET), and a client to
enable this service with per-Order granularity. enable this service with per-Order granularity.
Specifically, a server states its availability to grant Specifically, a server states its availability to grant
unauthenticated access to a client's Order star-certificate by unauthenticated access to a client's Order star-certificate by
setting the star-allow-certificate-get key to true in the meta field setting the star-allow-certificate-get attribute to true in the meta
of the Directory object: field of the Directory object:
o star-allow-certificate-get (optional, boolean): If this field is o star-allow-certificate-get (optional, boolean): If this field is
present and set to true, the server allows GET requests to star- present and set to true, the server allows GET requests to star-
certificate URLs. certificate URLs.
A client states its will to access the issued star-certificate via A client states its will to access the issued star-certificate via
unauthenticated GET by adding a recurrent-certificate-get key to its unauthenticated GET by adding a recurrent-certificate-get attribute
Order and setting it to true. to its Order and setting it to true.
o recurrent-certificate-get (optional, boolean): If this field is o recurrent-certificate-get (optional, boolean): If this field is
present and set to true, the client requests the server to allow present and set to true, the client requests the server to allow
unauthenticated GET to the star-certificate associated with this unauthenticated GET to the star-certificate associated with this
Order. Order.
If the server accepts the request, it MUST reflect the key in the If the server accepts the request, it MUST reflect the attribute
Order. setting in the resulting Order object.
3.5. Computing notBefore and notAfter of STAR Certificates 3.5. Computing notBefore and notAfter of STAR Certificates
We define "nominal renewal date" the point in time when a new short- We define "nominal renewal date" the point in time when a new short-
term certificate for a given STAR Order is due. It is a multiple of term certificate for a given STAR Order is due. It is a multiple of
the Order's recurrent-certificate-validity that starts with the the Order's recurrent-certificate-validity that starts with the
issuance of the first short-term certificate and is upper-bounded by issuance of the first short-term certificate and is upper-bounded by
the Order's recurrent-end-date (Figure 3). the Order's recurrent-end-date (Figure 6).
rcv - STAR Order's recurrent-certificate-validity rcv - STAR Order's recurrent-certificate-validity
red - STAR Order's recurrent-end-date red - STAR Order's recurrent-end-date
nrd[i] - nominal renewal date of the i-th STAR certificate nrd[i] - nominal renewal date of the i-th STAR certificate
.-rcv-. .-rcv-. .-rcv-. .__. .-rcv-. .-rcv-. .-rcv-. .__.
/ \ / \ / \ / red / \ / \ / \ / red
-----------o---------o---------o---------o----X-------> t -----------o---------o---------o---------o----X-------> t
nrd[0] nrd[1] nrd[2] nrd[3] nrd[0] nrd[1] nrd[2] nrd[3]
Figure 3: Nominal Renewal Date Figure 6: Nominal Renewal Date
The rules to determine the notBefore and notAfter values of the i-th The rules to determine the notBefore and notAfter values of the i-th
STAR certificate are as follows: STAR certificate are as follows:
notBefore = nrd[i] - predating notBefore = nrd[i] - predating
notAfter = min(nrd[i] + rcv, red) notAfter = min(nrd[i] + rcv, red)
where "predating" is the max between the (optional) recurrent- where "predating" is the max between the (optional) recurrent-
certificate-predate (rcp) and the amount of pre-dating that the certificate-predate (rcp) and the amount of pre-dating that the
server needs to add to make sure that all certificates being server needs to add to make sure that all certificates being
skipping to change at page 14, line 5 skipping to change at page 14, line 5
"recurrent-end-date": "2016-01-20T00:00:00Z", "recurrent-end-date": "2016-01-20T00:00:00Z",
"recurrent-certificate-validity": 345600, // 4 days "recurrent-certificate-validity": 345600, // 4 days
"recurrent-certificate-predate": 518400 // 6 days "recurrent-certificate-predate": 518400 // 6 days
} }
The amount of pre-dating that needs to be subtracted from each The amount of pre-dating that needs to be subtracted from each
nominal renewal date is 6 days - i.e., max(518400, 345600 * .5). nominal renewal date is 6 days - i.e., max(518400, 345600 * .5).
The notBefore and notAfter of each short-term certificate are: The notBefore and notAfter of each short-term certificate are:
[ +----------------------+----------------------+
[ "2016-01-04T00:00:00Z", "2016-01-14T00:00:00Z" ], | notBefore | notAfter |
[ "2016-01-08T00:00:00Z", "2016-01-18T00:00:00Z" ], +----------------------+----------------------+
[ "2016-01-12T00:00:00Z", "2016-01-20T00:00:00Z" ] | 2016-01-04T00:00:00Z | 2016-01-14T00:00:00Z |
] | 2016-01-08T00:00:00Z | 2016-01-18T00:00:00Z |
| 2016-01-12T00:00:00Z | 2016-01-20T00:00:00Z |
+----------------------+----------------------+
A client should expect each certificate to be available from the A client should expect each certificate to be available from the
star-certificate endpoint at the following times: star-certificate endpoint at the following times:
[ +------------------------------------+
"2016-01-10T00:00:00Z", // or earlier | 2016-01-10T00:00:00Z (or earlier) |
"2016-01-12T00:00:00Z", | 2016-01-12T00:00:00Z |
"2016-01-16T00:00:00Z" | 2016-01-16T00:00:00Z |
] +------------------------------------+
4. Operational Considerations 4. Operational Considerations
4.1. The Meaning of "Short Term" and the Impact of Skewed Clocks 4.1. The Meaning of "Short Term" and the Impact of Skewed Clocks
"Short Term" is a relative concept, therefore trying to define a cut- "Short Term" is a relative concept, therefore trying to define a cut-
off point that works in all cases would be a useless exercise. In off point that works in all cases would be a useless exercise. In
practice, the expected lifetime of a STAR certificate will be counted practice, the expected lifetime of a STAR certificate will be counted
in minutes, hours or days, depending on different factors: the in minutes, hours or days, depending on different factors: the
underlying requirements for revocation, how much clock underlying requirements for revocation, how much clock
skipping to change at page 19, line 48 skipping to change at page 20, line 7
+-------------------+----------+----------+-----------+ +-------------------+----------+----------+-----------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-----------+ +-------------------+----------+----------+-----------+
| Not-Before | http | standard | RFC XXXX | | Not-Before | http | standard | RFC XXXX |
| Not-After | http | standard | RFC XXXX | | Not-After | http | standard | RFC XXXX |
+-------------------+----------+----------+-----------+ +-------------------+----------+----------+-----------+
7. Security Considerations 7. Security Considerations
7.1. Denial of Service Considerations 7.1. No revocation
STAR certificates eliminate an important security feature of PKI
which is the ability to revoke certificates. Revocation allows the
administrator to limit the damage done by a rogue node or an
adversary who has control of the private key. With STAR
certificates, expiration replaces revocation so there is a timeliness
issue. To that end, see also the discussion on clock skew in
Section 4.1.
It should be noted that revocation also has timeliness issues,
because both CRLs and OCSP responses have nextUpdate fields that tell
relying parties (RPs) how long they should trust this revocation
data. These fields are typically set to hours, days, or even weeks
in the future. Any revocation that happens before the time in
nextUpdate goes unnoticed by the RP.
More discussion of the security of STAR certificates is available in
[Topalovic].
7.2. Denial of Service Considerations
STAR adds a new attack vector that increases the threat of denial of STAR adds a new attack vector that increases the threat of denial of
service attacks, caused by the change to the CA's behavior. Each service attacks, caused by the change to the CA's behavior. Each
STAR request amplifies the resource demands upon the CA, where one STAR request amplifies the resource demands upon the CA, where one
order produces not one, but potentially dozens or hundreds of order produces not one, but potentially dozens or hundreds of
certificates, depending on the "recurrent-certificate-validity" certificates, depending on the "recurrent-certificate-validity"
parameter. An attacker can use this property to aggressively reduce parameter. An attacker can use this property to aggressively reduce
the "recurrent-certificate-validity" (e.g. 1 sec.) jointly with other the "recurrent-certificate-validity" (e.g. 1 sec.) jointly with other
ACME attack vectors identified in Sec. 10 of [I-D.ietf-acme-acme]. ACME attack vectors identified in Sec. 10 of [RFC8555]. Other
Other collateral impact is related to the certificate endpoint collateral impact is related to the certificate endpoint resource
resource where the client can retrieve the certificates periodically. where the client can retrieve the certificates periodically. If this
If this resource is external to the CA (e.g. a hosted web server), resource is external to the CA (e.g. a hosted web server), the
the previous attack will be reflected to that resource. previous attack will be reflected to that resource.
Mitigation recommendations from ACME still apply, but some of them Mitigation recommendations from ACME still apply, but some of them
need to be adjusted. For example, applying rate limiting to the need to be adjusted. For example, applying rate limiting to the
initial request, by the nature of the recurrent behavior cannot solve initial request, by the nature of the recurrent behavior cannot solve
the above problem. The CA server needs complementary mitigation and the above problem. The CA server needs complementary mitigation and
specifically, it SHOULD enforce a minimum value on "recurrent- specifically, it SHOULD enforce a minimum value on "recurrent-
certificate-validity". Alternatively, the CA can set an internal certificate-validity". Alternatively, the CA can set an internal
certificate generation processes rate limit. certificate generation processes rate limit.
7.2. Privacy Considerations 7.3. Privacy Considerations
In order to avoid correlation of certificates by account, if In order to avoid correlation of certificates by account, if
unauthenticated GET is negotiated (Section 3.4) the server SHOULD unauthenticated GET is negotiated (Section 3.4) the recommendation in
choose URLs of certificate resources in a non-guessable way, for Section 10.5 of [RFC8555] regarding the choice of URL structure
example using capability URLs [W3C.WD-capability-urls-20140218]. applies, i.e. servers SHOULD choose URLs of certificate resources in
a non-guessable way, for example using capability URLs
[W3C.WD-capability-urls-20140218].
8. Acknowledgments 8. Acknowledgments
This work is partially supported by the European Commission under This work is partially supported by the European Commission under
Horizon 2020 grant agreement no. 688421 Measurement and Architecture Horizon 2020 grant agreement no. 688421 Measurement and Architecture
for a Middleboxed Internet (MAMI). This support does not imply for a Middleboxed Internet (MAMI). This support does not imply
endorsement. endorsement.
Thanks to Jon Peterson, Eric Rescorla, Sean Turner and Martin Thomson Thanks to Roman Danyliw, Jon Peterson, Eric Rescorla, Sean Turner and
for helpful comments and discussions that have shaped this document. Martin Thomson for helpful comments and discussions that have shaped
this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-acme-acme]
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", draft-ietf-acme-acme-18 (work in progress),
December 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
skipping to change at page 21, line 27 skipping to change at page 22, line 5
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP
APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
<https://www.rfc-editor.org/info/rfc7807>. <https://www.rfc-editor.org/info/rfc7807>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
9.2. Informative References 9.2. Informative References
[Acer] Acer, M., Stark, E., Felt, A., Fahl, S., Bhargava, R., [Acer] Acer, M., Stark, E., Felt, A., Fahl, S., Bhargava, R.,
Dev, B., Braithwaite, M., Sleevi, R., and P. Tabriz, Dev, B., Braithwaite, M., Sleevi, R., and P. Tabriz,
"Where the Wild Warnings Are: Root Causes of Chrome HTTPS "Where the Wild Warnings Are: Root Causes of Chrome HTTPS
Certificate Errors", DOI 10.1145/3133956.3134007, 2017, Certificate Errors", DOI 10.1145/3133956.3134007, 2017,
<https://acmccs.github.io/papers/p1407-acerA.pdf>. <https://acmccs.github.io/papers/p1407-acerA.pdf>.
[I-D.ietf-acme-star-delegation] [I-D.ietf-acme-star-delegation]
Sheffer, Y., Lopez, D., Pastor, A., and T. Fossati, "An Sheffer, Y., Lopez, D., Pastor, A., and T. Fossati, "An
skipping to change at page 22, line 27 skipping to change at page 23, line 8
[Stark] Stark, E., Huang, L., Israni, D., Jackson, C., and D. [Stark] Stark, E., Huang, L., Israni, D., Jackson, C., and D.
Boneh, "The case for prefetching and prevalidating TLS Boneh, "The case for prefetching and prevalidating TLS
server certificates", 2012, server certificates", 2012,
<http://crypto.stanford.edu/~dabo/pubs/abstracts/ <http://crypto.stanford.edu/~dabo/pubs/abstracts/
ssl-prefetch.html>. ssl-prefetch.html>.
[Topalovic] [Topalovic]
Topalovic, E., Saeta, B., Huang, L., Jackson, C., and D. Topalovic, E., Saeta, B., Huang, L., Jackson, C., and D.
Boneh, "Towards Short-Lived Certificates", 2012, Boneh, "Towards Short-Lived Certificates", 2012,
<http://www.w2spconf.com/2012/papers/w2sp12-final9.pdf>. <http://www.ieee-security.org/TC/W2SP/2012/papers/
w2sp12-final9.pdf>.
[W3C.WD-capability-urls-20140218] [W3C.WD-capability-urls-20140218]
Tennison, J., "Good Practices for Capability URLs", World Tennison, J., "Good Practices for Capability URLs", World
Wide Web Consortium WD WD-capability-urls-20140218, Wide Web Consortium WD WD-capability-urls-20140218,
February 2014, February 2014,
<http://www.w3.org/TR/2014/WD-capability-urls-20140218>. <http://www.w3.org/TR/2014/WD-capability-urls-20140218>.
Appendix A. Document History Appendix A. Document History
[[Note to RFC Editor: please remove before publication.]] [[Note to RFC Editor: please remove before publication.]]
A.1. draft-ietf-acme-star-05 A.1. draft-ietf-acme-star-06
o Roman's AD review
A.2. draft-ietf-acme-star-05
o EKR's AD review o EKR's AD review
o A detailed example of the timing of certificate issuance and o A detailed example of the timing of certificate issuance and
predating predating
o Added an explicit client-side parameter for predating o Added an explicit client-side parameter for predating
o Security considerations around unauthenticated GET o Security considerations around unauthenticated GET
A.2. draft-ietf-acme-star-04 A.3. draft-ietf-acme-star-04
o WG last call comments by Sean Turner o WG last call comments by Sean Turner
o revokeCert interface handling o revokeCert interface handling
o Allow negotiating plain-GET for certs o Allow negotiating plain-GET for certs
o In STAR Orders, use star-certificate instead of certificate o In STAR Orders, use star-certificate instead of certificate
A.3. draft-ietf-acme-star-03 A.4. draft-ietf-acme-star-03
o Clock skew considerations o Clock skew considerations
o Recommendations for "short" in the Web use case o Recommendations for "short" in the Web use case
o CT log considerations o CT log considerations
A.4. draft-ietf-acme-star-02 A.5. draft-ietf-acme-star-02
o Discovery of STAR capabilities via the directory object o Discovery of STAR capabilities via the directory object
o Use the more generic term Identifier Owner (IdO) instead of Domain o Use the more generic term Identifier Owner (IdO) instead of Domain
Name Owner (DNO) Name Owner (DNO)
o More precision about what goes in the order o More precision about what goes in the order
o Detail server side behavior on cancellation o Detail server side behavior on cancellation
A.5. draft-ietf-acme-star-01 A.6. draft-ietf-acme-star-01
o Generalized the introduction, separating out the specifics of o Generalized the introduction, separating out the specifics of
CDNs. CDNs.
o Clean out LURK-specific text. o Clean out LURK-specific text.
o Using a POST to ensure cancellation is authenticated. o Using a POST to ensure cancellation is authenticated.
o First and last date of recurrent cert, as absolute dates. o First and last date of recurrent cert, as absolute dates.
Validity of certs in seconds. Validity of certs in seconds.
o Use RFC7807 "Problem Details" in error responses. o Use RFC7807 "Problem Details" in error responses.
o Add IANA considerations. o Add IANA considerations.
o Changed the document's title. o Changed the document's title.
A.6. draft-ietf-acme-star-00 A.7. draft-ietf-acme-star-00
o Initial working group version. o Initial working group version.
o Removed the STAR interface, the protocol between NDC and DNO. o Removed the STAR interface, the protocol between NDC and DNO.
What remains is only the extended ACME protocol. What remains is only the extended ACME protocol.
A.7. draft-sheffer-acme-star-02 A.8. draft-sheffer-acme-star-02
o Using a more generic term for the delegation client, NDC. o Using a more generic term for the delegation client, NDC.
o Added an additional use case: public cloud services. o Added an additional use case: public cloud services.
o More detail on ACME authorization. o More detail on ACME authorization.
A.8. draft-sheffer-acme-star-01 A.9. draft-sheffer-acme-star-01
o A terminology section. o A terminology section.
o Some cleanup. o Some cleanup.
A.9. draft-sheffer-acme-star-00 A.10. draft-sheffer-acme-star-00
o Renamed draft to prevent confusion with other work in this space. o Renamed draft to prevent confusion with other work in this space.
o Added an initial STAR protocol: a REST API. o Added an initial STAR protocol: a REST API.
o Discussion of CDNI use cases. o Discussion of CDNI use cases.
A.10. draft-sheffer-acme-star-lurk-00 A.11. draft-sheffer-acme-star-lurk-00
o Initial version. o Initial version.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Intuit Intuit
EMail: yaronf.ietf@gmail.com EMail: yaronf.ietf@gmail.com
 End of changes. 53 change blocks. 
125 lines changed or deleted 152 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/