draft-ietf-acme-star-06.txt   draft-ietf-acme-star-07.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: January 2, 2020 O. Gonzalez de Dios Expires: February 21, 2020 O. Gonzalez de Dios
A. Pastor Perales A. Pastor Perales
Telefonica I+D Telefonica I+D
T. Fossati T. Fossati
ARM ARM
July 01, 2019 August 20, 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-06 draft-ietf-acme-star-07
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 January 2, 2020. This Internet-Draft will expire on February 21, 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 37 skipping to change at page 2, line 37
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 . . . . . . . . . . . . . 8 3.1.2. Canceling a Recurrent Order . . . . . . . . . . . . . 8
3.2. Capability Discovery . . . . . . . . . . . . . . . . . . 9 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 . . 13
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 . . . . . . . . . . . . . . . . . . . . 16
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . 19 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 20
6.4. Not-Before and Not-After HTTP Headers . . . . . . . . . . 19 6.4. Cert-Not-Before and Cert-Not-After HTTP Headers . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7.1. No revocation . . . . . . . . . . . . . . . . . . . . . . 20 7.1. No revocation . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Denial of Service Considerations . . . . . . . . . . . . 20 7.2. Denial of Service Considerations . . . . . . . . . . . . 21
7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 21 7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Document History . . . . . . . . . . . . . . . . . . 24 Appendix A. Document History . . . . . . . . . . . . . . . . . . 24
A.1. draft-ietf-acme-star-06 . . . . . . . . . . . . . . . . . 24 A.1. draft-ietf-acme-star-07 . . . . . . . . . . . . . . . . . 24
A.2. draft-ietf-acme-star-05 . . . . . . . . . . . . . . . . . 24 A.2. draft-ietf-acme-star-06 . . . . . . . . . . . . . . . . . 24
A.3. draft-ietf-acme-star-04 . . . . . . . . . . . . . . . . . 24 A.3. draft-ietf-acme-star-05 . . . . . . . . . . . . . . . . . 24
A.4. draft-ietf-acme-star-03 . . . . . . . . . . . . . . . . . 24 A.4. draft-ietf-acme-star-04 . . . . . . . . . . . . . . . . . 24
A.5. draft-ietf-acme-star-02 . . . . . . . . . . . . . . . . . 24 A.5. draft-ietf-acme-star-03 . . . . . . . . . . . . . . . . . 24
A.6. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 24 A.6. draft-ietf-acme-star-02 . . . . . . . . . . . . . . . . . 24
A.7. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 25 A.7. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 24
A.8. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 25 A.8. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 25
A.9. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 25 A.9. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 25
A.10. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 25 A.10. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 25
A.11. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 25 A.11. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 25
A.12. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The ACME protocol [RFC8555] automates the process of issuing a The ACME protocol [RFC8555] automates the process of 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
skipping to change at page 11, line 12 skipping to change at page 11, line 12
a GET to the star-certificate resource without authenticating itself a GET to the star-certificate resource without authenticating itself
to the server as illustrated in Figure 5. 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 Cert-Not-Before: Mon, 1 Feb 2016 00:00:00 GMT
Not-After: Mon, 8 Feb 2016 00:00:00 GMT Cert-Not-After: Mon, 8 Feb 2016 00:00:00 GMT
-----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 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 "Cert-Not-Before" and "Cert-Not-After"
headers in the response. When they exist, they MUST be equal to the HTTP headers in the response. When they exist, they MUST be equal to
respective fields inside the end-entity certificate. Their format is the respective fields inside the end-entity certificate. Their
"HTTP-date" as defined in Section 7.1.1.2 of [RFC7231]. Their format is "HTTP-date" as defined in Section 7.1.1.2 of [RFC7231].
purpose is to enable client implementations that do not parse the Their purpose is to enable client implementations that do not parse
certificate. the certificate.
Following are further clarifications regarding usage of these
headers, as per [RFC7231] Sec. 8.3.1. All apply to both headers.
o This header is a single value, not a list.
o The header is used only in responses to GET, HEAD and POST-as-GET
requests, and only for MIME types that denote public key
certificates.
o Header semantics are independent of context.
o The header is not hop-by-hop.
o Intermediaries MAY insert or delete the value, but MUST ensure
that if present, the header value equals the corresponding value
within the credential.
o The header is not appropriate for a Vary field.
o The header is allowed within message trailers.
o The header is not appropriate within redirects.
o The header does not introduce additional security considerations.
It discloses in a simpler form information that is already
available inside the credential.
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. Note that the when it is published at the "star-certificate" URL. Note that the
skipping to change at page 19, line 39 skipping to change at page 20, line 19
+----------------------------+------------+-----------+ +----------------------------+------------+-----------+
| Field Name | Field Type | Reference | | Field Name | Field Type | Reference |
+----------------------------+------------+-----------+ +----------------------------+------------+-----------+
| star-enabled | boolean | RCF XXXX | | star-enabled | boolean | RCF XXXX |
| star-min-cert-validity | integer | RCF XXXX | | star-min-cert-validity | integer | RCF XXXX |
| star-max-renewal | integer | RCF XXXX | | star-max-renewal | integer | RCF XXXX |
| star-allow-certificate-get | boolean | RFC XXXX | | star-allow-certificate-get | boolean | RFC XXXX |
+----------------------------+------------+-----------+ +----------------------------+------------+-----------+
6.4. Not-Before and Not-After HTTP Headers 6.4. Cert-Not-Before and Cert-Not-After HTTP Headers
The "Message Headers" registry should be updated with the following The "Message Headers" registry should be updated with the following
additional values: additional values:
+-------------------+----------+----------+-----------+ +-------------------+----------+----------+-----------------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-----------+ +-------------------+----------+----------+-----------------------+
| Not-Before | http | standard | RFC XXXX | | Cert-Not-Before | http | standard | RFC XXXX, Section 3.3 |
| Not-After | http | standard | RFC XXXX | | Cert-Not-After | http | standard | RFC XXXX, Section 3.3 |
+-------------------+----------+----------+-----------+ +-------------------+----------+----------+-----------------------+
7. Security Considerations 7. Security Considerations
7.1. No revocation 7.1. No revocation
STAR certificates eliminate an important security feature of PKI STAR certificates eliminate an important security feature of PKI
which is the ability to revoke certificates. Revocation allows the which is the ability to revoke certificates. Revocation allows the
administrator to limit the damage done by a rogue node or an administrator to limit the damage done by a rogue node or an
adversary who has control of the private key. With STAR adversary who has control of the private key. With STAR
certificates, expiration replaces revocation so there is a timeliness certificates, expiration replaces revocation so there is a timeliness
skipping to change at page 24, line 9 skipping to change at page 24, line 9
[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-06 A.1. draft-ietf-acme-star-07
o Changed the HTTP headers names and clarified the IANA
registration, following feedback from the IANA expert reviewer
A.2. draft-ietf-acme-star-06
o Roman's AD review o Roman's AD review
A.2. draft-ietf-acme-star-05 A.3. 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.3. draft-ietf-acme-star-04 A.4. 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.4. draft-ietf-acme-star-03 A.5. 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.5. draft-ietf-acme-star-02 A.6. 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.6. draft-ietf-acme-star-01 A.7. 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.7. draft-ietf-acme-star-00 A.8. 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.8. draft-sheffer-acme-star-02 A.9. 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.9. draft-sheffer-acme-star-01 A.10. draft-sheffer-acme-star-01
o A terminology section. o A terminology section.
o Some cleanup. o Some cleanup.
A.10. draft-sheffer-acme-star-00 A.11. 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.11. draft-sheffer-acme-star-lurk-00 A.12. 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. 28 change blocks. 
49 lines changed or deleted 75 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/