draft-ietf-acme-star-07.txt   draft-ietf-acme-star-08.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: February 21, 2020 O. Gonzalez de Dios Expires: February 29, 2020 O. Gonzalez de Dios
A. Pastor Perales A. Pastor Perales
Telefonica I+D Telefonica I+D
T. Fossati T. Fossati
ARM ARM
August 20, 2019 August 28, 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-07 draft-ietf-acme-star-08
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 February 21, 2020. This Internet-Draft will expire on February 29, 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 3, line 19 skipping to change at page 3, line 19
6.4. Cert-Not-Before and Cert-Not-After HTTP Headers . . . . . 20 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 . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . 22 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-07 . . . . . . . . . . . . . . . . . 24 A.1. draft-ietf-acme-star-08 . . . . . . . . . . . . . . . . . 24
A.2. draft-ietf-acme-star-06 . . . . . . . . . . . . . . . . . 24 A.2. draft-ietf-acme-star-07 . . . . . . . . . . . . . . . . . 24
A.3. draft-ietf-acme-star-05 . . . . . . . . . . . . . . . . . 24 A.3. draft-ietf-acme-star-06 . . . . . . . . . . . . . . . . . 24
A.4. draft-ietf-acme-star-04 . . . . . . . . . . . . . . . . . 24 A.4. draft-ietf-acme-star-05 . . . . . . . . . . . . . . . . . 24
A.5. draft-ietf-acme-star-03 . . . . . . . . . . . . . . . . . 24 A.5. draft-ietf-acme-star-04 . . . . . . . . . . . . . . . . . 24
A.6. draft-ietf-acme-star-02 . . . . . . . . . . . . . . . . . 24 A.6. draft-ietf-acme-star-03 . . . . . . . . . . . . . . . . . 24
A.7. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 24 A.7. draft-ietf-acme-star-02 . . . . . . . . . . . . . . . . . 24
A.8. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 25 A.8. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 25
A.9. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 25 A.9. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 25
A.10. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 25 A.10. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 25
A.11. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 25 A.11. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 25
A.12. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 25 A.12. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 25
A.13. 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 15, line 28 skipping to change at page 15, line 28
In terms of security, STAR certificates and certificates with OCSP In terms of security, STAR certificates and certificates with OCSP
must-staple [RFC7633] can be considered roughly equivalent if the must-staple [RFC7633] can be considered roughly equivalent if the
STAR certificate's and the OCSP response's lifetimes are the same. STAR certificate's and the OCSP response's lifetimes are the same.
Given OCSP responses can be cached on average for 4 days [Stark], it Given OCSP responses can be cached on average for 4 days [Stark], it
is RECOMMENDED that a STAR certificate that is used on the Web has an is RECOMMENDED that a STAR certificate that is used on the Web has an
"effective" lifetime (excluding any pre-dating to account for clock "effective" lifetime (excluding any pre-dating to account for clock
skews) no longer than 4 days. skews) no longer than 4 days.
4.2. Impact on Certificate Transparency (CT) Logs 4.2. Impact on Certificate Transparency (CT) Logs
Provided that the recommendations in Section 4.1 are followed, the Even in the highly unlikely case STAR becomes the only certificate
increase in Certificate Transparency (CT) [RFC6962] log ingestion issuance model, discussion with the IETF TRANS Working Group and
should be one order of magnitude in the worst case compared to the Certificate Transparency (CT) logs implementers suggests that
current state. existing CT Log Server implementations are capable of sustaining the
resulting 100-fold increase in ingestion rate. Additionally, such a
The input received from most members of the CT community when the future, higher load could be managed with a variety of techniques
issue was raised was that this should not represent a problem for the (e.g., sharding by modulo of certificate hash, using "smart" load-
CT architecture. balancing CT proxies, etc.). With regards to the increase in the log
size, current CT log growth is already being managed with schemes
like Chrome's Log Policy [OBrien] which allow Operators to define
their log life-cycle; and allowing the CAs, User Agents, Monitors,
and any other interested entities to build-in support for that life-
cycle ahead of time.
4.3. Dependability 4.3. Dependability
When using authenticated POST-as-GET, the HTTPS endpoint from where When using authenticated POST-as-GET, the HTTPS endpoint from where
the STAR certificate is fetched can't be easily replicated by an on- the STAR certificate is fetched can't be easily replicated by an on-
path HTTP cache. Reducing the caching properties of the protocol path HTTP cache. Reducing the caching properties of the protocol
makes STAR clients increasingly dependent on the ACME server makes STAR clients increasingly dependent on the ACME server
availability. This might be problematic given the relatively high availability. This might be problematic given the relatively high
rate of client-server interactions in a STAR ecosystem. Clients and rate of client-server interactions in a STAR ecosystem. Clients and
servers should consider using the mechanism described in Section 3.4 servers should consider using the mechanism described in Section 3.4
skipping to change at page 21, line 44 skipping to change at page 21, line 44
a non-guessable way, for example using capability URLs a non-guessable way, for example using capability URLs
[W3C.WD-capability-urls-20140218]. [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 Roman Danyliw, Jon Peterson, Eric Rescorla, Sean Turner and Thanks to Roman Danyliw, Jon Peterson, Eric Rescorla, Sean Turner,
Martin Thomson for helpful comments and discussions that have shaped Martin Thomson and Mehmet Ersue for helpful comments and discussions
this document. that have shaped this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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:
skipping to change at page 22, line 44 skipping to change at page 22, line 44
[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
ACME Profile for Generating Delegated STAR Certificates", ACME Profile for Generating Delegated STAR Certificates",
draft-ietf-acme-star-delegation-00 (work in progress), draft-ietf-acme-star-delegation-01 (work in progress),
December 2018. August 2019.
[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.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [OBrien] O'Brien, D. and R. Sleevi, "Chromium Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency Log Policy", 2017,
<https://www.rfc-editor.org/info/rfc6962>. <https://github.com/chromium/ct-policy>.
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
Feature Extension", RFC 7633, DOI 10.17487/RFC7633, Feature Extension", RFC 7633, DOI 10.17487/RFC7633,
October 2015, <https://www.rfc-editor.org/info/rfc7633>. October 2015, <https://www.rfc-editor.org/info/rfc7633>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
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-07 A.1. draft-ietf-acme-star-08
o Improved text on interaction with CT Logs, responding to Mehmet
Ersue's review.
A.2. draft-ietf-acme-star-07
o Changed the HTTP headers names and clarified the IANA o Changed the HTTP headers names and clarified the IANA
registration, following feedback from the IANA expert reviewer registration, following feedback from the IANA expert reviewer
A.2. draft-ietf-acme-star-06 A.3. draft-ietf-acme-star-06
o Roman's AD review o Roman's AD review
A.3. draft-ietf-acme-star-05 A.4. 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.4. draft-ietf-acme-star-04 A.5. 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.5. draft-ietf-acme-star-03 A.6. 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.6. draft-ietf-acme-star-02 A.7. 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.7. draft-ietf-acme-star-01 A.8. 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.8. draft-ietf-acme-star-00 A.9. 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.9. draft-sheffer-acme-star-02 A.10. 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.10. draft-sheffer-acme-star-01 A.11. draft-sheffer-acme-star-01
o A terminology section. o A terminology section.
o Some cleanup. o Some cleanup.
A.11. draft-sheffer-acme-star-00 A.12. 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.12. draft-sheffer-acme-star-lurk-00 A.13. 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
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
 End of changes. 24 change blocks. 
46 lines changed or deleted 56 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/