idnits 2.17.1 draft-ietf-acme-star-11.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 (October 24, 2019) is 1646 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) -- Looks like a reference, but probably isn't: '0' on line 625 -- Looks like a reference, but probably isn't: '1' on line 625 -- Looks like a reference, but probably isn't: '2' on line 625 -- Looks like a reference, but probably isn't: '3' on line 625 ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7807 (Obsoleted by RFC 9457) == Outdated reference: A later version (-09) exists of draft-ietf-acme-star-delegation-01 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). 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: April 26, 2020 O. Gonzalez de Dios 6 A. Pastor Perales 7 Telefonica I+D 8 T. Fossati 9 ARM 10 October 24, 2019 12 Support for Short-Term, Automatically-Renewed (STAR) Certificates in 13 Automated Certificate Management Environment (ACME) 14 draft-ietf-acme-star-11 16 Abstract 18 Public-key certificates need to be revoked when they are compromised, 19 that is, when the associated private key is exposed to an 20 unauthorized entity. However the revocation process is often 21 unreliable. An alternative to revocation is issuing a sequence of 22 certificates, each with a short validity period, and terminating this 23 sequence upon compromise. This memo proposes an ACME extension to 24 enable the issuance of short-term and automatically renewed (STAR) 25 X.509 certificates. 27 [RFC Editor: please remove before publication] 29 While the draft is being developed, the editor's version can be found 30 at https://github.com/yaronf/I-D/tree/master/STAR. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 26, 2020. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Name Delegation Use Case . . . . . . . . . . . . . . . . 4 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Conventions used in this document . . . . . . . . . . . . 4 70 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.2. Refresh . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2.3. Termination . . . . . . . . . . . . . . . . . . . . . . . 6 74 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 7 75 3.1. ACME Extensions . . . . . . . . . . . . . . . . . . . . . 7 76 3.1.1. Extending the Order Resource . . . . . . . . . . . . 7 77 3.1.2. Canceling an Auto-renewal Order . . . . . . . . . . . 8 78 3.2. Capability Discovery . . . . . . . . . . . . . . . . . . 10 79 3.3. Fetching the Certificates . . . . . . . . . . . . . . . . 11 80 3.4. Negotiating an unauthenticated GET . . . . . . . . . . . 13 81 3.5. Computing notBefore and notAfter of STAR Certificates . . 14 82 3.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 15 83 4. Operational Considerations . . . . . . . . . . . . . . . . . 15 84 4.1. The Meaning of "Short Term" and the Impact of Skewed 85 Clocks . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 4.2. Impact on Certificate Transparency (CT) Logs . . . . . . 16 87 4.3. HTTP Caching and Dependability . . . . . . . . . . . . . 16 88 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 89 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17 90 5.1.1. ACME Server with STAR extension . . . . . . . . . . . 18 91 5.1.2. STAR Proxy . . . . . . . . . . . . . . . . . . . . . 18 92 5.2. Level of Maturity . . . . . . . . . . . . . . . . . . . . 18 93 5.3. Coverage . . . . . . . . . . . . . . . . . . . . . . . . 18 94 5.4. Version Compatibility . . . . . . . . . . . . . . . . . . 19 95 5.5. Licensing . . . . . . . . . . . . . . . . . . . . . . . . 19 96 5.6. Implementation experience . . . . . . . . . . . . . . . . 19 97 5.7. Contact Information . . . . . . . . . . . . . . . . . . . 19 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 99 6.1. New Registries . . . . . . . . . . . . . . . . . . . . . 19 100 6.2. New Error Types . . . . . . . . . . . . . . . . . . . . . 20 101 6.3. New fields in Order Objects . . . . . . . . . . . . . . . 20 102 6.4. Fields in the "auto-renewal" Object within an Order 103 Object . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 6.5. New fields in the "meta" Object within a Directory Object 21 105 6.6. Fields in the "auto-renewal" Object within a Directory 106 Metadata Object . . . . . . . . . . . . . . . . . . . . . 22 107 6.7. Cert-Not-Before and Cert-Not-After HTTP Headers . . . . . 22 108 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 109 7.1. No revocation . . . . . . . . . . . . . . . . . . . . . . 22 110 7.2. Denial of Service Considerations . . . . . . . . . . . . 23 111 7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 24 112 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 113 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 114 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 115 9.2. Informative References . . . . . . . . . . . . . . . . . 25 116 Appendix A. Document History . . . . . . . . . . . . . . . . . . 27 117 A.1. draft-ietf-acme-star-11 . . . . . . . . . . . . . . . . . 27 118 A.2. draft-ietf-acme-star-10 . . . . . . . . . . . . . . . . . 27 119 A.3. draft-ietf-acme-star-09 . . . . . . . . . . . . . . . . . 27 120 A.4. draft-ietf-acme-star-08 . . . . . . . . . . . . . . . . . 27 121 A.5. draft-ietf-acme-star-07 . . . . . . . . . . . . . . . . . 27 122 A.6. draft-ietf-acme-star-06 . . . . . . . . . . . . . . . . . 27 123 A.7. draft-ietf-acme-star-05 . . . . . . . . . . . . . . . . . 28 124 A.8. draft-ietf-acme-star-04 . . . . . . . . . . . . . . . . . 28 125 A.9. draft-ietf-acme-star-03 . . . . . . . . . . . . . . . . . 28 126 A.10. draft-ietf-acme-star-02 . . . . . . . . . . . . . . . . . 28 127 A.11. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 28 128 A.12. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 28 129 A.13. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 29 130 A.14. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 29 131 A.15. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 29 132 A.16. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 29 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 135 1. Introduction 137 The ACME protocol [RFC8555] automates the process of issuing a 138 certificate to a named entity (an Identifier Owner or IdO). 139 Typically, but not always, the identifier is a domain name. 141 If the IdO wishes to obtain a string of short-term certificates 142 originating from the same private key (see [Topalovic] about why 143 using short-lived certificates might be preferable to explicit 144 revocation), she must go through the whole ACME protocol each time a 145 new short-term certificate is needed - e.g., every 2-3 days. If done 146 this way, the process would involve frequent interactions between the 147 registration function of the ACME Certification Authority (CA) and 148 the identity provider infrastructure (e.g.: DNS, web servers), 149 therefore making the issuance of short-term certificates exceedingly 150 dependent on the reliability of both. 152 This document presents an extension of the ACME protocol that 153 optimizes this process by making short-term certificates first class 154 objects in the ACME ecosystem. Once the Order for a string of short- 155 term certificates is accepted, the CA is responsible for publishing 156 the next certificate at an agreed upon URL before the previous one 157 expires. The IdO can terminate the automatic renewal before the 158 negotiated deadline, if needed - e.g., on key compromise. 160 For a more generic treatment of STAR certificates, readers are 161 referred to [I-D.nir-saag-star]. 163 1.1. Name Delegation Use Case 165 The proposed mechanism can be used as a building block of an 166 efficient name-delegation protocol, for example one that exists 167 between a CDN or a cloud provider and its customers 168 [I-D.ietf-acme-star-delegation]. At any time, the service customer 169 (i.e., the IdO) can terminate the delegation by simply instructing 170 the CA to stop the automatic renewal and letting the currently active 171 certificate expire shortly thereafter. 173 Note that in the name delegation use case the delegated entity needs 174 to access the auto-renewed certificate without being in possession of 175 the ACME account key that was used for initiating the STAR issuance. 176 This leads to the optional use of unauthenticated GET in this 177 protocol (Section 3.4). 179 1.2. Terminology 181 IdO Identifier Owner, the owner of an identifier, e.g.: a domain 182 name, a telephone number. 183 STAR Short-Term and Automatically Renewed X.509 certificates. 185 1.3. Conventions used in this document 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in 190 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 191 capitals, as shown here. 193 2. Protocol Flow 195 The following subsections describe the three main phases of the 196 protocol: 198 o Bootstrap: the IdO asks an ACME CA to create a short-term and 199 automatically-renewed (STAR) certificate (Section 2.1); 200 o Auto-renewal: the ACME CA periodically re-issues the short-term 201 certificate and posts it to the star-certificate URL 202 (Section 2.2); 203 o Termination: the IdO requests the ACME CA to discontinue the 204 automatic renewal of the certificate (Section 2.3). 206 2.1. Bootstrap 208 The IdO, in its role as an ACME client, requests the CA to issue a 209 STAR certificate, i.e., one that: 211 o Has a short validity, e.g., 24 to 72 hours. Note that the exact 212 definition of "short" depends on the use case; 213 o Is automatically renewed by the CA for a certain period of time; 214 o Is downloadable from a (highly available) location. 216 Other than that, the ACME protocol flows as usual between IdO and CA. 217 In particular, IdO is responsible for satisfying the requested ACME 218 challenges until the CA is willing to issue the requested 219 certificate. Per normal ACME processing, the IdO is given back an 220 Order resource associated with the STAR certificate to be used in 221 subsequent interaction with the CA (e.g., if the certificate needs to 222 be terminated.) 224 The bootstrap phase ends when the ACME CA updates the Order resource 225 to include the URL for the issued STAR certificate. 227 2.2. Refresh 229 The CA issues the initial certificate after the authorization 230 completes successfully. It then automatically re-issues the 231 certificate using the same CSR (and therefore the same identifier and 232 public key) before the previous one expires, and publishes it to the 233 URL that was returned to the IdO at the end of the bootstrap phase. 234 The certificate user, which could be either the IdO itself or a 235 delegated third party, as described in 236 [I-D.ietf-acme-star-delegation], obtains the certificate 237 (Section 3.3) and uses it. 239 The refresh process (Figure 1) goes on until either: 241 o IdO explicitly terminates the automatic renewal (Section 2.3); or 242 o Automatic renewal expires. 244 Certificate ACME/STAR 245 User Server 246 | Retrieve cert | [...] 247 |---------------------->| | 248 | +------. / 249 | | | / 250 | | Automatic renewal : 251 | | | \ 252 | |<-----' \ 253 | Retrieve cert | | 254 |---------------------->| short validity period 255 | | | 256 | +------. / 257 | | | / 258 | | Automatic renewal : 259 | | | \ 260 | |<-----' \ 261 | Retrieve cert | | 262 |---------------------->| short validity period 263 | | | 264 | +------. / 265 | | | / 266 | | Automatic renewal : 267 | | | \ 268 | |<-----' \ 269 | | | 270 | [...] | [...] 272 Figure 1: Auto renewal 274 2.3. Termination 276 The IdO may request early termination of the STAR certificate by 277 sending a cancellation request to the Order resource, as described in 278 Section 3.1.2. After the CA receives and verifies the request, it 279 shall: 281 o Cancel the automatic renewal process for the STAR certificate; 282 o Change the certificate publication resource to return an error 283 indicating the termination of the issuance; 284 o Change the status of the Order to "canceled". 286 Note that it is not necessary to explicitly revoke the short-term 287 certificate. 289 Certificate ACME/STAR 290 User IdO Server 291 | | | 292 | | Cancel Order | 293 | +---------------------->| 294 | | +-------. 295 | | | | 296 | | | End auto renewal 297 | | | Remove cert link 298 | | | etc. 299 | | | | 300 | | Done |<------' 301 | |<----------------------+ 302 | | | 303 | | 304 | Retrieve cert | 305 +---------------------------------------------->| 306 | Error: autoRenewalCanceled | 307 |<----------------------------------------------+ 308 | | 310 Figure 2: Termination 312 3. Protocol Details 314 This section describes the protocol details, namely the extensions to 315 the ACME protocol required to issue STAR certificates. 317 3.1. ACME Extensions 319 This protocol extends the ACME protocol, to allow for automatically 320 renewed Orders. 322 3.1.1. Extending the Order Resource 324 The Order resource is extended with a new "auto-renewal" object that 325 MUST be present for STAR certificates. The "auto-renewal" object has 326 the following structure: 328 o start-date (optional, string): the earliest date of validity of 329 the first certificate issued, in [RFC3339] format. When omitted, 330 the start date is as soon as authorization is complete. 331 o end-date (required, string): the latest date of validity of the 332 last certificate issued, in [RFC3339] format. 333 o lifetime (required, integer): the maximum validity period of each 334 STAR certificate, an integer that denotes a number of seconds. 335 This is a nominal value which does not include any extra validity 336 time due to server or client adjustment (see below). 338 o lifetime-adjust (optional, integer): amount of "left pad" added to 339 each STAR certificate, an integer that denotes a number of 340 seconds. The default is 0. If present, the value of the 341 notBefore field that would otherwise appear in the STAR 342 certificates is pre-dated by the specified number of seconds. See 343 also Section 4.1 for why a client might want to use this control 344 and Section 3.5 for how the effective certificate lifetime is 345 computed. The value reflected by the server, together with the 346 value of the lifetime attribute, can be used by the client as a 347 hint to configure its polling timer. 348 o allow-certificate-get (optional, boolean): see Section 3.4. 350 These attributes are included in a POST message when creating the 351 Order, as part of the "payload" encoded object. They are returned 352 when the Order has been created, and the ACME server MAY adjust them 353 at will, according to its local policy (see also Section 3.2). 355 The optional notBefore and notAfter fields defined in Section 7.1.3 356 of [RFC8555] MUST NOT be present in a STAR Order. If they are 357 included, the server MUST return an error with status code 400 "Bad 358 Request" and type "malformedRequest". 360 Section 7.1.6 of [RFC8555] defines the following values for the Order 361 resource's status: "pending", "ready", "processing", "valid", and 362 "invalid". In the case of auto-renewal Orders, the status MUST be 363 "valid" as long as STAR certificates are being issued. We add a new 364 status value: "canceled", see Section 3.1.2. 366 A STAR certificate is by definition a dynamic resource, i.e., it 367 refers to an entity that varies over time. Instead of overloading 368 the semantics of the "certificate" attribute, this document defines a 369 new attribute "star-certificate" to be used instead of "certificate". 371 o star-certificate (optional, string): A URL for the (rolling) STAR 372 certificate that has been issued in response to this Order. 374 3.1.2. Canceling an Auto-renewal Order 376 An important property of the auto-renewal Order is that it can be 377 canceled by the IdO, with no need for certificate revocation. To 378 cancel the Order, the ACME client sends a POST to the Order URL as 379 shown in Figure 3. 381 POST /acme/order/ogfr8EcolOT HTTP/1.1 382 Host: example.org 383 Content-Type: application/jose+json 385 { 386 "protected": base64url({ 387 "alg": "ES256", 388 "kid": "https://example.com/acme/acct/gw06UNhKfOve", 389 "nonce": "Alc00Ap6Rt7GMkEl3L1JX5", 390 "url": "https://example.com/acme/order/ogfr8EcolOT" 391 }), 392 "payload": base64url({ 393 "status": "canceled" 394 }), 395 "signature": "g454e3hdBlkT4AEw...nKePnUyZTjGtXZ6H" 396 } 398 Figure 3: Canceling an Auto-renewal Order 400 After a successful cancellation, the server MUST NOT issue any 401 additional certificates for this Order. 403 When the Order is canceled, the server: 405 o MUST update the status of the Order resource to "canceled" and 406 MUST set an appropriate "expires" date; 407 o MUST respond with 403 (Forbidden) to any requests to the star- 408 certificate endpoint. The response SHOULD provide additional 409 information using a problem document [RFC7807] with type 410 "urn:ietf:params:acme:error:autoRenewalCanceled". 412 Issuing a cancellation for an Order that is not in "valid" state is 413 not allowed. A client MUST NOT send such a request, and a server 414 MUST return an error response with status code 400 (Bad Request) and 415 type "urn:ietf:params:acme:error:autoRenewalCancellationInvalid". 417 The state machine described in Section 7.1.6 of [RFC8555] is extended 418 as illustrated in Figure 4 (State Transitions for Order Objects). 420 pending --------------+ 421 | | 422 | All authz | 423 | "valid" | 424 V | 425 ready ---------------+ 426 | | 427 | Receive | 428 | finalize | 429 | request | 430 V | 431 processing ------------+ 432 | | 433 | First | 434 | certificate | Error or 435 | issued | Authorization failure 436 V V 437 valid invalid 438 | 439 | STAR 440 | Certificate 441 | canceled 442 V 443 canceled 445 Figure 4 447 Explicit certificate revocation using the revokeCert interface 448 (Section 7.6 of [RFC8555]) is not supported for STAR certificates. A 449 server receiving a revocation request for a STAR certificate MUST 450 return an error response with status code 403 (Forbidden) and type 451 "urn:ietf:params:acme:error:autoRenewalRevocationNotSupported". 453 3.2. Capability Discovery 455 In order to support the discovery of STAR capabilities, the "meta" 456 field inside the directory object defined in Section 9.7.6 of 457 [RFC8555] is extended with a new "auto-renewal" object. The "auto- 458 renewal" object MUST be present if the server supports STAR. Its 459 structure is as follows: 461 o min-lifetime (required, integer): minimum acceptable value for 462 auto-renewal lifetime, in seconds. 463 o max-duration (required, integer): maximum delta between the auto- 464 renewal end-date and start-date, in seconds. 465 o allow-certificate-get (optional, boolean): see Section 3.4. 467 An example directory object advertising STAR support with one day 468 min-lifetime and one year max-duration, and supporting certificate 469 fetching with an HTTP GET is shown in Figure 5. 471 { 472 "new-nonce": "https://example.com/acme/new-nonce", 473 "new-account": "https://example.com/acme/new-account", 474 "new-order": "https://example.com/acme/new-order", 475 "new-authz": "https://example.com/acme/new-authz", 476 "revoke-cert": "https://example.com/acme/revoke-cert", 477 "key-change": "https://example.com/acme/key-change", 478 "meta": { 479 "terms-of-service": "https://example.com/acme/terms/2017-5-30", 480 "website": "https://www.example.com/", 481 "caa-identities": ["example.com"], 482 "auto-renewal": { 483 "min-lifetime": 86400, 484 "max-duration": 31536000, 485 "allow-certificate-get": true 486 } 487 } 488 } 490 Figure 5: Directory object with STAR support 492 3.3. Fetching the Certificates 494 The certificate is fetched from the star-certificate endpoint with 495 POST-as-GET as per [RFC8555] Section 7.4.2, unless client and server 496 have successfully negotiated the "unauthenticated GET" option 497 described in Section 3.4. In such case, the client can simply issue 498 a GET to the star-certificate resource without authenticating itself 499 to the server as illustrated in Figure 6. 501 GET /acme/cert/g7m3ZQeTEqa HTTP/1.1 502 Host: example.org 503 Accept: application/pem-certificate-chain 505 HTTP/1.1 200 OK 506 Content-Type: application/pem-certificate-chain 507 Link: ;rel="index" 508 Cert-Not-Before: Thu, 3 Oct 2019 00:00:00 GMT 509 Cert-Not-After: Thu, 10 Oct 2019 00:00:00 GMT 511 -----BEGIN CERTIFICATE----- 512 [End-entity certificate contents] 513 -----END CERTIFICATE----- 514 -----BEGIN CERTIFICATE----- 515 [Issuer certificate contents] 516 -----END CERTIFICATE----- 517 -----BEGIN CERTIFICATE----- 518 [Other certificate contents] 519 -----END CERTIFICATE----- 521 Figure 6: Fetching a STAR certificate with unauthenticated GET 523 The Server SHOULD include the "Cert-Not-Before" and "Cert-Not-After" 524 HTTP header fields in the response. When they exist, they MUST be 525 equal to the respective fields inside the end-entity certificate. 526 Their format is "HTTP-date" as defined in Section 7.1.1.2 of 527 [RFC7231]. Their purpose is to enable client implementations that do 528 not parse the certificate. 530 Following are further clarifications regarding usage of these header 531 fields, as per [RFC7231] Sec. 8.3.1. All apply to both headers. 533 o This header field is a single value, not a list. 534 o The header field is used only in responses to GET, HEAD and POST- 535 as-GET requests, and only for MIME types that denote public key 536 certificates. 537 o Header field semantics are independent of context. 538 o The header field is not hop-by-hop. 539 o Intermediaries MAY insert or delete the value; 540 o If an intermediary inserts the value, it MUST ensure that the 541 newly added value matches the corresponding value in the 542 certificate. 543 o The header field is not appropriate for a Vary field. 544 o The header field is allowed within message trailers. 545 o The header field is not appropriate within redirects. 546 o The header field does not introduce additional security 547 considerations. It discloses in a simpler form information that 548 is already available inside the certificate. 550 To improve robustness, the next certificate MUST be made available by 551 the ACME CA at the URL pointed by "star-certificate" at the latest 552 halfway through the lifetime of the currently active certificate. It 553 is worth noting that this has an implication in case of cancellation: 554 in fact, from the time the next certificate is made available, the 555 cancellation is not completely effective until the "next" certificate 556 also expires. To avoid the client accidentally entering a broken 557 state, the notBefore of the "next" certificate MUST be set so that 558 the certificate is already valid when it is published at the "star- 559 certificate" URL. Note that the server might need to increase the 560 auto-renewal lifetime-adjust value to satisfy the latter requirement. 561 For a detailed description of the renewal scheduling logic, see 562 Section 3.5. For further rationale on the need for adjusting the 563 certificate validity, see Section 4.1. 565 The server MUST NOT issue any certificates for this Order with 566 notAfter after the auto-renewal end-date. 568 For expired Orders, the server MUST respond with 403 (Forbidden) to 569 any requests to the star-certificate endpoint. The response SHOULD 570 provide additional information using a problem document [RFC7807] 571 with type "urn:ietf:params:acme:error:autoRenewalExpired". Note that 572 the Order resource's state remains "valid", as per the base protocol. 574 3.4. Negotiating an unauthenticated GET 576 In order to enable the name delegation workflow defined in 577 [I-D.ietf-acme-star-delegation] as well as to increase the 578 reliability of the STAR ecosystem (see Section 4.3 for details), this 579 document defines a mechanism that allows a server to advertise 580 support for accessing star-certificate resources via unauthenticated 581 GET (in addition to POST-as-GET), and a client to enable this service 582 with per-Order granularity. 584 Specifically, a server states its availability to grant 585 unauthenticated access to a client's Order star-certificate by 586 setting the allow-certificate-get attribute to true in the auto- 587 renewal object of the meta field inside the Directory object: 589 o allow-certificate-get (optional, boolean): If this field is 590 present and set to true, the server allows GET (and HEAD) requests 591 to star-certificate URLs. 593 A client states its desire to access the issued star-certificate via 594 unauthenticated GET by adding an allow-certificate-get attribute to 595 the auto-renewal object of the payload of its newOrder request and 596 setting it to true. 598 o allow-certificate-get (optional, boolean): If this field is 599 present and set to true, the client requests the server to allow 600 unauthenticated GET (and HEAD) to the star-certificate associated 601 with this Order. 603 If the server accepts the request, it MUST reflect the attribute 604 setting in the resulting Order object. 606 Note that even when the use of unauthenticated GET has been agreed, 607 the server MUST also allow POST-as-GET requests to the star- 608 certificate resource. 610 3.5. Computing notBefore and notAfter of STAR Certificates 612 We define "nominal renewal date" as the point in time when a new 613 short-term certificate for a given STAR Order is due. Its cadence is 614 a multiple of the Order's auto-renewal lifetime that starts with the 615 issuance of the first short-term certificate and is upper-bounded by 616 the Order's auto-renewal end-date (Figure 7). 618 T - STAR Order's auto-renewal lifetime 619 end - STAR Order's auto-renewal end-date 620 nrd[i] - nominal renewal date of the i-th STAR certificate 622 .- T -. .- T -. .- T -. .__. 623 / \ / \ / \ / end 624 -----------o---------o---------o---------o----X-------> t 625 nrd[0] nrd[1] nrd[2] nrd[3] 627 Figure 7: Nominal Renewal Date 629 The rules to determine the notBefore and notAfter values of the i-th 630 STAR certificate are as follows: 632 notAfter = min(nrd[i] + T, end) 633 notBefore = nrd[i] - max(adjust_client, adjust_server) 635 Where "adjust_client" is the min between the auto-renewal lifetime- 636 adjust value ("la"), optionally supplied by the client, and the auto- 637 renewal lifetime of each short-term certificate ("T"); 638 "adjust_server" is the amount of padding added by the ACME server to 639 make sure that all certificates being published are valid at the time 640 of publication. The server padding is a fraction f of T (i.e., f * T 641 with .5 <= f < 1, see Section 3.3): 643 adjust_client = min(T, la) 644 adjust_server = f * T 646 Note that the ACME server MUST NOT set the notBefore of the first 647 STAR certificate to a date prior to the auto-renewal start-date. 649 3.5.1. Example 651 Given a server that intends to publish the next STAR certificate 652 halfway through the lifetime of the previous one, and a STAR Order 653 with the following attributes: 655 "auto-renewal": { 656 "start-date": "2019-01-10T00:00:00Z", 657 "end-date": "2019-01-20T00:00:00Z", 658 "lifetime": 345600, // 4 days 659 "lifetime-adjust": 259200 // 3 days 660 } 662 The amount of time that needs to be subtracted from each nominal 663 renewal date is 3 days - i.e., max(min(345600, 259200), 345600 * .5). 665 The notBefore and notAfter of each short-term certificate are: 667 +----------------------+----------------------+ 668 | notBefore | notAfter | 669 +----------------------+----------------------+ 670 | 2019-01-10T00:00:00Z | 2019-01-14T00:00:00Z | 671 | 2019-01-11T00:00:00Z | 2019-01-18T00:00:00Z | 672 | 2019-01-15T00:00:00Z | 2019-01-20T00:00:00Z | 673 +----------------------+----------------------+ 675 The value of the notBefore is also the time at which the client 676 should expect the new certificate to be available from the star- 677 certificate endpoint. 679 4. Operational Considerations 681 4.1. The Meaning of "Short Term" and the Impact of Skewed Clocks 683 "Short Term" is a relative concept, therefore trying to define a cut- 684 off point that works in all cases would be a useless exercise. In 685 practice, the expected lifetime of a STAR certificate will be counted 686 in minutes, hours or days, depending on different factors: the 687 underlying requirements for revocation, how much clock 688 synchronization is expected among relying parties and the issuing CA, 689 etc. 691 Nevertheless, this section attempts to provide reasonable suggestions 692 for the Web use case, informed by current operational and research 693 experience. 695 Acer et al. [Acer] find that one of the main causes of "HTTPS error" 696 warnings in browsers is misconfigured client clocks. In particular, 697 they observe that roughly 95% of the "severe" clock skews - the 6.7% 698 of clock-related breakage reports which account for clients that are 699 more than 24 hours behind - happen to be within 6-7 days. 701 In order to avoid these spurious warnings about a not (yet) valid 702 server certificate, site owners could use the auto-renewal lifetime- 703 adjust attribute to control the effective lifetime of their Web 704 facing certificates. The exact number depends on the percentage of 705 the "clock-skewed" population that the site owner expects to protect 706 - 5 days cover 97.3%, 7 days cover 99.6% - as well as the nominal 707 auto-renewal lifetime of the STAR Order. Note that exact choice is 708 also likely to depend on the kinds of client that is prevalent for a 709 given site or app - for example, Android and Mac OS clients are known 710 to behave better than Windows clients. These considerations are 711 clearly out of scope of the present document. 713 In terms of security, STAR certificates and certificates with OCSP 714 must-staple [RFC7633] can be considered roughly equivalent if the 715 STAR certificate's and the OCSP response's lifetimes are the same. 716 Given OCSP responses can be cached on average for 4 days [Stark], it 717 is RECOMMENDED that a STAR certificate that is used on the Web has an 718 "effective" lifetime (excluding any adjustment to account for clock 719 skews) no longer than 4 days. 721 4.2. Impact on Certificate Transparency (CT) Logs 723 Even in the highly unlikely case STAR becomes the only certificate 724 issuance model, discussion with the IETF TRANS Working Group and 725 Certificate Transparency (CT) logs implementers suggests that 726 existing CT Log Server implementations are capable of sustaining the 727 resulting 100-fold increase in ingestion rate. Additionally, such a 728 future, higher load could be managed with a variety of techniques 729 (e.g., sharding by modulo of certificate hash, using "smart" load- 730 balancing CT proxies, etc.). With regards to the increase in the log 731 size, current CT log growth is already being managed with schemes 732 like Chrome's Log Policy [OBrien] which allow Operators to define 733 their log life-cycle; and allowing the CAs, User Agents, Monitors, 734 and any other interested entities to build-in support for that life- 735 cycle ahead of time. 737 4.3. HTTP Caching and Dependability 739 When using authenticated POST-as-GET, the HTTPS endpoint from where 740 the STAR certificate is fetched can't be easily replicated by an on- 741 path HTTP cache. Reducing the caching properties of the protocol 742 makes STAR clients increasingly dependent on the ACME server 743 availability. This might be problematic given the relatively high 744 rate of client-server interactions in a STAR ecosystem and especially 745 when multiple endpoints (e.g., a high number of CDN edge nodes) end 746 up requesting the same certificate. Clients and servers should 747 consider using the mechanism described in Section 3.4 to mitigate the 748 risk. 750 When using unauthenticated GET to fetch the STAR certificate, the 751 server SHALL use the appropriate cache directives to set the 752 freshness lifetime of the response (Section 5.2 of [RFC7234]) such 753 that on-path caches will consider it stale before or at the time its 754 effective lifetime is due to expire. 756 5. Implementation Status 758 Note to RFC Editor: please remove this section before publication, 759 including the reference to [RFC7942] and 760 [I-D.sheffer-acme-star-request]. 762 This section records the status of known implementations of the 763 protocol defined by this specification at the time of posting of this 764 Internet-Draft, and is based on a proposal described in [RFC7942]. 765 The description of implementations in this section is intended to 766 assist the IETF in its decision processes in progressing drafts to 767 RFCs. Please note that the listing of any individual implementation 768 here does not imply endorsement by the IETF. Furthermore, no effort 769 has been spent to verify the information presented here that was 770 supplied by IETF contributors. This is not intended as, and must not 771 be construed to be, a catalog of available implementations or their 772 features. Readers are advised to note that other implementations may 773 exist. 775 According to [RFC7942], "this will allow reviewers and working groups 776 to assign due consideration to documents that have the benefit of 777 running code, which may serve as evidence of valuable experimentation 778 and feedback that have made the implemented protocols more mature. 779 It is up to the individual working groups to use this information as 780 they see fit". 782 5.1. Overview 784 The implementation is constructed around 3 elements: STAR Client for 785 the Name Delegation Client (NDC), STAR Proxy for IdO and ACME Server 786 for CA. The communication between them is over an IP network and the 787 HTTPS protocol. 789 The software of the implementation is available at: 790 https://github.com/mami-project/lurk 791 The following subsections offer a basic description, detailed 792 information is available in https://github.com/mami- 793 project/lurk/blob/master/proxySTAR_v2/README.md 795 5.1.1. ACME Server with STAR extension 797 This is a fork of the Let's Encrypt Boulder project that implements 798 an ACME compliant CA. It includes modifications to extend the ACME 799 protocol as it is specified in this draft, to support recurrent 800 Orders and cancelling Orders. 802 The implementation understands the new "recurrent" attributes as part 803 of the Certificate issuance in the POST request for a new resource. 804 An additional process "renewalManager.go" has been included in 805 parallel that reads the details of each recurrent request, 806 automatically produces a "cron" Linux based task that issues the 807 recurrent certificates, until the lifetime ends or the Order is 808 canceled. This process is also in charge of maintaining a fixed URI 809 to enable the NDC to download certificates, unlike Boulder's regular 810 process of producing a unique URI per certificate. 812 5.1.2. STAR Proxy 814 The STAR Proxy has a double role as ACME client and STAR Server. The 815 former is a fork of the EFF Certbot project that implements an ACME 816 compliant client with the STAR extension. The latter is a basic HTTP 817 REST API server. 819 The STAR Proxy understands the basic API request with a server. The 820 current implementation of the API is defined in draft-ietf-acme-star- 821 01. Registration or Order cancellation triggers the modified Certbot 822 client that requests, or cancels, the recurrent generation of 823 certificates using the STAR extension over ACME protocol. The URI 824 with the location of the recurrent certificate is delivered to the 825 STAR client as a response. 827 5.2. Level of Maturity 829 This is a prototype. 831 5.3. Coverage 833 A STAR Client is not included in this implementation, but done by 834 direct HTTP request with any open HTTP REST API tool. This is 835 expected to be covered as part of the [I-D.sheffer-acme-star-request] 836 implementation. 838 This implementation completely covers STAR Proxy and ACME Server with 839 STAR extension. 841 5.4. Version Compatibility 843 The implementation is compatible with version draft-ietf-acme-star- 844 01. The implementation is based on the Boulder and Certbot code 845 release from 7-Aug-2017. 847 5.5. Licensing 849 This implementation inherits the Boulder license (Mozilla Public 850 License 2.0) and Certbot license (Apache License Version 2.0 ). 852 5.6. Implementation experience 854 To prove the concept all the implementation has been done with a 855 self-signed CA, to avoid impact on real domains. To be able to do it 856 we use the FAKE_DNS property of Boulder and static /etc/hosts entries 857 with domains names. Nonetheless this implementation should run with 858 real domains. 860 Most of the implementation has been made to avoid deep changes inside 861 of Boulder or Certbot, for example, the recurrent certificates 862 issuance by the CA is based on an external process that auto- 863 configures the standard Linux "cron" daemon in the ACME CA server. 865 The reference setup recommended is one physical host with 3 virtual 866 machines, one for each of the 3 components (client, proxy and server) 867 and the connectivity based on host bridge. 869 Network security is not enabled (iptables default policies are 870 "accept" and all rules removed) in this implementation to simplify 871 and test the protocol. 873 5.7. Contact Information 875 See author details below. 877 6. IANA Considerations 879 [[RFC Editor: please replace XXXX below by the RFC number.]] 881 6.1. New Registries 883 This document requests that IANA create the following new registries: 885 o ACME Order Auto Renewal Fields (Section 6.4) 886 o ACME Directory Metadata Auto Renewal Fields (Section 6.6) 888 All of these registries are administered under a Specification 889 Required policy [RFC8126]. 891 6.2. New Error Types 893 This document adds the following entries to the ACME Error Type 894 registry: 896 +-----------------------------------+-------------------+-----------+ 897 | Type | Description | Reference | 898 +-----------------------------------+-------------------+-----------+ 899 | autoRenewalCanceled | The short-term | RFC XXXX | 900 | | certificate is no | | 901 | | longer available | | 902 | | because the auto- | | 903 | | renewal Order has | | 904 | | been explicitly | | 905 | | canceled by the | | 906 | | IdO | | 907 | autoRenewalExpired | The short-term | RFC XXXX | 908 | | certificate is no | | 909 | | longer available | | 910 | | because the auto- | | 911 | | renewal Order has | | 912 | | expired | | 913 | autoRenewalCancellationInvalid | A request to | RFC XXXX | 914 | | cancel a auto- | | 915 | | renewal Order | | 916 | | that is not in | | 917 | | state "valid" has | | 918 | | been received | | 919 | autoRenewalRevocationNotSupported | A request to | RFC XXXX | 920 | | revoke a auto- | | 921 | | renewal Order has | | 922 | | been received | | 923 +-----------------------------------+-------------------+-----------+ 925 6.3. New fields in Order Objects 927 This document adds the following entries to the ACME Order Object 928 Fields registry: 930 +------------------+------------+--------------+-----------+ 931 | Field Name | Field Type | Configurable | Reference | 932 +------------------+------------+--------------+-----------+ 933 | auto-renewal | object | true | RFC XXXX | 934 | star-certificate | string | false | RFC XXXX | 935 +------------------+------------+--------------+-----------+ 937 6.4. Fields in the "auto-renewal" Object within an Order Object 939 The "ACME Order Auto Renewal Fields" registry lists field names that 940 are defined for use in the JSON object included in the "auto-renewal" 941 field of an ACME order object. 943 Template: 945 o Field name: The string to be used as a field name in the JSON 946 object 947 o Field type: The type of value to be provided, e.g., string, 948 boolean, array of string 949 o Configurable: Boolean indicating whether the server should accept 950 values provided by the client 951 o Reference: Where this field is defined 953 Initial contents: The fields and descriptions defined in 954 Section 3.1.1. 956 +-----------------------+------------+--------------+-----------+ 957 | Field Name | Field Type | Configurable | Reference | 958 +-----------------------+------------+--------------+-----------+ 959 | start-date | string | true | RFC XXXX | 960 | end-date | string | true | RFC XXXX | 961 | lifetime | integer | true | RFC XXXX | 962 | lifetime-adjust | integer | true | RFC XXXX | 963 | allow-certificate-get | boolean | true | RFC XXXX | 964 +-----------------------+------------+--------------+-----------+ 966 6.5. New fields in the "meta" Object within a Directory Object 968 This document adds the following entry to the ACME Directory Metadata 969 Fields: 971 +--------------+------------+-----------+ 972 | Field Name | Field Type | Reference | 973 +--------------+------------+-----------+ 974 | auto-renewal | object | RFC XXXX | 975 +--------------+------------+-----------+ 977 6.6. Fields in the "auto-renewal" Object within a Directory Metadata 978 Object 980 The "ACME Directory Metadata Auto Renewal Fields" registry lists 981 field names that are defined for use in the JSON object included in 982 the "auto-renewal" field of an ACME directory "meta" object. 984 Template: 986 o Field name: The string to be used as a field name in the JSON 987 object 988 o Field type: The type of value to be provided, e.g., string, 989 boolean, array of string 990 o Reference: Where this field is defined 992 Initial contents: The fields and descriptions defined in Section 3.2. 994 +-----------------------+------------+-----------+ 995 | Field Name | Field Type | Reference | 996 +-----------------------+------------+-----------+ 997 | min-lifetime | integer | RFC XXXX | 998 | max-duration | integer | RFC XXXX | 999 | allow-certificate-get | boolean | RFC XXXX | 1000 +-----------------------+------------+-----------+ 1002 6.7. Cert-Not-Before and Cert-Not-After HTTP Headers 1004 The "Message Headers" registry should be updated with the following 1005 additional values: 1007 +-------------------+----------+----------+-----------------------+ 1008 | Header Field Name | Protocol | Status | Reference | 1009 +-------------------+----------+----------+-----------------------+ 1010 | Cert-Not-Before | http | standard | RFC XXXX, Section 3.3 | 1011 | Cert-Not-After | http | standard | RFC XXXX, Section 3.3 | 1012 +-------------------+----------+----------+-----------------------+ 1014 7. Security Considerations 1016 7.1. No revocation 1018 STAR certificates eliminate an important security feature of PKI 1019 which is the ability to revoke certificates. Revocation allows the 1020 administrator to limit the damage done by a rogue node or an 1021 adversary who has control of the private key. With STAR 1022 certificates, expiration replaces revocation so there is potential 1023 for lack of timeliness in the revocation taking effect. To that end, 1024 see also the discussion on clock skew in Section 4.1. 1026 It should be noted that revocation also has timeliness issues, 1027 because both CRLs and OCSP responses have nextUpdate fields that tell 1028 relying parties (RPs) how long they should trust this revocation 1029 data. These fields are typically set to hours, days, or even weeks 1030 in the future. Any revocation that happens before the time in 1031 nextUpdate goes unnoticed by the RP. 1033 One situation where the lack of explicit revocation could create a 1034 security risk to the IdO is when the Order is created with start-date 1035 some appreciable amount of time in the future. Recall that when 1036 authorizations have been fulfilled, the Order moves to the "valid" 1037 state and the star-certificate endpoint is populated with the first 1038 cert (Figure 4). So, if an attacker manages to get hold of the 1039 private key as well as of the first (post-dated) certificate, there 1040 is a time window in the future when they will be able to successfully 1041 impersonate the IdO. Note that cancellation is pointless in this 1042 case. In order to mitigate the described threat, it is RECOMMENDED 1043 that IdO place their Orders at a time that is close to the Order's 1044 start-date. 1046 More discussion of the security of STAR certificates is available in 1047 [Topalovic]. 1049 7.2. Denial of Service Considerations 1051 STAR adds a new attack vector that increases the threat of denial of 1052 service attacks, caused by the change to the CA's behavior. Each 1053 STAR request amplifies the resource demands upon the CA, where one 1054 Order produces not one, but potentially dozens or hundreds of 1055 certificates, depending on the auto-renewal "lifetime" parameter. An 1056 attacker can use this property to aggressively reduce the auto- 1057 renewal "lifetime" (e.g. 1 sec.) jointly with other ACME attack 1058 vectors identified in Sec. 10 of [RFC8555]. Other collateral impact 1059 is related to the certificate endpoint resource where the client can 1060 retrieve the certificates periodically. If this resource is external 1061 to the CA (e.g. a hosted web server), the previous attack will be 1062 reflected to that resource. 1064 Mitigation recommendations from ACME still apply, but some of them 1065 need to be adjusted. For example, applying rate limiting to the 1066 initial request, by the nature of the auto-renewal behavior cannot 1067 solve the above problem. The CA server needs complementary 1068 mitigation and specifically, it SHOULD enforce a minimum value on 1069 auto-renewal "lifetime". Alternatively, the CA can set an internal 1070 certificate generation processes rate limit. Note that this limit 1071 has to take account of already-scheduled renewal issuances as well as 1072 new incoming requests. 1074 7.3. Privacy Considerations 1076 In order to avoid correlation of certificates by account, if 1077 unauthenticated GET is negotiated (Section 3.4) the recommendation in 1078 Section 10.5 of [RFC8555] regarding the choice of URL structure 1079 applies, i.e. servers SHOULD choose URLs of certificate resources in 1080 a non-guessable way, for example using capability URLs 1081 [W3C.WD-capability-urls-20140218]. 1083 8. Acknowledgments 1085 This work is partially supported by the European Commission under 1086 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 1087 for a Middleboxed Internet (MAMI). This support does not imply 1088 endorsement. 1090 Thanks to Ben Kaduk, Richard Barnes, Roman Danyliw, Jon Peterson, 1091 Eric Rescorla, Ryan Sleevi, Sean Turner, Alexey Melnikov, Adam Roach, 1092 Martin Thomson and Mehmet Ersue for helpful comments and discussions 1093 that have shaped this document. 1095 9. References 1097 9.1. Normative References 1099 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1100 Requirement Levels", BCP 14, RFC 2119, 1101 DOI 10.17487/RFC2119, March 1997, 1102 . 1104 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1105 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1106 . 1108 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1109 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1110 DOI 10.17487/RFC7231, June 2014, 1111 . 1113 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1114 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1115 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1116 . 1118 [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP 1119 APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, 1120 . 1122 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1123 Writing an IANA Considerations Section in RFCs", BCP 26, 1124 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1125 . 1127 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1128 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1129 May 2017, . 1131 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1132 Kasten, "Automatic Certificate Management Environment 1133 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1134 . 1136 9.2. Informative References 1138 [Acer] Acer, M., Stark, E., Felt, A., Fahl, S., Bhargava, R., 1139 Dev, B., Braithwaite, M., Sleevi, R., and P. Tabriz, 1140 "Where the Wild Warnings Are: Root Causes of Chrome HTTPS 1141 Certificate Errors", DOI 10.1145/3133956.3134007, 2017, 1142 . 1144 [I-D.ietf-acme-star-delegation] 1145 Sheffer, Y., Lopez, D., Pastor, A., and T. Fossati, "An 1146 ACME Profile for Generating Delegated STAR Certificates", 1147 draft-ietf-acme-star-delegation-01 (work in progress), 1148 August 2019. 1150 [I-D.nir-saag-star] 1151 Nir, Y., Fossati, T., Sheffer, Y., and T. Eckert, 1152 "Considerations For Using Short Term Certificates", draft- 1153 nir-saag-star-01 (work in progress), March 2018. 1155 [I-D.sheffer-acme-star-request] 1156 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 1157 Fossati, "Generating Certificate Requests for Short-Term, 1158 Automatically-Renewed (STAR) Certificates", draft-sheffer- 1159 acme-star-request-02 (work in progress), June 2018. 1161 [OBrien] O'Brien, D. and R. Sleevi, "Chromium Certificate 1162 Transparency Log Policy", 2017, 1163 . 1165 [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) 1166 Feature Extension", RFC 7633, DOI 10.17487/RFC7633, 1167 October 2015, . 1169 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1170 Code: The Implementation Status Section", BCP 205, 1171 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1172 . 1174 [Stark] Stark, E., Huang, L., Israni, D., Jackson, C., and D. 1175 Boneh, "The case for prefetching and prevalidating TLS 1176 server certificates", 2012, 1177 . 1180 [Topalovic] 1181 Topalovic, E., Saeta, B., Huang, L., Jackson, C., and D. 1182 Boneh, "Towards Short-Lived Certificates", 2012, 1183 . 1186 [W3C.WD-capability-urls-20140218] 1187 Tennison, J., "Good Practices for Capability URLs", World 1188 Wide Web Consortium WD WD-capability-urls-20140218, 1189 February 2014, 1190 . 1192 Appendix A. Document History 1194 [[Note to RFC Editor: please remove before publication.]] 1196 A.1. draft-ietf-acme-star-11 1198 o One more nit re: random URL 1200 A.2. draft-ietf-acme-star-10 1202 IESG processing: 1204 o More clarity on IANA registration (Alexey); 1205 o HTTP header requirements adjustments (Adam); 1206 o Misc editorial (Ben) 1208 A.3. draft-ietf-acme-star-09 1210 Richard and Ryan's review resulted in the following updates: 1212 o STAR Order and Directory Meta attributes renamed slightly and 1213 grouped under two brand new "auto-renewal" objects; 1214 o IANA registration updated accordingly (note that two new 1215 registries have been added as a consequence); 1216 o Unbounded pre-dating of certificates removed so that STAR certs 1217 are never issued with their notBefore in the past; 1218 o Changed "recurrent" to "autoRenewal" in error codes; 1219 o Changed "recurrent" to "auto-renewal" in reference to Orders; 1220 o Added operational considerations for HTTP caches. 1222 A.4. draft-ietf-acme-star-08 1224 o Improved text on interaction with CT Logs, responding to Mehmet 1225 Ersue's review. 1227 A.5. draft-ietf-acme-star-07 1229 o Changed the HTTP headers names and clarified the IANA 1230 registration, following feedback from the IANA expert reviewer 1232 A.6. draft-ietf-acme-star-06 1234 o Roman's AD review 1236 A.7. draft-ietf-acme-star-05 1238 o EKR's AD review 1239 o A detailed example of the timing of certificate issuance and 1240 predating 1241 o Added an explicit client-side parameter for predating 1242 o Security considerations around unauthenticated GET 1244 A.8. draft-ietf-acme-star-04 1246 o WG last call comments by Sean Turner 1247 o revokeCert interface handling 1248 o Allow negotiating plain-GET for certs 1249 o In STAR Orders, use star-certificate instead of certificate 1251 A.9. draft-ietf-acme-star-03 1253 o Clock skew considerations 1254 o Recommendations for "short" in the Web use case 1255 o CT log considerations 1257 A.10. draft-ietf-acme-star-02 1259 o Discovery of STAR capabilities via the directory object 1260 o Use the more generic term Identifier Owner (IdO) instead of Domain 1261 Name Owner (DNO) 1262 o More precision about what goes in the order 1263 o Detail server side behavior on cancellation 1265 A.11. draft-ietf-acme-star-01 1267 o Generalized the introduction, separating out the specifics of 1268 CDNs. 1269 o Clean out LURK-specific text. 1270 o Using a POST to ensure cancellation is authenticated. 1271 o First and last date of recurrent cert, as absolute dates. 1272 Validity of certs in seconds. 1273 o Use RFC7807 "Problem Details" in error responses. 1274 o Add IANA considerations. 1275 o Changed the document's title. 1277 A.12. draft-ietf-acme-star-00 1279 o Initial working group version. 1280 o Removed the STAR interface, the protocol between NDC and DNO. 1281 What remains is only the extended ACME protocol. 1283 A.13. draft-sheffer-acme-star-02 1285 o Using a more generic term for the delegation client, NDC. 1286 o Added an additional use case: public cloud services. 1287 o More detail on ACME authorization. 1289 A.14. draft-sheffer-acme-star-01 1291 o A terminology section. 1292 o Some cleanup. 1294 A.15. draft-sheffer-acme-star-00 1296 o Renamed draft to prevent confusion with other work in this space. 1297 o Added an initial STAR protocol: a REST API. 1298 o Discussion of CDNI use cases. 1300 A.16. draft-sheffer-acme-star-lurk-00 1302 o Initial version. 1304 Authors' Addresses 1306 Yaron Sheffer 1307 Intuit 1309 EMail: yaronf.ietf@gmail.com 1311 Diego Lopez 1312 Telefonica I+D 1314 EMail: diego.r.lopez@telefonica.com 1316 Oscar Gonzalez de Dios 1317 Telefonica I+D 1319 EMail: oscar.gonzalezdedios@telefonica.com 1321 Antonio Agustin Pastor Perales 1322 Telefonica I+D 1324 EMail: antonio.pastorperales@telefonica.com 1325 Thomas Fossati 1326 ARM 1328 EMail: thomas.fossati@arm.com