draft-ietf-acme-star-04.txt   draft-ietf-acme-star-05.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: April 22, 2019 O. Gonzalez de Dios Expires: September 5, 2019 O. Gonzalez de Dios
A. Pastor Perales A. Pastor Perales
Telefonica I+D Telefonica I+D
T. Fossati T. Fossati
Nokia ARM
October 19, 2018 March 04, 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-04 draft-ietf-acme-star-05
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 April 22, 2019. This Internet-Draft will expire on September 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . 8 3.1.2. Canceling a Recurrent Order . . . . . . . . . . . . . 9
3.2. Capability Discovery . . . . . . . . . . . . . . . . . . 9 3.2. Capability Discovery . . . . . . . . . . . . . . . . . . 10
3.3. Fetching the Certificates . . . . . . . . . . . . . . . . 10 3.3. Fetching the Certificates . . . . . . . . . . . . . . . . 10
3.4. Negotiate unauthenticated GET . . . . . . . . . . . . . . 12 3.4. Negotiating an unauthenticated GET . . . . . . . . . . . 12
4. Operational Considerations . . . . . . . . . . . . . . . . . 12 3.5. Computing notBefore and notAfter of STAR Certificates . . 12
3.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . . . . . 12 Clocks . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Impact on Certificate Transparency (CT) Logs . . . . . . 13 4.2. Impact on Certificate Transparency (CT) Logs . . . . . . 15
4.3. Dependability . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Dependability . . . . . . . . . . . . . . . . . . . . . . 15
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1. ACME Server with STAR extension . . . . . . . . . . . 14 5.1.1. ACME Server with STAR extension . . . . . . . . . . . 16
5.1.2. STAR Proxy . . . . . . . . . . . . . . . . . . . . . 15 5.1.2. STAR Proxy . . . . . . . . . . . . . . . . . . . . . 16
5.2. Level of Maturity . . . . . . . . . . . . . . . . . . . . 15 5.2. Level of Maturity . . . . . . . . . . . . . . . . . . . . 17
5.3. Coverage . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Coverage . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4. Version Compatibility . . . . . . . . . . . . . . . . . . 15 5.4. Version Compatibility . . . . . . . . . . . . . . . . . . 17
5.5. Licensing . . . . . . . . . . . . . . . . . . . . . . . . 15 5.5. Licensing . . . . . . . . . . . . . . . . . . . . . . . . 17
5.6. Implementation experience . . . . . . . . . . . . . . . . 16 5.6. Implementation experience . . . . . . . . . . . . . . . . 17
5.7. Contact Information . . . . . . . . . . . . . . . . . . . 16 5.7. Contact Information . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. New Error Types . . . . . . . . . . . . . . . . . . . . . 16 6.1. New Error Types . . . . . . . . . . . . . . . . . . . . . 18
6.2. New fields in Order Objects . . . . . . . . . . . . . . . 17 6.2. New fields in Order Objects . . . . . . . . . . . . . . . 18
6.3. New fields in the "meta" Object within a Directory Object 18 6.3. New fields in the "meta" Object within a Directory Object 19
6.4. Not-Before and Not-After HTTP Headers . . . . . . . . . . 18 6.4. Not-Before and Not-After HTTP Headers . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7.1. Denial of Service Considerations . . . . . . . . . . . . 18 7.1. Denial of Service Considerations . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Privacy Considerations . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Document History . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 21
A.1. draft-ietf-acme-star-04 . . . . . . . . . . . . . . . . . 21 Appendix A. Document History . . . . . . . . . . . . . . . . . . 23
A.2. draft-ietf-acme-star-03 . . . . . . . . . . . . . . . . . 21 A.1. draft-ietf-acme-star-05 . . . . . . . . . . . . . . . . . 23
A.3. draft-ietf-acme-star-02 . . . . . . . . . . . . . . . . . 21 A.2. draft-ietf-acme-star-04 . . . . . . . . . . . . . . . . . 23
A.4. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 21 A.3. draft-ietf-acme-star-03 . . . . . . . . . . . . . . . . . 23
A.5. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 21 A.4. draft-ietf-acme-star-02 . . . . . . . . . . . . . . . . . 23
A.6. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 21 A.5. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 23
A.7. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 22 A.6. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 24
A.8. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 22 A.7. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 24
A.9. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 22 A.8. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 A.9. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 24
A.10. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The ACME protocol [I-D.ietf-acme-acme] automates the process of The ACME protocol [I-D.ietf-acme-acme] automates the process of
issuing a certificate to a named entity (an Identifier Owner or IdO). issuing a 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
skipping to change at page 4, line 13 skipping to change at page 4, line 15
natural deadline, if needed - e.g., on key compromise. natural 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.sheffer-acme-star-request]. At any time, the service customer [I-D.ietf-acme-star-delegation]. At any time, the service customer
(i.e., the IdO) can terminate the delegation by simply instructing (i.e., the IdO) can terminate the delegation by simply instructing
the CA to stop the automatic renewal and letting the currently active the CA to stop the automatic renewal and letting the currently active
certificate expire shortly thereafter. Note that in this case the certificate expire shortly thereafter. Note that in this case the
delegated entity needs to access the auto-renewed certificate without delegated entity needs to access the auto-renewed certificate without
being in possession of the ACME account key that was used for being in possession of the ACME account key that was used for
initiating the STAR issuance. initiating the STAR issuance.
1.2. Terminology 1.2. Terminology
IdO Identifier Owner, the owner of an identifier, e.g.: a domain IdO Identifier Owner, the owner of an identifier, e.g.: a domain
skipping to change at page 5, line 30 skipping to change at page 5, line 35
2.2. Refresh 2.2. Refresh
The CA issues the initial certificate, typically when the The CA issues the initial certificate, typically when the
authorization is done. It then automatically re-issues the authorization is done. 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.sheffer-acme-star-request], 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:
o IdO explicitly terminates the automatic renewal (Section 2.3); or o IdO explicitly terminates the automatic renewal (Section 2.3); or
o Automatic renewal expires. o Automatic renewal expires.
Certificate ACME/STAR Certificate ACME/STAR
User Server User Server
| Retrieve cert | [...] | Retrieve cert | [...]
skipping to change at page 7, line 46 skipping to change at page 7, line 46
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": true,
"recurrent-start-date": "2016-01-01T00:00:00Z", "recurrent-start-date": "2016-01-01T00:00:00Z",
"recurrent-end-date": "2017-01-01T00:00:00Z", "recurrent-end-date": "2017-01-01T00:00:00Z",
"recurrent-certificate-validity": 604800 "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
client can use this value as a hint to configure its polling client can use the value reflected by the server (which may be
timer. different from the one sent by the client) as a hint to configure
its polling timer.
o recurrent-certificate-predate (optional, integer): amount of pre-
dating added to each STAR certificate, an integer that denotes a
number of seconds. The default is 0. If present, the value of
the notBefore field that would otherwise appear in the STAR
certificates is pre-dated by the specified number of seconds. See
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 MUST NOT be present in a
STAR Order. If they are included, the server MUST return an error STAR Order. If they are included, the server MUST return an error
with status code 400 "Bad Request" and type "malformedRequest". with status code 400 "Bad Request" and type "malformedRequest".
skipping to change at page 9, line 35 skipping to change at page 9, line 41
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 has Issuing a cancellation for an order that is not in "valid" state is
undefined semantics. A client MUST NOT send such a request, and a not allowed. A client MUST NOT send such a request, and a server
server MUST return an error response with status code 400 (Bad MUST return an error response with status code 400 (Bad Request) and
Request) and type type "urn:ietf:params:acme:error:recurrentCancellationInvalid".
"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 [I-D.ietf-acme-acme]) is not supported for STAR
certificates. A server receiving a revocation request for a STAR certificates. A server receiving a revocation request for a STAR
certificate MUST return an error response with status code 403 certificate MUST 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
skipping to change at page 10, line 32 skipping to change at page 10, line 38
"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
} }
} }
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 [I-D.ietf-acme-acme] Section 7.4.2, unless client
and server have successfully negotiated the "unauthenticated GET" and server have successfully negotiated the "unauthenticated GET"
option described in Section 3.4. In such case, the client can simply option described in Section 3.4. In such case, the client can simply
issue a GET to the star-certificate resource without authenticating issue a GET to the star-certificate resource without authenticating
skipping to change at page 11, line 40 skipping to change at page 11, line 40
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
is worth noting that this has an implication in case of cancellation: is worth noting that this has an implication in case of cancellation:
in fact, from the time the next certificate is made available, the in fact, from the time the next certificate is made available, the
cancellation is not completely effective until the latter also cancellation is not completely effective until the latter also
expires. To avoid the client accidentally entering a broken state, expires. To avoid the client accidentally entering a broken state,
the "next" certificate MUST be pre-dated so that it is already valid the "next" certificate MUST be pre-dated so that it is already valid
when it is published at the "star-certificate" URL. For further when it is published at the "star-certificate" URL. Note that the
discussion on pre-dating, see Section 4.1. server might need to increase the recurrent-certificate-predate value
to satisfy the latter requirement. For further discussion on pre-
dating, see Section 4.1.
The server MUST NOT issue any additional certificates for this order The server MUST NOT issue any additional certificates for this order
beyond its recurrent-end-date. beyond its recurrent-end-date.
Immediately after the order expires, the server MUST respond with 403 Immediately after the order expires, the server MUST respond with 403
(Forbidden) to any requests to the star-certificate endpoint. The (Forbidden) to any requests to the star-certificate endpoint. The
response SHOULD provide additional information using a problem response SHOULD provide additional information using a problem
document [RFC7807] with type document [RFC7807] with type
"urn:ietf:params:acme:error:recurrentOrderExpired". Note that the "urn:ietf:params:acme:error:recurrentOrderExpired". Note that the
Order resource's state remains "valid", as per the base protocol. Order resource's state remains "valid", as per the base protocol.
3.4. Negotiate unauthenticated GET 3.4. Negotiating an unauthenticated GET
In order to enable the name delegation workflow defined in In order to enable the name delegation workflow defined in
[I-D.sheffer-acme-star-request] 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 key to true in the meta field
of the Directory object: of the Directory object:
skipping to change at page 12, line 36 skipping to change at page 12, line 38
Order and setting it to true. 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 key in the
Order. Order.
3.5. Computing notBefore and notAfter of STAR Certificates
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
the Order's recurrent-certificate-validity that starts with the
issuance of the first short-term certificate and is upper-bounded by
the Order's recurrent-end-date (Figure 3).
rcv - STAR Order's recurrent-certificate-validity
red - STAR Order's recurrent-end-date
nrd[i] - nominal renewal date of the i-th STAR certificate
.-rcv-. .-rcv-. .-rcv-. .__.
/ \ / \ / \ / red
-----------o---------o---------o---------o----X-------> t
nrd[0] nrd[1] nrd[2] nrd[3]
Figure 3: Nominal Renewal Date
The rules to determine the notBefore and notAfter values of the i-th
STAR certificate are as follows:
notBefore = nrd[i] - predating
notAfter = min(nrd[i] + rcv, red)
where "predating" is the max between the (optional) recurrent-
certificate-predate (rcp) and the amount of pre-dating that the
server needs to add to make sure that all certificates being
published are valid at the time of publication (Section 3.3). The
server pre-dating is a fraction f of rcv (i.e., f * rcv with .5 <= f
< 1).
predating = max(rcp, f * rcv)
3.5.1. Example
Given a server that intends to publish the next STAR certificate
halfway through the lifetime of the previous one, and a STAR Order
with the following attributes:
{
"recurrent-start-date": "2016-01-10T00:00:00Z",
"recurrent-end-date": "2016-01-20T00:00:00Z",
"recurrent-certificate-validity": 345600, // 4 days
"recurrent-certificate-predate": 518400 // 6 days
}
The amount of pre-dating that needs to be subtracted from each
nominal renewal date is 6 days - i.e., max(518400, 345600 * .5).
The notBefore and notAfter of each short-term certificate are:
[
[ "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
star-certificate endpoint at the following times:
[
"2016-01-10T00:00:00Z", // or earlier
"2016-01-12T00: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
synchronization is expected among relying parties and the issuing CA, synchronization is expected among relying parties and the issuing CA,
skipping to change at page 17, line 43 skipping to change at page 19, line 12
This document adds the following entries to the ACME Order Object This document adds the following entries to the ACME Order Object
Fields registry: Fields registry:
+------------------------------+---------+--------------+-----------+ +------------------------------+---------+--------------+-----------+
| Field Name | Field | Configurable | Reference | | Field Name | Field | Configurable | Reference |
| | Type | | | | | Type | | |
+------------------------------+---------+--------------+-----------+ +------------------------------+---------+--------------+-----------+
| recurrent | string | true | RFC XXXX | | recurrent | string | true | RFC XXXX |
| recurrent-start-date | string | true | RFC XXXX | | recurrent-start-date | string | true | RFC XXXX |
| recurrent-end-date | string | true | RFC XXXX | | recurrent-end-date | string | true | RFC XXXX |
| recurrent-certificate- | string | true | RFC XXXX | | recurrent-certificate- | integer | true | RFC XXXX |
| validity | | | | | validity | | | |
| recurrent-certificate- | integer | true | RFC XXXX |
| predate | | | |
| recurrent-certificate-get | boolean | true | RFC XXXX | | recurrent-certificate-get | boolean | true | RFC XXXX |
| star-certificate | string | false | RFC XXXX | | star-certificate | string | false | RFC XXXX |
+------------------------------+---------+--------------+-----------+ +------------------------------+---------+--------------+-----------+
6.3. New fields in the "meta" Object within a Directory Object 6.3. New fields in the "meta" Object within a Directory Object
This document adds the following entries to the ACME Directory This document adds the following entries to the ACME Directory
Metadata Fields: Metadata Fields:
+----------------------------+------------+-----------+ +----------------------------+------------+-----------+
skipping to change at page 19, line 7 skipping to change at page 20, line 22
the previous attack will be reflected to that resource. the 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
In order to avoid correlation of certificates by account, if
unauthenticated GET is negotiated (Section 3.4) the server 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, Sean Turner and Martin Thomson for helpful Thanks to Jon Peterson, Eric Rescorla, Sean Turner and Martin Thomson
comments and discussions that have shaped this document. 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] [I-D.ietf-acme-acme]
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", draft-ietf-acme-acme-16 (work in progress), (ACME)", draft-ietf-acme-acme-18 (work in progress),
October 2018. 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>.
skipping to change at page 20, line 13 skipping to change at page 21, line 35
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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]
Sheffer, Y., Lopez, D., Pastor, A., and T. Fossati, "An
ACME Profile for Generating Delegated STAR Certificates",
draft-ietf-acme-star-delegation-00 (work in progress),
December 2018.
[I-D.nir-saag-star] [I-D.nir-saag-star]
Nir, Y., Fossati, T., Sheffer, Y., and T. Eckert, Nir, Y., Fossati, T., Sheffer, Y., and T. Eckert,
"Considerations For Using Short Term Certificates", draft- "Considerations For Using Short Term Certificates", draft-
nir-saag-star-01 (work in progress), March 2018. nir-saag-star-01 (work in progress), March 2018.
[I-D.sheffer-acme-star-request] [I-D.sheffer-acme-star-request]
Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T.
Fossati, "Generating Certificate Requests for Short-Term, Fossati, "Generating Certificate Requests for Short-Term,
Automatically-Renewed (STAR) Certificates", draft-sheffer- Automatically-Renewed (STAR) Certificates", draft-sheffer-
acme-star-request-02 (work in progress), June 2018. acme-star-request-02 (work in progress), June 2018.
skipping to change at page 21, line 5 skipping to change at page 22, line 29
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.w2spconf.com/2012/papers/w2sp12-final9.pdf>.
[W3C.WD-capability-urls-20140218]
Tennison, J., "Good Practices for Capability URLs", World
Wide Web Consortium WD WD-capability-urls-20140218,
February 2014,
<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-04 A.1. draft-ietf-acme-star-05
o EKR's AD review
o A detailed example of the timing of certificate issuance and
predating
o Added an explicit client-side parameter for predating
o Security considerations around unauthenticated GET
A.2. 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.2. draft-ietf-acme-star-03 A.3. 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.3. draft-ietf-acme-star-02 A.4. 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.4. draft-ietf-acme-star-01 A.5. 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.5. draft-ietf-acme-star-00 A.6. 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.6. draft-sheffer-acme-star-02 A.7. 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.7. draft-sheffer-acme-star-01 A.8. draft-sheffer-acme-star-01
o A terminology section. o A terminology section.
o Some cleanup. o Some cleanup.
A.8. draft-sheffer-acme-star-00 A.9. 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.9. draft-sheffer-acme-star-lurk-00 A.10. 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
skipping to change at page 22, line 36 skipping to change at page 25, line 4
Diego Lopez Diego Lopez
Telefonica I+D Telefonica I+D
EMail: diego.r.lopez@telefonica.com EMail: diego.r.lopez@telefonica.com
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica I+D Telefonica I+D
EMail: oscar.gonzalezdedios@telefonica.com EMail: oscar.gonzalezdedios@telefonica.com
Antonio Agustin Pastor Perales Antonio Agustin Pastor Perales
Telefonica I+D Telefonica I+D
EMail: antonio.pastorperales@telefonica.com EMail: antonio.pastorperales@telefonica.com
Thomas Fossati Thomas Fossati
Nokia ARM
EMail: thomas.fossati@nokia.com EMail: thomas.fossati@arm.com
 End of changes. 40 change blocks. 
78 lines changed or deleted 187 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/