draft-ietf-acme-star-02.txt   draft-ietf-acme-star-03.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: June 2, 2018 O. Gonzalez de Dios Expires: September 4, 2018 O. Gonzalez de Dios
A. Pastor Perales A. Pastor Perales
Telefonica I+D Telefonica I+D
T. Fossati T. Fossati
Nokia Nokia
November 29, 2017 March 03, 2018
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-02 draft-ietf-acme-star-03
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 attacker. that is, when the associated private key is exposed to an attacker.
However the revocation process is often unreliable. An alternative However the revocation process is often unreliable. An alternative
to revocation is issuing a sequence of certificates, each with a to revocation is issuing a sequence of certificates, each with a
short validity period, and terminating this sequence upon compromise. short validity period, and terminating this sequence upon compromise.
This memo proposes an ACME extension to enable the issuance of short- This memo proposes an ACME extension to enable the issuance of short-
term and automatically renewed (STAR) certificates. term and automatically renewed (STAR) certificates.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 June 2, 2018. This Internet-Draft will expire on September 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
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
4. Operational Considerations . . . . . . . . . . . . . . . . . 11 4. Operational Considerations . . . . . . . . . . . . . . . . . 11
4.1. Define "short" . . . . . . . . . . . . . . . . . . . . . 11 4.1. Short Term and the Impact of Skewed Clocks . . . . . . . 11
4.2. Clock Skew . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Impact on Certificate Transparency (CT) Logs . . . . . . 11
4.3. Certificate Transparency (CT) Logs . . . . . . . . . . . 11 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 12
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. ACME Server with STAR extension . . . . . . . . . . . 12 5.1.1. ACME Server with STAR extension . . . . . . . . . . . 12
5.1.2. STAR Proxy . . . . . . . . . . . . . . . . . . . . . 12 5.1.2. STAR Proxy . . . . . . . . . . . . . . . . . . . . . 13
5.2. Level of Maturity . . . . . . . . . . . . . . . . . . . . 13 5.2. Level of Maturity . . . . . . . . . . . . . . . . . . . . 13
5.3. Coverage . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Coverage . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. Version Compatibility . . . . . . . . . . . . . . . . . . 13 5.4. Version Compatibility . . . . . . . . . . . . . . . . . . 13
5.5. Licensing . . . . . . . . . . . . . . . . . . . . . . . . 13 5.5. Licensing . . . . . . . . . . . . . . . . . . . . . . . . 14
5.6. Implementation experience . . . . . . . . . . . . . . . . 13 5.6. Implementation experience . . . . . . . . . . . . . . . . 14
5.7. Contact Information . . . . . . . . . . . . . . . . . . . 14 5.7. Contact Information . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. New ACME Error Types . . . . . . . . . . . . . . . . . . 14 6.1. New ACME Error Types . . . . . . . . . . . . . . . . . . 14
6.2. New ACME Order Object Fields . . . . . . . . . . . . . . 14 6.2. New ACME Order Object Fields . . . . . . . . . . . . . . 15
6.3. Not-Before and Not-After HTTP Headers . . . . . . . . . . 15 6.3. Not-Before and Not-After HTTP Headers . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7.1. Denial of Service Considerations . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Denial of Service Considerations . . . . . . . . . . . . 16
7.2. Additional Considerations TBD . . . . . . . . . . . . . . 16 7.2. Additional Considerations TBD . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Document History . . . . . . . . . . . . . . . . . . 18 Appendix A. Document History . . . . . . . . . . . . . . . . . . 19
A.1. draft-ietf-acme-star-02 . . . . . . . . . . . . . . . . . 18 A.1. draft-ietf-acme-star-03 . . . . . . . . . . . . . . . . . 19
A.2. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 18 A.2. draft-ietf-acme-star-02 . . . . . . . . . . . . . . . . . 19
A.3. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 18 A.3. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 19
A.4. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 18 A.4. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 19
A.5. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 18 A.5. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 19
A.6. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 18 A.6. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 19
A.7. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 19 A.7. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 A.8. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 Identity Owner or IdO). issuing a certificate to a named entity (an Identity Owner or IdO).
Typically, but not always, the identity is a domain name and we may Typically, but not always, the identity is a domain name and we may
refer to the entity as a Domain Name Owner (DNO). refer to the entity as a Domain Name Owner (DNO).
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 7 skipping to change at page 11, line 7
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 certificate endpoint. The (Forbidden) to any requests to the 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". "urn:ietf:params:acme:error:recurrentOrderExpired".
4. Operational Considerations 4. Operational Considerations
4.1. Define "short" 4.1. Short Term and the Impact of Skewed Clocks
TBD "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
practice, the expected lifetime of a STAR certificate will be counted
in minutes, hours or days, depending on different factors: the
underlying requirements for revocation, how much clock
synchronization is expected among relying parties and the issuing CA,
etc.
o Short is a relative concept: defining a cut-off point in this Nevertheless, this section attempts to provide reasonable suggestions
document would be arbitrary. The lifetime of a STAR certificate for the Web use case, informed by current operational and research
is defined by the requirements for revocation on a case by case experience.
basis.
4.2. Clock Skew Acer et al. [Acer] find that one of the main causes of "HTTPS error"
warnings in browers is misconfigured client clocks. In particular,
they observe that roughly 95% of the "severe" clock skews - the 6.7%
of clock-related breakage reports which account for clients that are
more than 24 hours behind - happen to be within 6-7 days.
TBD In order to avoid these spurious warnings about a not (yet) valid
server certificate, it is RECOMMENDED that site owners pre-date their
Web facing certificates by 5 to 7 days. The exact number depends on
the percentage of the "clock-skewed" population that the site owner
expects to protect - 5 days cover 97.3%, 7 days cover 99.6%. Note
that exact choice is also likely to depend on the kind of clients
that is prevalent for a given site or app - for example, Android and
Mac OS clients are known to behave better than Windows clients.
These considerations are clearly out of scope of the present
document.
o tweaking notBefore (maybe reference [I-D.nir-saag-star]) In terms of security, STAR certificates and certificates with OCSP
o Browser use case: to select the lower bound for short-term (5-7 must-staple [RFC7633] can be considered roughly equivalent if the
days) see Section 7.1 of [Acer]. 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
is RECOMMENDED that a STAR certificate that is used on the Web has an
"effective" lifetime (excluding any pre-dating to account for clock
skews) no longer than 4 days.
4.3. Certificate Transparency (CT) Logs 4.2. Impact on Certificate Transparency (CT) Logs
TBD Provided that the recommendations in Section 4.1 are followed, the
increase in Certificate Transparency (CT) [RFC6962] log ingestion
should be one order of magnitude in the worst case compared to the
current state.
o Browser use case only: STAR increase in CT log ingestion rate The input received from most members of the CT community when the
(quantify). How to deal with it is not part of this document. issue was raised was that this should not represent a problem for the
CT architecture.
5. Implementation Status 5. Implementation Status
Note to RFC Editor: please remove this section before publication, Note to RFC Editor: please remove this section before publication,
including the reference to [RFC7942]. including the reference to [RFC7942].
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
skipping to change at page 16, line 22 skipping to change at page 17, line 10
endorsement. endorsement.
Thanks to Jon Peterson and Martin Thomson for helpful comments and Thanks to Jon Peterson and Martin Thomson for helpful comments and
discussions that have shaped this document. 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., and J. Kasten, "Automatic Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Certificate Management Environment (ACME)", draft-ietf- Kasten, "Automatic Certificate Management Environment
acme-acme-08 (work in progress), October 2017. (ACME)", draft-ietf-acme-acme-09 (work in progress),
December 2017.
[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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. 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 17, line 16 skipping to change at page 18, line 5
Nir, Y., Fossati, T., and Y. Sheffer, "Considerations For Nir, Y., Fossati, T., and Y. Sheffer, "Considerations For
Using Short Term Certificates", draft-nir-saag-star-00 Using Short Term Certificates", draft-nir-saag-star-00
(work in progress), October 2017. (work in progress), October 2017.
[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-01 (work in progress), June 2017. acme-star-request-01 (work in progress), June 2017.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/info/rfc6962>.
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
Feature Extension", RFC 7633, DOI 10.17487/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>.
[Stark] Stark, E., Huang, L., Israni, D., Jackson, C., and D.
Boneh, "The case for prefetching and prevalidating TLS
server certificates", 2012,
<http://crypto.stanford.edu/~dabo/pubs/abstracts/
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>.
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-02 A.1. draft-ietf-acme-star-03
o Clock skew considerations
o Recommendations for "short" in the Web use case
o CT log considerations
A.2. 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.2. draft-ietf-acme-star-01 A.3. 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.3. draft-ietf-acme-star-00 A.4. 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.4. draft-sheffer-acme-star-02 A.5. 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.5. draft-sheffer-acme-star-01 A.6. draft-sheffer-acme-star-01
o A terminology section. o A terminology section.
o Some cleanup. o Some cleanup.
A.6. draft-sheffer-acme-star-00 A.7. 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.7. draft-sheffer-acme-star-lurk-00 A.8. 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. 30 change blocks. 
52 lines changed or deleted 100 lines changed or added

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