idnits 2.17.1 draft-ietf-acme-star-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 12, 2017) is 2358 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-08 ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7807 (Obsoleted by RFC 9457) == Outdated reference: A later version (-01) exists of draft-nir-saag-star-00 == Outdated reference: A later version (-02) exists of draft-sheffer-acme-star-request-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACME Working Group Y. Sheffer 3 Internet-Draft Intuit 4 Intended status: Standards Track D. Lopez 5 Expires: May 16, 2018 O. Gonzalez de Dios 6 A. Pastor Perales 7 Telefonica I+D 8 T. Fossati 9 Nokia 10 November 12, 2017 12 Support for Short-Term, Automatically-Renewed (STAR) Certificates in 13 Automated Certificate Management Environment (ACME) 14 draft-ietf-acme-star-01 16 Abstract 18 This memo proposes an ACME extension to enable the issuance of short- 19 term and automatically renewed certificates. 21 [RFC Editor: please remove before publication] 23 While the draft is being developed, the editor's version can be found 24 at https://github.com/yaronf/I-D/tree/master/STAR. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 16, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Name Delegation Use Case . . . . . . . . . . . . . . . . 3 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.3. Conventions used in this document . . . . . . . . . . . . 4 64 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.2. Refresh . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.3. Termination . . . . . . . . . . . . . . . . . . . . . . . 6 68 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 7 69 3.1. ACME Extensions . . . . . . . . . . . . . . . . . . . . . 7 70 3.1.1. Extending the Order Resource . . . . . . . . . . . . 7 71 3.1.2. Canceling a Recurrent Order . . . . . . . . . . . . . 8 72 3.2. Indicating Support of Recurrent Orders . . . . . . . . . 9 73 3.3. Fetching the Certificates . . . . . . . . . . . . . . . . 9 74 4. Operational Considerations . . . . . . . . . . . . . . . . . 10 75 4.1. Certificate Transparency (CT) Logs . . . . . . . . . . . 10 76 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 77 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 78 5.1.1. ACME Server with STAR extension . . . . . . . . . . . 11 79 5.1.2. Proxy STAR . . . . . . . . . . . . . . . . . . . . . 11 80 5.2. Level of Maturity . . . . . . . . . . . . . . . . . . . . 12 81 5.3. Coverage . . . . . . . . . . . . . . . . . . . . . . . . 12 82 5.4. Version Compatibility . . . . . . . . . . . . . . . . . . 12 83 5.5. Licensing . . . . . . . . . . . . . . . . . . . . . . . . 12 84 5.6. Implementation experience . . . . . . . . . . . . . . . . 12 85 5.7. Contact Information . . . . . . . . . . . . . . . . . . . 13 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 6.1. New ACME Error Types . . . . . . . . . . . . . . . . . . 13 88 6.2. New ACME Order Object Fields . . . . . . . . . . . . . . 13 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 93 9.2. Informative References . . . . . . . . . . . . . . . . . 14 94 Appendix A. Document History . . . . . . . . . . . . . . . . . . 16 95 A.1. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 16 96 A.2. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 16 97 A.3. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 16 98 A.4. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 16 99 A.5. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 16 100 A.6. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 103 1. Introduction 105 The ACME protocol [I-D.ietf-acme-acme] automates the process of 106 issuing a certificate to a Domain Name Owner (DNO). However, if the 107 DNO wishes to obtain a string of short-term certificates originating 108 from the same private key (see [Topalovic] for the rationale), she 109 must go through the whole ACME protocol each time a new short-term 110 certificate is needed - e.g., every 2-3 days. If done this way, the 111 process would involve frequent interactions between the registration 112 function of the ACME Certification Authority (CA) and the user's 113 backing infrastructure (e.g.: DNS, web servers), therefore making the 114 issuance of short-term certificates exceedingly dependent on the 115 reliability of both. 117 This document presents an extension of the ACME protocol that 118 optimizes this process by making short-term certificates first class 119 objects in the ACME ecosystem. Once the order for a string of short- 120 term certificates is accepted, the CA is responsible for publishing 121 the next certificate at an agreed upon URL before the previous one 122 expires. The DNO can terminate the automatic renewal before the 123 natural deadline, if needed - e.g., on key compromise. 125 For a more generic treatment of STAR certificates, readers are 126 referred to [I-D.nir-saag-star]. 128 1.1. Name Delegation Use Case 130 The proposed mechanism can be used as a building block of an 131 efficient name-delegation protocol, for example one that exists 132 between a CDN or a cloud provider and its users 133 [I-D.sheffer-acme-star-request], in a way that makes the delegator 134 (i.e., the DNO) in full control of the delegation by simply 135 instructing the CA to stop the automatic renewal and letting the 136 currently active certificate expire shortly thereafter. 138 1.2. Terminology 140 DNO Domain Name Owner, the owner of a domain. 141 STAR Short-Term, Automatically Renewed X.509 certificates. 142 NDC Name Delegation Client, an entity to which the domain name owned 143 by the DNO is delegated for a limited time. This might be a CDN 144 edge cache, a cloud provider's load balancer or Web Application 145 Firewall (WAF). 147 1.3. Conventions used in this document 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in 152 [RFC2119]. 154 2. Protocol Flow 156 The following subsections describe the three main phases of the 157 protocol: 159 o Bootstrap: the DNO asks an ACME CA to create a short-term and 160 automatically-renewed (STAR) certificate (Section 2.1); 161 o Auto-renewal: the ACME CA periodically re-issues the short-term 162 certificate and posts it to a public URL (Section 2.2); 163 o Termination: the DNO requests the ACME CA to discontinue the 164 automatic renewal of the certificate (Section 2.3). 166 This diagram presents the entities that are (or may be) involved in 167 the protocol and their interactions during the different phases. 169 Refresh 170 . . . . . . . . . . . . . . . . . . . . 171 . ' ` v 172 .-----. Bootstrap / Terminate .---------. 173 | DNO |------------------------------------->| ACME CA | 174 `-----' `---------' 175 ^ .- - -. ^ 176 ` . . . . . . . . : NDC : . . . . . . . . . ' 177 Request `- - -' Refresh 178 Delegation 180 Note that there might be a distinct NDC entity (e.g., a CDN edge 181 cache) that uses a separate channel to request the DNO to set up a 182 name delegation. The protocol described in 183 [I-D.sheffer-acme-star-request] might be used for this purpose. 185 2.1. Bootstrap 187 The DNO, in its role as an ACME client, requests the CA to issue a 188 STAR certificate, i.e., one that: 190 o Has a short validity (e.g., 24 to 72 hours); 191 o Is automatically renewed by the CA for a certain period of time; 192 o Is downloadable from a (highly available) public link without 193 requiring any special authorization. 195 Other than that, the ACME protocol flows as normal between DNO and 196 CA. In particular, DNO is responsible for satisfying the requested 197 ACME challenges until the CA is willing to issue the requested 198 certificate. Per normal ACME processing, the DNO is given back an 199 Order ID for the issued STAR certificate to be used in subsequent 200 interaction with the CA (e.g., if the certificate needs to be 201 terminated.) 203 The bootstrap phase ends when the DNO obtains the OK from the ACME 204 CA. 206 2.2. Refresh 208 The CA automatically re-issues the certificate using the same CSR 209 (and therefore the same name and public key) before it expires and 210 publishes it to the URL that was returned to the DNO at the end of 211 the bootstrap phase. The certificate user, which could be either the 212 DNO itself or a delegated third party, as described in 213 [I-D.sheffer-acme-star-request], obtains the certificate and uses it. 215 The refresh process (Figure 1) goes on until either: 217 o DNO terminates the delegation, or 218 o Automatic renewal expires. 220 Certificate ACME/STAR 221 User Server 222 | Retrieve cert | [...] 223 |---------------------->| | 224 | +------. / 225 | | | / 226 | | Automatic renewal : 227 | | | \ 228 | |<-----' \ 229 | Retrieve cert | | 230 |---------------------->| 72 hours 231 | | | 232 | +------. / 233 | | | / 234 | | Automatic renewal : 235 | | | \ 236 | |<-----' \ 237 | Retrieve cert | | 238 |---------------------->| 72 hours 239 | | | 240 | +------. / 241 | | | / 242 | | Automatic renewal : 243 | | | \ 244 | |<-----' \ 245 | | | 246 | [...] | [...] 248 Figure 1: Auto renewal 250 2.3. Termination 252 The DNO may request early termination of the STAR certificate by 253 including the Order ID in a certificate termination request to the 254 ACME interface, defined below. After the CA receives and verifies 255 the request, it shall: 257 o Cancel the automatic renewal process for the STAR certificate; 258 o Change the certificate publication resource to return an error 259 indicating the termination of the delegation to any external 260 client. 262 Note that it is not necessary to explicitly revoke the short-term 263 certificate. 265 STAR STAR ACME/STAR 266 Client Proxy Server 267 | | | 268 | | Terminate Order ID | 269 | +---------------------->| 270 | | +-------. 271 | | | | 272 | | | End auto renewal 273 | | | Remove cert link 274 | | | etc. 275 | | | | 276 | | Done |<------' 277 | |<----------------------+ 278 | | | 279 | | 280 | Retrieve cert | 281 +---------------------------------------------->| 282 | Error: terminated | 283 |<----------------------------------------------+ 284 | | 286 Figure 2: Termination 288 3. Protocol Details 290 This section describes the protocol details, namely the extensions to 291 the ACME protocol required to issue STAR certificates. 293 3.1. ACME Extensions 295 This protocol extends the ACME protocol, to allow for recurrent 296 orders. 298 3.1.1. Extending the Order Resource 300 The Order resource is extended with the following attributes: 302 { 303 "recurrent": true, 304 "recurrent-start-date": "2016-01-01T00:00:00Z", 305 "recurrent-end-date": "2017-01-01T00:00:00Z", 306 "recurrent-certificate-validity": 604800 307 } 309 o recurrent: MUST be "true" for STAR certificates. 310 o recurrent-start-date: the earliest date of validity of the first 311 certificate issued, in [RFC3339] format. This attribute is 312 optional. When omitted, the start date is as soon as 313 authorization is complete. 314 o recurrent-end-date: the latest date of validity of the last 315 certificate issued, in [RFC3339] format. 316 o recurrent-certificate-validity: the maximum validity period of 317 each STAR certificate, an integer that denotes a number of 318 seconds. 320 These attributes are included in a POST message when creating the 321 order, as part of the "payload" encoded object. They are returned 322 when the order has been created, and the ACME server MAY adjust them 323 at will, according to its local policy. 325 ACME defines the following values for the Order resource's status: 326 "invalid", "pending", "processing", "valid". In the case of 327 recurrent orders, the status MUST be "valid" as long as STAR 328 certificates are being issued. We add a new status value, 329 "canceled", see below. 331 3.1.2. Canceling a Recurrent Order 333 An important property of the recurrent Order is that it can be 334 canceled by the DNO, with no need for certificate revocation. To 335 cancel the Order, the ACME client sends a POST: 337 POST /acme/order/1 HTTP/1.1 338 Host: acme-server.example.org 339 Content-Type: application/jose+json 341 { 342 "protected": base64url({ 343 "alg": "ES256", 344 "kid": "https://example.com/acme/acct/1", 345 "nonce": "5XJ1L3lEkMG7tR6pA00clA", 346 "url": "https://example.com/acme/order/1" 347 }), 348 "payload": base64url({ 349 "status": "canceled" 350 }), 351 "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" 352 } 354 The server MUST NOT issue any additional certificates for this Order, 355 beyond the certificate that is available for collection at the time 356 of deletion. Immediately after the Order is canceled, the server 357 SHOULD respond with 403 (Forbidden) to any requests to the 358 certificate endpoint. The response SHOULD provide additional 359 information using a problem document [RFC7807] with type 360 "urn:ietf:params:acme:error:recurrentOrderCanceled". 362 3.2. Indicating Support of Recurrent Orders 364 ACME supports sending arbitrary extensions when creating an Order, 365 and as a result, there is no need to explicitly indicate support of 366 this extension. The DNO MUST verify that the "recurrent" attribute 367 was understood, as indicated by the "recurrent" attribute included by 368 the CA in the created Order. Since the standard ACME protocol does 369 not allow to explicitly cancel a pending Order (the POST operation in 370 Section 3.1.2 is an extension), a DNO that encounters an non- 371 supporting server will probably let the Order expire instead of 372 following through with the authorization process. 374 3.3. Fetching the Certificates 376 The certificate is fetched from the certificate endpoint, as per 377 [I-D.ietf-acme-acme], Section 7.4.2. 379 GET /acme/cert/asdf HTTP/1.1 380 Host: acme-server.example.org 381 Accept: application/pkix-cert 383 HTTP/1.1 200 OK 384 Content-Type: application/pem-certificate-chain 385 Link: ;rel="index" 386 Not-Before: Mon, 1 Feb 2016 00:00:00 GMT 387 Not-After: Mon, 8 Feb 2016 00:00:00 GMT 389 -----BEGIN CERTIFICATE----- 390 [End-entity certificate contents] 391 -----END CERTIFICATE----- 392 -----BEGIN CERTIFICATE----- 393 [Issuer certificate contents] 394 -----END CERTIFICATE----- 395 -----BEGIN CERTIFICATE----- 396 [Other certificate contents] 397 -----END CERTIFICATE----- 399 The Server SHOULD include the "Not-Before" and "Not-After" headers. 400 When they exist, they MUST be equal to the respective fields inside 401 the certificate. Their format is "HTTP-date" as defined in 402 Section 7.1.1.2 of [RFC7231]. Their purpose is to enable client 403 implementations that do not parse the certificate. 405 To improve robustness, the next certificate MUST be made available by 406 the ACME CA at the latest halfway through the lifetime of the 407 currently active certificate. It is worth noting that this has an 408 implication in case of cancellation: in fact, from the time the next 409 certificate is made available, the cancellation is not completely 410 effective until the latter also expires. 412 The server MUST NOT issue any additional certificates for this Order 413 beyond its recurrent-end-date. 415 Immediately after the Order expires, the server SHOULD respond with 416 403 (Forbidden) to any requests to the certificate endpoint. The 417 response SHOULD provide additional information using a problem 418 document [RFC7807] with type 419 "urn:ietf:params:acme:error:recurrentOrderExpired". 421 4. Operational Considerations 423 4.1. Certificate Transparency (CT) Logs 425 TBD: larger logs and how to deal with them. 427 5. Implementation Status 429 Note to RFC Editor: please remove this section before publication, 430 including the reference to [RFC7942]. 432 This section records the status of known implementations of the 433 protocol defined by this specification at the time of posting of this 434 Internet-Draft, and is based on a proposal described in [RFC7942]. 435 The description of implementations in this section is intended to 436 assist the IETF in its decision processes in progressing drafts to 437 RFCs. Please note that the listing of any individual implementation 438 here does not imply endorsement by the IETF. Furthermore, no effort 439 has been spent to verify the information presented here that was 440 supplied by IETF contributors. This is not intended as, and must not 441 be construed to be, a catalog of available implementations or their 442 features. Readers are advised to note that other implementations may 443 exist. 445 According to [RFC7942], "this will allow reviewers and working groups 446 to assign due consideration to documents that have the benefit of 447 running code, which may serve as evidence of valuable experimentation 448 and feedback that have made the implemented protocols more mature. 449 It is up to the individual working groups to use this information as 450 they see fit". 452 5.1. Overview 454 The implementation is constructed around 3 elements: Client STAR for 455 NDC, Proxy STAR for DNO and Server ACME for CA. The communication 456 between them is over an IP network and the HTTPS protocol. 458 The software of the implementation is available at: 459 https://github.com/mami-project/lurk 461 The following subsections offer a basic description, detailed 462 information is available in https://github.com/mami- 463 project/lurk/blob/master/proxySTAR_v1/README.md 465 5.1.1. ACME Server with STAR extension 467 This is a fork of the Let's Encrypt Boulder project that implements 468 an ACME compliant CA. It includes modifications to extend the ACME 469 protocol as it is specified in this draft, to support recurrent 470 orders and cancelling orders. 472 The implementation understands the new "recurrent" attributes as part 473 of the Certificate issuance in the POST request for a new resource. 474 An additional process "renewalManager.go" has been included in 475 parallel that reads the details of each recurrent request, 476 automatically produces a "cron" Linux based task that issues the 477 recurrent certificates, until the lifetime ends or the order is 478 canceled. This process is also in charge of maintaining a fixed URI 479 to enable the NDC to download certificates, unlike Boulder's regular 480 process of producing a unique URI per certificate. 482 5.1.2. Proxy STAR 484 The Proxy STAR, has a double role as ACME client and STAR Server. 485 The former is a fork of the EFF Certbot project that implements an 486 ACME compliant client with the STAR extension. The latter is a basic 487 HTTP REST API server. 489 The proxy STAR understands the basic API request with a server. The 490 current implementation of the API is defined in draft-sheffer-acme- 491 star-request-00. Registration or order cancellation triggers the 492 modified Certbot client that requests, or cancels, the recurrent 493 generation of certificates using the STAR extension over ACME 494 protocol. The URI with the location of the recurrent certificate is 495 delivered to the STAR client as a response. 497 5.2. Level of Maturity 499 This is a prototype. 501 5.3. Coverage 503 Client STAR is not included in this implementation, but done by 504 direct HTTP request with any open HTTP REST API tool. This is 505 expected to be covered as part of [I-D.sheffer-acme-star-request] 506 implementation. 508 This implementation completely covers Proxy STAR and Server ACME with 509 STAR extension 511 5.4. Version Compatibility 513 The implementation is compatible with version draft-ietf-acme-star- 514 00. The implementation is based on the Boulder and Certbot code 515 release from 7-Aug-2017. 517 5.5. Licensing 519 This implementation inherits the Boulder license (Mozilla Public 520 License 2.0) and Certbot license (Apache License Version 2.0 ). 522 5.6. Implementation experience 524 To prove the concept all the implementation has been done with a 525 self-signed CA, to avoid impact on real domains. To be able to do it 526 we use the FAKE_DNS property of Boulder and static /etc/hosts entries 527 with domains names. Nonetheless this implementation should run with 528 real domains. 530 Most of the implementation has been made to avoid deep changes inside 531 of Boulder or Certbot, for example, the recurrent certificates 532 issuance by the CA is based on an external process that auto- 533 configures the standard Linux "cron" daemon in the ACME CA server. 535 The reference setup recommended is one physical host with 3 virtual 536 machines, one for each of the 3 components (client, proxy and server) 537 and the connectivity based on host bridge. 539 No security is enabled (iptables default policies are "accept" and 540 all rules removed) in this implementation to simplify and test the 541 protocol. 543 5.7. Contact Information 545 See author details below. 547 6. IANA Considerations 549 [[RFC Editor: please replace XXXX below by the RFC number.]] 551 6.1. New ACME Error Types 553 This document adds the following entry to the ACME Error Type 554 registry: 556 +------------------------+------------------------------+-----------+ 557 | Type | Description | Reference | 558 +------------------------+------------------------------+-----------+ 559 | recurrentOrderCanceled | The short-term certificate | RFC XXXX | 560 | | is no longer available | | 561 | | because the recurrent order | | 562 | | has been explicitly canceled | | 563 | | by the DNO | | 564 | recurrentOrderExpired | The short-term certificate | RFC XXXX | 565 | | is no longer available | | 566 | | because the recurrent order | | 567 | | has expired | | 568 +------------------------+------------------------------+-----------+ 570 6.2. New ACME Order Object Fields 572 This document adds the following entries to the ACME Order Object 573 Fields registry: 575 +-------------------------------+--------+--------------+-----------+ 576 | Field Name | Field | Configurable | Reference | 577 | | Type | | | 578 +-------------------------------+--------+--------------+-----------+ 579 | recurrent | string | true | RFC XXXX | 580 | recurrent-start-date | string | true | RFC XXXX | 581 | recurrent-end-date | string | true | RFC XXXX | 582 | recurrent-certificate- | string | true | RFC XXXX | 583 | validity | | | | 584 +-------------------------------+--------+--------------+-----------+ 586 7. Security Considerations 588 TBD 590 8. Acknowledgments 592 This work is partially supported by the European Commission under 593 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 594 for a Middleboxed Internet (MAMI). This support does not imply 595 endorsement. 597 9. References 599 9.1. Normative References 601 [I-D.ietf-acme-acme] 602 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 603 Certificate Management Environment (ACME)", draft-ietf- 604 acme-acme-08 (work in progress), October 2017. 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, 608 DOI 10.17487/RFC2119, March 1997, . 611 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 612 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 613 . 615 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 616 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 617 DOI 10.17487/RFC7231, June 2014, . 620 [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP 621 APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, 622 . 624 9.2. Informative References 626 [I-D.nir-saag-star] 627 Nir, Y., Fossati, T., and Y. Sheffer, "Considerations For 628 Using Short Term Certificates", draft-nir-saag-star-00 629 (work in progress), October 2017. 631 [I-D.sheffer-acme-star-request] 632 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 633 Fossati, "Generating Certificate Requests for Short-Term, 634 Automatically-Renewed (STAR) Certificates", draft-sheffer- 635 acme-star-request-01 (work in progress), June 2017. 637 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 638 Code: The Implementation Status Section", BCP 205, 639 RFC 7942, DOI 10.17487/RFC7942, July 2016, 640 . 642 [Topalovic] 643 Topalovic, E., Saeta, B., Huang, L., Jackson, C., and D. 644 Boneh, "Towards Short-Lived Certificates", 2012, 645 . 647 Appendix A. Document History 649 [[Note to RFC Editor: please remove before publication.]] 651 A.1. draft-ietf-acme-star-01 653 o Generalized the introduction, separating out the specifics of 654 CDNs. 655 o Clean out LURK-specific text. 656 o Using a POST to ensure cancellation is authenticated. 657 o First and last date of recurrent cert, as absolute dates. 658 Validity of certs in seconds. 659 o Use RFC7807 "Problem Details" in error responses. 660 o Add IANA considerations. 661 o Changed the document's title. 663 A.2. draft-ietf-acme-star-00 665 o Initial working group version. 666 o Removed the STAR interface, the protocol between NDC and DNO. 667 What remains is only the extended ACME protocol. 669 A.3. draft-sheffer-acme-star-02 671 o Using a more generic term for the delegation client, NDC. 672 o Added an additional use case: public cloud services. 673 o More detail on ACME authorization. 675 A.4. draft-sheffer-acme-star-01 677 o A terminology section. 678 o Some cleanup. 680 A.5. draft-sheffer-acme-star-00 682 o Renamed draft to prevent confusion with other work in this space. 683 o Added an initial STAR protocol: a REST API. 684 o Discussion of CDNI use cases. 686 A.6. draft-sheffer-acme-star-lurk-00 688 o Initial version. 690 Authors' Addresses 691 Yaron Sheffer 692 Intuit 694 EMail: yaronf.ietf@gmail.com 696 Diego Lopez 697 Telefonica I+D 699 EMail: diego.r.lopez@telefonica.com 701 Oscar Gonzalez de Dios 702 Telefonica I+D 704 EMail: oscar.gonzalezdedios@telefonica.com 706 Antonio Agustin Pastor Perales 707 Telefonica I+D 709 EMail: antonio.pastorperales@telefonica.com 711 Thomas Fossati 712 Nokia 714 EMail: thomas.fossati@nokia.com