idnits 2.17.1 draft-ietf-acme-star-07.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 (August 20, 2019) is 1710 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 574 -- Looks like a reference, but probably isn't: '1' on line 574 -- Looks like a reference, but probably isn't: '2' on line 574 -- Looks like a reference, but probably isn't: '3' on line 574 ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7807 (Obsoleted by RFC 9457) == Outdated reference: A later version (-09) exists of draft-ietf-acme-star-delegation-00 -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 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: February 21, 2020 O. Gonzalez de Dios 6 A. Pastor Perales 7 Telefonica I+D 8 T. Fossati 9 ARM 10 August 20, 2019 12 Support for Short-Term, Automatically-Renewed (STAR) Certificates in 13 Automated Certificate Management Environment (ACME) 14 draft-ietf-acme-star-07 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 February 21, 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 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 a Recurrent Order . . . . . . . . . . . . . 8 78 3.2. Capability Discovery . . . . . . . . . . . . . . . . . . 9 79 3.3. Fetching the Certificates . . . . . . . . . . . . . . . . 10 80 3.4. Negotiating an unauthenticated GET . . . . . . . . . . . 12 81 3.5. Computing notBefore and notAfter of STAR Certificates . . 13 82 3.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 13 83 4. Operational Considerations . . . . . . . . . . . . . . . . . 14 84 4.1. The Meaning of "Short Term" and the Impact of Skewed 85 Clocks . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 4.2. Impact on Certificate Transparency (CT) Logs . . . . . . 15 87 4.3. Dependability . . . . . . . . . . . . . . . . . . . . . . 15 88 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 89 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 90 5.1.1. ACME Server with STAR extension . . . . . . . . . . . 16 91 5.1.2. STAR Proxy . . . . . . . . . . . . . . . . . . . . . 17 92 5.2. Level of Maturity . . . . . . . . . . . . . . . . . . . . 17 93 5.3. Coverage . . . . . . . . . . . . . . . . . . . . . . . . 17 94 5.4. Version Compatibility . . . . . . . . . . . . . . . . . . 17 95 5.5. Licensing . . . . . . . . . . . . . . . . . . . . . . . . 17 96 5.6. Implementation experience . . . . . . . . . . . . . . . . 18 97 5.7. Contact Information . . . . . . . . . . . . . . . . . . . 18 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 99 6.1. New Error Types . . . . . . . . . . . . . . . . . . . . . 18 100 6.2. New fields in Order Objects . . . . . . . . . . . . . . . 19 101 6.3. New fields in the "meta" Object within a Directory Object 20 102 6.4. Cert-Not-Before and Cert-Not-After HTTP Headers . . . . . 20 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 104 7.1. No revocation . . . . . . . . . . . . . . . . . . . . . . 20 105 7.2. Denial of Service Considerations . . . . . . . . . . . . 21 106 7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 21 107 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 108 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 109 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 110 9.2. Informative References . . . . . . . . . . . . . . . . . 22 111 Appendix A. Document History . . . . . . . . . . . . . . . . . . 24 112 A.1. draft-ietf-acme-star-07 . . . . . . . . . . . . . . . . . 24 113 A.2. draft-ietf-acme-star-06 . . . . . . . . . . . . . . . . . 24 114 A.3. draft-ietf-acme-star-05 . . . . . . . . . . . . . . . . . 24 115 A.4. draft-ietf-acme-star-04 . . . . . . . . . . . . . . . . . 24 116 A.5. draft-ietf-acme-star-03 . . . . . . . . . . . . . . . . . 24 117 A.6. draft-ietf-acme-star-02 . . . . . . . . . . . . . . . . . 24 118 A.7. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 24 119 A.8. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 25 120 A.9. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 25 121 A.10. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 25 122 A.11. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 25 123 A.12. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 25 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 126 1. Introduction 128 The ACME protocol [RFC8555] automates the process of issuing a 129 certificate to a named entity (an Identifier Owner or IdO). 130 Typically, but not always, the identifier is a domain name. 132 If the IdO wishes to obtain a string of short-term certificates 133 originating from the same private key (see [Topalovic] about why 134 using short-lived certificates might be preferable to explicit 135 revocation), she must go through the whole ACME protocol each time a 136 new short-term certificate is needed - e.g., every 2-3 days. If done 137 this way, the process would involve frequent interactions between the 138 registration function of the ACME Certification Authority (CA) and 139 the identity provider infrastructure (e.g.: DNS, web servers), 140 therefore making the issuance of short-term certificates exceedingly 141 dependent on the reliability of both. 143 This document presents an extension of the ACME protocol that 144 optimizes this process by making short-term certificates first class 145 objects in the ACME ecosystem. Once the order for a string of short- 146 term certificates is accepted, the CA is responsible for publishing 147 the next certificate at an agreed upon URL before the previous one 148 expires. The IdO can terminate the automatic renewal before the 149 negotiated deadline, if needed - e.g., on key compromise. 151 For a more generic treatment of STAR certificates, readers are 152 referred to [I-D.nir-saag-star]. 154 1.1. Name Delegation Use Case 156 The proposed mechanism can be used as a building block of an 157 efficient name-delegation protocol, for example one that exists 158 between a CDN or a cloud provider and its customers 159 [I-D.ietf-acme-star-delegation]. At any time, the service customer 160 (i.e., the IdO) can terminate the delegation by simply instructing 161 the CA to stop the automatic renewal and letting the currently active 162 certificate expire shortly thereafter. Note that in this case the 163 delegated entity needs to access the auto-renewed certificate without 164 being in possession of the ACME account key that was used for 165 initiating the STAR issuance. 167 1.2. Terminology 169 IdO Identifier Owner, the owner of an identifier, e.g.: a domain 170 name, a telephone number. 171 STAR Short-Term and Automatically Renewed X.509 certificates. 173 1.3. Conventions used in this document 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 177 "OPTIONAL" in this document are to be interpreted as described in 178 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 179 capitals, as shown here. 181 2. Protocol Flow 183 The following subsections describe the three main phases of the 184 protocol: 186 o Bootstrap: the IdO asks an ACME CA to create a short-term and 187 automatically-renewed (STAR) certificate (Section 2.1); 188 o Auto-renewal: the ACME CA periodically re-issues the short-term 189 certificate and posts it to the star-certificate URL 190 (Section 2.2); 191 o Termination: the IdO requests the ACME CA to discontinue the 192 automatic renewal of the certificate (Section 2.3). 194 2.1. Bootstrap 196 The IdO, in its role as an ACME client, requests the CA to issue a 197 STAR certificate, i.e., one that: 199 o Has a short validity, e.g., 24 to 72 hours. Note that the exact 200 definition of "short" depends on the use case; 201 o Is automatically renewed by the CA for a certain period of time; 202 o Is downloadable from a (highly available) location. 204 Other than that, the ACME protocol flows as usual between IdO and CA. 205 In particular, IdO is responsible for satisfying the requested ACME 206 challenges until the CA is willing to issue the requested 207 certificate. Per normal ACME processing, the IdO is given back an 208 Order resource associated with the STAR certificate to be used in 209 subsequent interaction with the CA (e.g., if the certificate needs to 210 be terminated.) 212 The bootstrap phase ends when the ACME CA updates the Order resource 213 to include the URL for the issued STAR certificate. 215 2.2. Refresh 217 The CA issues the initial certificate after the authorization 218 completes successfully. It then automatically re-issues the 219 certificate using the same CSR (and therefore the same identifier and 220 public key) before the previous one expires, and publishes it to the 221 URL that was returned to the IdO at the end of the bootstrap phase. 222 The certificate user, which could be either the IdO itself or a 223 delegated third party, as described in 224 [I-D.ietf-acme-star-delegation], obtains the certificate 225 (Section 3.3) and uses it. 227 The refresh process (Figure 1) goes on until either: 229 o IdO explicitly terminates the automatic renewal (Section 2.3); or 230 o Automatic renewal expires. 232 Certificate ACME/STAR 233 User Server 234 | Retrieve cert | [...] 235 |---------------------->| | 236 | +------. / 237 | | | / 238 | | Automatic renewal : 239 | | | \ 240 | |<-----' \ 241 | Retrieve cert | | 242 |---------------------->| short validity period 243 | | | 244 | +------. / 245 | | | / 246 | | Automatic renewal : 247 | | | \ 248 | |<-----' \ 249 | Retrieve cert | | 250 |---------------------->| short validity period 251 | | | 252 | +------. / 253 | | | / 254 | | Automatic renewal : 255 | | | \ 256 | |<-----' \ 257 | | | 258 | [...] | [...] 260 Figure 1: Auto renewal 262 2.3. Termination 264 The IdO may request early termination of the STAR certificate by 265 sending a cancellation request to the Order resource, as described in 266 Section 3.1.2. After the CA receives and verifies the request, it 267 shall: 269 o Cancel the automatic renewal process for the STAR certificate; 270 o Change the certificate publication resource to return an error 271 indicating the termination of the issuance; 272 o Change the status of the Order to "canceled". 274 Note that it is not necessary to explicitly revoke the short-term 275 certificate. 277 Certificate ACME/STAR 278 User IdO Server 279 | | | 280 | | Cancel Order | 281 | +---------------------->| 282 | | +-------. 283 | | | | 284 | | | End auto renewal 285 | | | Remove cert link 286 | | | etc. 287 | | | | 288 | | Done |<------' 289 | |<----------------------+ 290 | | | 291 | | 292 | Retrieve cert | 293 +---------------------------------------------->| 294 | Error: recurrentOrderCanceled | 295 |<----------------------------------------------+ 296 | | 298 Figure 2: Termination 300 3. Protocol Details 302 This section describes the protocol details, namely the extensions to 303 the ACME protocol required to issue STAR certificates. 305 3.1. ACME Extensions 307 This protocol extends the ACME protocol, to allow for recurrent 308 Orders. 310 3.1.1. Extending the Order Resource 312 The Order resource is extended with the following attributes: 314 o recurrent (required, boolean): MUST be true for STAR certificates. 315 o recurrent-start-date (optional, string): the earliest date of 316 validity of the first certificate issued, in [RFC3339] format. 317 When omitted, the start date is as soon as authorization is 318 complete. 319 o recurrent-end-date (required, string): the latest date of validity 320 of the last certificate issued, in [RFC3339] format. 321 o recurrent-certificate-validity (required, integer): the maximum 322 validity period of each STAR certificate, an integer that denotes 323 a number of seconds. This is a nominal value which does not 324 include any extra validity time which is due to pre-dating. The 325 client can use the value reflected by the server (which may be 326 different from the one sent by the client) as a hint to configure 327 its polling timer. 328 o recurrent-certificate-predate (optional, integer): amount of pre- 329 dating added to each STAR certificate, an integer that denotes a 330 number of seconds. The default is 0. If present, the value of 331 the notBefore field that would otherwise appear in the STAR 332 certificates is pre-dated by the specified number of seconds. See 333 also Section 4.1. 334 o recurrent-certificate-get (optional, boolean): see Section 3.4. 336 These attributes are included in a POST message when creating the 337 Order, as part of the "payload" encoded object. They are returned 338 when the Order has been created, and the ACME server MAY adjust them 339 at will, according to its local policy (see also Section 3.2). 341 The optional notBefore and notAfter fields defined in Section 7.1.3 342 of [RFC8555] MUST NOT be present in a STAR Order. If they are 343 included, the server MUST return an error with status code 400 "Bad 344 Request" and type "malformedRequest". 346 Section 7.1.6 of [RFC8555] defines the following values for the Order 347 resource's status: "pending", "ready", "processing", "valid", and 348 "invalid". In the case of recurrent Orders, the status MUST be 349 "valid" as long as STAR certificates are being issued. We add a new 350 status value: "canceled", see Section 3.1.2. 352 A STAR certificate is by definition a mutable resource. Instead of 353 overloading the semantics of the "certificate" attribute, this 354 document defines a new attribute "star-certificate" to be used 355 instead of "certificate". 357 o star-certificate (optional, string): A URL for the (rolling) STAR 358 certificate that has been issued in response to this Order. 360 3.1.2. Canceling a Recurrent Order 362 An important property of the recurrent Order is that it can be 363 canceled by the IdO, with no need for certificate revocation. To 364 cancel the Order, the ACME client sends a POST to the Order URL as 365 shown in Figure 3. 367 POST /acme/order/TOlocE8rfgo HTTP/1.1 368 Host: example.org 369 Content-Type: application/jose+json 371 { 372 "protected": base64url({ 373 "alg": "ES256", 374 "kid": "https://example.com/acme/acct/evOfKhNU60wg", 375 "nonce": "5XJ1L3lEkMG7tR6pA00clA", 376 "url": "https://example.com/acme/order/TOlocE8rfgo" 377 }), 378 "payload": base64url({ 379 "status": "canceled" 380 }), 381 "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" 382 } 384 Figure 3: Canceling a Recurrent Order 386 After a successful cancellation, the server MUST NOT issue any 387 additional certificates for this order. 389 Immediately after the order is canceled, the server: 391 o MUST update the status of the order resource to "canceled" and 392 MUST set an appropriate "expires" date; 393 o MUST respond with 403 (Forbidden) to any requests to the star- 394 certificate endpoint. The response SHOULD provide additional 395 information using a problem document [RFC7807] with type 396 "urn:ietf:params:acme:error:recurrentOrderCanceled". 398 Issuing a cancellation for an order that is not in "valid" state is 399 not allowed. A client MUST NOT send such a request, and a server 400 MUST return an error response with status code 400 (Bad Request) and 401 type "urn:ietf:params:acme:error:recurrentCancellationInvalid". 403 Explicit certificate revocation using the revokeCert interface 404 (Section 7.6 of [RFC8555]) is not supported for STAR certificates. A 405 server receiving a revocation request for a STAR certificate MUST 406 return an error response with status code 403 (Forbidden) and type 407 "urn:ietf:params:acme:error:recurrentRevocationNotSupported". 409 3.2. Capability Discovery 411 In order to support the discovery of STAR capabilities, the directory 412 object defined in Section 9.7.6 of [RFC8555] is extended with the 413 following attributes inside the "meta" field: 415 o star-enabled (required, boolean): indicates STAR support. An ACME 416 STAR server MUST include this attribute, and MUST set it to true 417 if the feature is enabled. 418 o star-min-cert-validity (required, integer): minimum acceptable 419 value for recurrent-certificate-validity, in seconds. 420 o star-max-renewal (required, integer): maximum delta between 421 recurrent-end-date and recurrent-start-date, in seconds. 422 o star-allow-certificate-get (optional, boolean): see Section 3.4. 424 An example directory object advertising STAR support with one day 425 star-min-cert-validity and one year star-max-renewal, and supporting 426 certificate fetching with an HTTP GET is shown in Figure 4. 428 { 429 "new-nonce": "https://example.com/acme/new-nonce", 430 "new-account": "https://example.com/acme/new-account", 431 "new-order": "https://example.com/acme/new-order", 432 "new-authz": "https://example.com/acme/new-authz", 433 "revoke-cert": "https://example.com/acme/revoke-cert", 434 "key-change": "https://example.com/acme/key-change", 435 "meta": { 436 "terms-of-service": "https://example.com/acme/terms/2017-5-30", 437 "website": "https://www.example.com/", 438 "caa-identities": ["example.com"], 439 "star-enabled": true, 440 "star-min-cert-validity": 86400, 441 "star-max-renewal": 31536000, 442 "star-allow-certificate-get": true 443 } 444 } 446 Figure 4: Directory object with STAR support 448 3.3. Fetching the Certificates 450 The certificate is fetched from the star-certificate endpoint with 451 POST-as-GET as per [RFC8555] Section 7.4.2, unless client and server 452 have successfully negotiated the "unauthenticated GET" option 453 described in Section 3.4. In such case, the client can simply issue 454 a GET to the star-certificate resource without authenticating itself 455 to the server as illustrated in Figure 5. 457 GET /acme/cert/mAt3xBGaobw HTTP/1.1 458 Host: example.org 459 Accept: application/pem-certificate-chain 461 HTTP/1.1 200 OK 462 Content-Type: application/pem-certificate-chain 463 Link: ;rel="index" 464 Cert-Not-Before: Mon, 1 Feb 2016 00:00:00 GMT 465 Cert-Not-After: Mon, 8 Feb 2016 00:00:00 GMT 467 -----BEGIN CERTIFICATE----- 468 [End-entity certificate contents] 469 -----END CERTIFICATE----- 470 -----BEGIN CERTIFICATE----- 471 [Issuer certificate contents] 472 -----END CERTIFICATE----- 473 -----BEGIN CERTIFICATE----- 474 [Other certificate contents] 475 -----END CERTIFICATE----- 477 Figure 5: Fetching a STAR certificate with unauthenticated GET 479 The Server SHOULD include the "Cert-Not-Before" and "Cert-Not-After" 480 HTTP headers in the response. When they exist, they MUST be equal to 481 the respective fields inside the end-entity certificate. Their 482 format is "HTTP-date" as defined in Section 7.1.1.2 of [RFC7231]. 483 Their purpose is to enable client implementations that do not parse 484 the certificate. 486 Following are further clarifications regarding usage of these 487 headers, as per [RFC7231] Sec. 8.3.1. All apply to both headers. 489 o This header is a single value, not a list. 490 o The header is used only in responses to GET, HEAD and POST-as-GET 491 requests, and only for MIME types that denote public key 492 certificates. 493 o Header semantics are independent of context. 494 o The header is not hop-by-hop. 495 o Intermediaries MAY insert or delete the value, but MUST ensure 496 that if present, the header value equals the corresponding value 497 within the credential. 498 o The header is not appropriate for a Vary field. 499 o The header is allowed within message trailers. 500 o The header is not appropriate within redirects. 501 o The header does not introduce additional security considerations. 502 It discloses in a simpler form information that is already 503 available inside the credential. 505 To improve robustness, the next certificate MUST be made available by 506 the ACME CA at the URL pointed by "star-certificate" at the latest 507 halfway through the lifetime of the currently active certificate. It 508 is worth noting that this has an implication in case of cancellation: 509 in fact, from the time the next certificate is made available, the 510 cancellation is not completely effective until the latter also 511 expires. To avoid the client accidentally entering a broken state, 512 the "next" certificate MUST be pre-dated so that it is already valid 513 when it is published at the "star-certificate" URL. Note that the 514 server might need to increase the recurrent-certificate-predate value 515 to satisfy the latter requirement. For further discussion on pre- 516 dating, see Section 4.1. 518 The server MUST NOT issue any additional certificates for this order 519 beyond its recurrent-end-date. 521 Immediately after the order expires, the server MUST respond with 403 522 (Forbidden) to any requests to the star-certificate endpoint. The 523 response SHOULD provide additional information using a problem 524 document [RFC7807] with type 525 "urn:ietf:params:acme:error:recurrentOrderExpired". Note that the 526 Order resource's state remains "valid", as per the base protocol. 528 3.4. Negotiating an unauthenticated GET 530 In order to enable the name delegation workflow defined in 531 [I-D.ietf-acme-star-delegation] as well as to increase the 532 reliability of the STAR ecosystem (see Section 4.3 for details), this 533 document defines a mechanism that allows a server to advertise 534 support for accessing star-certificate resources via unauthenticated 535 GET (instead of, or in addition to, POST-as-GET), and a client to 536 enable this service with per-Order granularity. 538 Specifically, a server states its availability to grant 539 unauthenticated access to a client's Order star-certificate by 540 setting the star-allow-certificate-get attribute to true in the meta 541 field of the Directory object: 543 o star-allow-certificate-get (optional, boolean): If this field is 544 present and set to true, the server allows GET requests to star- 545 certificate URLs. 547 A client states its will to access the issued star-certificate via 548 unauthenticated GET by adding a recurrent-certificate-get attribute 549 to its Order and setting it to true. 551 o recurrent-certificate-get (optional, boolean): If this field is 552 present and set to true, the client requests the server to allow 553 unauthenticated GET to the star-certificate associated with this 554 Order. 556 If the server accepts the request, it MUST reflect the attribute 557 setting in the resulting Order object. 559 3.5. Computing notBefore and notAfter of STAR Certificates 561 We define "nominal renewal date" the point in time when a new short- 562 term certificate for a given STAR Order is due. It is a multiple of 563 the Order's recurrent-certificate-validity that starts with the 564 issuance of the first short-term certificate and is upper-bounded by 565 the Order's recurrent-end-date (Figure 6). 567 rcv - STAR Order's recurrent-certificate-validity 568 red - STAR Order's recurrent-end-date 569 nrd[i] - nominal renewal date of the i-th STAR certificate 571 .-rcv-. .-rcv-. .-rcv-. .__. 572 / \ / \ / \ / red 573 -----------o---------o---------o---------o----X-------> t 574 nrd[0] nrd[1] nrd[2] nrd[3] 576 Figure 6: Nominal Renewal Date 578 The rules to determine the notBefore and notAfter values of the i-th 579 STAR certificate are as follows: 581 notBefore = nrd[i] - predating 582 notAfter = min(nrd[i] + rcv, red) 584 where "predating" is the max between the (optional) recurrent- 585 certificate-predate (rcp) and the amount of pre-dating that the 586 server needs to add to make sure that all certificates being 587 published are valid at the time of publication (Section 3.3). The 588 server pre-dating is a fraction f of rcv (i.e., f * rcv with .5 <= f 589 < 1). 591 predating = max(rcp, f * rcv) 593 3.5.1. Example 595 Given a server that intends to publish the next STAR certificate 596 halfway through the lifetime of the previous one, and a STAR Order 597 with the following attributes: 599 { 600 "recurrent-start-date": "2016-01-10T00:00:00Z", 601 "recurrent-end-date": "2016-01-20T00:00:00Z", 602 "recurrent-certificate-validity": 345600, // 4 days 603 "recurrent-certificate-predate": 518400 // 6 days 604 } 606 The amount of pre-dating that needs to be subtracted from each 607 nominal renewal date is 6 days - i.e., max(518400, 345600 * .5). 609 The notBefore and notAfter of each short-term certificate are: 611 +----------------------+----------------------+ 612 | notBefore | notAfter | 613 +----------------------+----------------------+ 614 | 2016-01-04T00:00:00Z | 2016-01-14T00:00:00Z | 615 | 2016-01-08T00:00:00Z | 2016-01-18T00:00:00Z | 616 | 2016-01-12T00:00:00Z | 2016-01-20T00:00:00Z | 617 +----------------------+----------------------+ 619 A client should expect each certificate to be available from the 620 star-certificate endpoint at the following times: 622 +------------------------------------+ 623 | 2016-01-10T00:00:00Z (or earlier) | 624 | 2016-01-12T00:00:00Z | 625 | 2016-01-16T00:00:00Z | 626 +------------------------------------+ 628 4. Operational Considerations 630 4.1. The Meaning of "Short Term" and the Impact of Skewed Clocks 632 "Short Term" is a relative concept, therefore trying to define a cut- 633 off point that works in all cases would be a useless exercise. In 634 practice, the expected lifetime of a STAR certificate will be counted 635 in minutes, hours or days, depending on different factors: the 636 underlying requirements for revocation, how much clock 637 synchronization is expected among relying parties and the issuing CA, 638 etc. 640 Nevertheless, this section attempts to provide reasonable suggestions 641 for the Web use case, informed by current operational and research 642 experience. 644 Acer et al. [Acer] find that one of the main causes of "HTTPS error" 645 warnings in browsers is misconfigured client clocks. In particular, 646 they observe that roughly 95% of the "severe" clock skews - the 6.7% 647 of clock-related breakage reports which account for clients that are 648 more than 24 hours behind - happen to be within 6-7 days. 650 In order to avoid these spurious warnings about a not (yet) valid 651 server certificate, it is RECOMMENDED that site owners pre-date their 652 Web facing certificates by 5 to 7 days. The exact number depends on 653 the percentage of the "clock-skewed" population that the site owner 654 expects to protect - 5 days cover 97.3%, 7 days cover 99.6%. Note 655 that exact choice is also likely to depend on the kind of clients 656 that is prevalent for a given site or app - for example, Android and 657 Mac OS clients are known to behave better than Windows clients. 658 These considerations are clearly out of scope of the present 659 document. 661 In terms of security, STAR certificates and certificates with OCSP 662 must-staple [RFC7633] can be considered roughly equivalent if the 663 STAR certificate's and the OCSP response's lifetimes are the same. 664 Given OCSP responses can be cached on average for 4 days [Stark], it 665 is RECOMMENDED that a STAR certificate that is used on the Web has an 666 "effective" lifetime (excluding any pre-dating to account for clock 667 skews) no longer than 4 days. 669 4.2. Impact on Certificate Transparency (CT) Logs 671 Provided that the recommendations in Section 4.1 are followed, the 672 increase in Certificate Transparency (CT) [RFC6962] log ingestion 673 should be one order of magnitude in the worst case compared to the 674 current state. 676 The input received from most members of the CT community when the 677 issue was raised was that this should not represent a problem for the 678 CT architecture. 680 4.3. Dependability 682 When using authenticated POST-as-GET, the HTTPS endpoint from where 683 the STAR certificate is fetched can't be easily replicated by an on- 684 path HTTP cache. Reducing the caching properties of the protocol 685 makes STAR clients increasingly dependent on the ACME server 686 availability. This might be problematic given the relatively high 687 rate of client-server interactions in a STAR ecosystem. Clients and 688 servers should consider using the mechanism described in Section 3.4 689 to mitigate the risk. 691 5. Implementation Status 693 Note to RFC Editor: please remove this section before publication, 694 including the reference to [RFC7942]. 696 This section records the status of known implementations of the 697 protocol defined by this specification at the time of posting of this 698 Internet-Draft, and is based on a proposal described in [RFC7942]. 699 The description of implementations in this section is intended to 700 assist the IETF in its decision processes in progressing drafts to 701 RFCs. Please note that the listing of any individual implementation 702 here does not imply endorsement by the IETF. Furthermore, no effort 703 has been spent to verify the information presented here that was 704 supplied by IETF contributors. This is not intended as, and must not 705 be construed to be, a catalog of available implementations or their 706 features. Readers are advised to note that other implementations may 707 exist. 709 According to [RFC7942], "this will allow reviewers and working groups 710 to assign due consideration to documents that have the benefit of 711 running code, which may serve as evidence of valuable experimentation 712 and feedback that have made the implemented protocols more mature. 713 It is up to the individual working groups to use this information as 714 they see fit". 716 5.1. Overview 718 The implementation is constructed around 3 elements: STAR Client for 719 the Name Delegation Client (NDC), STAR Proxy for IdO and ACME Server 720 for CA. The communication between them is over an IP network and the 721 HTTPS protocol. 723 The software of the implementation is available at: 724 https://github.com/mami-project/lurk 726 The following subsections offer a basic description, detailed 727 information is available in https://github.com/mami- 728 project/lurk/blob/master/proxySTAR_v2/README.md 730 5.1.1. ACME Server with STAR extension 732 This is a fork of the Let's Encrypt Boulder project that implements 733 an ACME compliant CA. It includes modifications to extend the ACME 734 protocol as it is specified in this draft, to support recurrent 735 orders and cancelling orders. 737 The implementation understands the new "recurrent" attributes as part 738 of the Certificate issuance in the POST request for a new resource. 740 An additional process "renewalManager.go" has been included in 741 parallel that reads the details of each recurrent request, 742 automatically produces a "cron" Linux based task that issues the 743 recurrent certificates, until the lifetime ends or the order is 744 canceled. This process is also in charge of maintaining a fixed URI 745 to enable the NDC to download certificates, unlike Boulder's regular 746 process of producing a unique URI per certificate. 748 5.1.2. STAR Proxy 750 The STAR Proxy has a double role as ACME client and STAR Server. The 751 former is a fork of the EFF Certbot project that implements an ACME 752 compliant client with the STAR extension. The latter is a basic HTTP 753 REST API server. 755 The STAR Proxy understands the basic API request with a server. The 756 current implementation of the API is defined in draft-ietf-acme-star- 757 01. Registration or order cancellation triggers the modified Certbot 758 client that requests, or cancels, the recurrent generation of 759 certificates using the STAR extension over ACME protocol. The URI 760 with the location of the recurrent certificate is delivered to the 761 STAR client as a response. 763 5.2. Level of Maturity 765 This is a prototype. 767 5.3. Coverage 769 A STAR Client is not included in this implementation, but done by 770 direct HTTP request with any open HTTP REST API tool. This is 771 expected to be covered as part of the [I-D.sheffer-acme-star-request] 772 implementation. 774 This implementation completely covers STAR Proxy and ACME Server with 775 STAR extension. 777 5.4. Version Compatibility 779 The implementation is compatible with version draft-ietf-acme-star- 780 01. The implementation is based on the Boulder and Certbot code 781 release from 7-Aug-2017. 783 5.5. Licensing 785 This implementation inherits the Boulder license (Mozilla Public 786 License 2.0) and Certbot license (Apache License Version 2.0 ). 788 5.6. Implementation experience 790 To prove the concept all the implementation has been done with a 791 self-signed CA, to avoid impact on real domains. To be able to do it 792 we use the FAKE_DNS property of Boulder and static /etc/hosts entries 793 with domains names. Nonetheless this implementation should run with 794 real domains. 796 Most of the implementation has been made to avoid deep changes inside 797 of Boulder or Certbot, for example, the recurrent certificates 798 issuance by the CA is based on an external process that auto- 799 configures the standard Linux "cron" daemon in the ACME CA server. 801 The reference setup recommended is one physical host with 3 virtual 802 machines, one for each of the 3 components (client, proxy and server) 803 and the connectivity based on host bridge. 805 Network security is not enabled (iptables default policies are 806 "accept" and all rules removed) in this implementation to simplify 807 and test the protocol. 809 5.7. Contact Information 811 See author details below. 813 6. IANA Considerations 815 [[RFC Editor: please replace XXXX below by the RFC number.]] 817 6.1. New Error Types 819 This document adds the following entries to the ACME Error Type 820 registry: 822 +---------------------------------+---------------------+-----------+ 823 | Type | Description | Reference | 824 +---------------------------------+---------------------+-----------+ 825 | recurrentOrderCanceled | The short-term | RFC XXXX | 826 | | certificate is no | | 827 | | longer available | | 828 | | because the | | 829 | | recurrent order has | | 830 | | been explicitly | | 831 | | canceled by the IdO | | 832 | recurrentOrderExpired | The short-term | RFC XXXX | 833 | | certificate is no | | 834 | | longer available | | 835 | | because the | | 836 | | recurrent order has | | 837 | | expired | | 838 | recurrentCancellationInvalid | A request to cancel | RFC XXXX | 839 | | a recurrent order | | 840 | | that is not in | | 841 | | state "valid" has | | 842 | | been received | | 843 | recurrentRevocationNotSupported | A request to revoke | RFC XXXX | 844 | | a recurrent order | | 845 | | has been received | | 846 +---------------------------------+---------------------+-----------+ 848 6.2. New fields in Order Objects 850 This document adds the following entries to the ACME Order Object 851 Fields registry: 853 +------------------------------+---------+--------------+-----------+ 854 | Field Name | Field | Configurable | Reference | 855 | | Type | | | 856 +------------------------------+---------+--------------+-----------+ 857 | recurrent | string | true | RFC XXXX | 858 | recurrent-start-date | string | true | RFC XXXX | 859 | recurrent-end-date | string | true | RFC XXXX | 860 | recurrent-certificate- | integer | true | RFC XXXX | 861 | validity | | | | 862 | recurrent-certificate- | integer | true | RFC XXXX | 863 | predate | | | | 864 | recurrent-certificate-get | boolean | true | RFC XXXX | 865 | star-certificate | string | false | RFC XXXX | 866 +------------------------------+---------+--------------+-----------+ 868 6.3. New fields in the "meta" Object within a Directory Object 870 This document adds the following entries to the ACME Directory 871 Metadata Fields: 873 +----------------------------+------------+-----------+ 874 | Field Name | Field Type | Reference | 875 +----------------------------+------------+-----------+ 876 | star-enabled | boolean | RCF XXXX | 877 | star-min-cert-validity | integer | RCF XXXX | 878 | star-max-renewal | integer | RCF XXXX | 879 | star-allow-certificate-get | boolean | RFC XXXX | 880 +----------------------------+------------+-----------+ 882 6.4. Cert-Not-Before and Cert-Not-After HTTP Headers 884 The "Message Headers" registry should be updated with the following 885 additional values: 887 +-------------------+----------+----------+-----------------------+ 888 | Header Field Name | Protocol | Status | Reference | 889 +-------------------+----------+----------+-----------------------+ 890 | Cert-Not-Before | http | standard | RFC XXXX, Section 3.3 | 891 | Cert-Not-After | http | standard | RFC XXXX, Section 3.3 | 892 +-------------------+----------+----------+-----------------------+ 894 7. Security Considerations 896 7.1. No revocation 898 STAR certificates eliminate an important security feature of PKI 899 which is the ability to revoke certificates. Revocation allows the 900 administrator to limit the damage done by a rogue node or an 901 adversary who has control of the private key. With STAR 902 certificates, expiration replaces revocation so there is a timeliness 903 issue. To that end, see also the discussion on clock skew in 904 Section 4.1. 906 It should be noted that revocation also has timeliness issues, 907 because both CRLs and OCSP responses have nextUpdate fields that tell 908 relying parties (RPs) how long they should trust this revocation 909 data. These fields are typically set to hours, days, or even weeks 910 in the future. Any revocation that happens before the time in 911 nextUpdate goes unnoticed by the RP. 913 More discussion of the security of STAR certificates is available in 914 [Topalovic]. 916 7.2. Denial of Service Considerations 918 STAR adds a new attack vector that increases the threat of denial of 919 service attacks, caused by the change to the CA's behavior. Each 920 STAR request amplifies the resource demands upon the CA, where one 921 order produces not one, but potentially dozens or hundreds of 922 certificates, depending on the "recurrent-certificate-validity" 923 parameter. An attacker can use this property to aggressively reduce 924 the "recurrent-certificate-validity" (e.g. 1 sec.) jointly with other 925 ACME attack vectors identified in Sec. 10 of [RFC8555]. Other 926 collateral impact is related to the certificate endpoint resource 927 where the client can retrieve the certificates periodically. If this 928 resource is external to the CA (e.g. a hosted web server), the 929 previous attack will be reflected to that resource. 931 Mitigation recommendations from ACME still apply, but some of them 932 need to be adjusted. For example, applying rate limiting to the 933 initial request, by the nature of the recurrent behavior cannot solve 934 the above problem. The CA server needs complementary mitigation and 935 specifically, it SHOULD enforce a minimum value on "recurrent- 936 certificate-validity". Alternatively, the CA can set an internal 937 certificate generation processes rate limit. 939 7.3. Privacy Considerations 941 In order to avoid correlation of certificates by account, if 942 unauthenticated GET is negotiated (Section 3.4) the recommendation in 943 Section 10.5 of [RFC8555] regarding the choice of URL structure 944 applies, i.e. servers SHOULD choose URLs of certificate resources in 945 a non-guessable way, for example using capability URLs 946 [W3C.WD-capability-urls-20140218]. 948 8. Acknowledgments 950 This work is partially supported by the European Commission under 951 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 952 for a Middleboxed Internet (MAMI). This support does not imply 953 endorsement. 955 Thanks to Roman Danyliw, Jon Peterson, Eric Rescorla, Sean Turner and 956 Martin Thomson for helpful comments and discussions that have shaped 957 this document. 959 9. References 960 9.1. Normative References 962 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 963 Requirement Levels", BCP 14, RFC 2119, 964 DOI 10.17487/RFC2119, March 1997, 965 . 967 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 968 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 969 . 971 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 972 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 973 DOI 10.17487/RFC7231, June 2014, 974 . 976 [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP 977 APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, 978 . 980 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 981 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 982 May 2017, . 984 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 985 Kasten, "Automatic Certificate Management Environment 986 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 987 . 989 9.2. Informative References 991 [Acer] Acer, M., Stark, E., Felt, A., Fahl, S., Bhargava, R., 992 Dev, B., Braithwaite, M., Sleevi, R., and P. Tabriz, 993 "Where the Wild Warnings Are: Root Causes of Chrome HTTPS 994 Certificate Errors", DOI 10.1145/3133956.3134007, 2017, 995 . 997 [I-D.ietf-acme-star-delegation] 998 Sheffer, Y., Lopez, D., Pastor, A., and T. Fossati, "An 999 ACME Profile for Generating Delegated STAR Certificates", 1000 draft-ietf-acme-star-delegation-00 (work in progress), 1001 December 2018. 1003 [I-D.nir-saag-star] 1004 Nir, Y., Fossati, T., Sheffer, Y., and T. Eckert, 1005 "Considerations For Using Short Term Certificates", draft- 1006 nir-saag-star-01 (work in progress), March 2018. 1008 [I-D.sheffer-acme-star-request] 1009 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 1010 Fossati, "Generating Certificate Requests for Short-Term, 1011 Automatically-Renewed (STAR) Certificates", draft-sheffer- 1012 acme-star-request-02 (work in progress), June 2018. 1014 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 1015 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 1016 . 1018 [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) 1019 Feature Extension", RFC 7633, DOI 10.17487/RFC7633, 1020 October 2015, . 1022 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1023 Code: The Implementation Status Section", BCP 205, 1024 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1025 . 1027 [Stark] Stark, E., Huang, L., Israni, D., Jackson, C., and D. 1028 Boneh, "The case for prefetching and prevalidating TLS 1029 server certificates", 2012, 1030 . 1033 [Topalovic] 1034 Topalovic, E., Saeta, B., Huang, L., Jackson, C., and D. 1035 Boneh, "Towards Short-Lived Certificates", 2012, 1036 . 1039 [W3C.WD-capability-urls-20140218] 1040 Tennison, J., "Good Practices for Capability URLs", World 1041 Wide Web Consortium WD WD-capability-urls-20140218, 1042 February 2014, 1043 . 1045 Appendix A. Document History 1047 [[Note to RFC Editor: please remove before publication.]] 1049 A.1. draft-ietf-acme-star-07 1051 o Changed the HTTP headers names and clarified the IANA 1052 registration, following feedback from the IANA expert reviewer 1054 A.2. draft-ietf-acme-star-06 1056 o Roman's AD review 1058 A.3. draft-ietf-acme-star-05 1060 o EKR's AD review 1061 o A detailed example of the timing of certificate issuance and 1062 predating 1063 o Added an explicit client-side parameter for predating 1064 o Security considerations around unauthenticated GET 1066 A.4. draft-ietf-acme-star-04 1068 o WG last call comments by Sean Turner 1069 o revokeCert interface handling 1070 o Allow negotiating plain-GET for certs 1071 o In STAR Orders, use star-certificate instead of certificate 1073 A.5. draft-ietf-acme-star-03 1075 o Clock skew considerations 1076 o Recommendations for "short" in the Web use case 1077 o CT log considerations 1079 A.6. draft-ietf-acme-star-02 1081 o Discovery of STAR capabilities via the directory object 1082 o Use the more generic term Identifier Owner (IdO) instead of Domain 1083 Name Owner (DNO) 1084 o More precision about what goes in the order 1085 o Detail server side behavior on cancellation 1087 A.7. draft-ietf-acme-star-01 1089 o Generalized the introduction, separating out the specifics of 1090 CDNs. 1091 o Clean out LURK-specific text. 1092 o Using a POST to ensure cancellation is authenticated. 1094 o First and last date of recurrent cert, as absolute dates. 1095 Validity of certs in seconds. 1096 o Use RFC7807 "Problem Details" in error responses. 1097 o Add IANA considerations. 1098 o Changed the document's title. 1100 A.8. draft-ietf-acme-star-00 1102 o Initial working group version. 1103 o Removed the STAR interface, the protocol between NDC and DNO. 1104 What remains is only the extended ACME protocol. 1106 A.9. draft-sheffer-acme-star-02 1108 o Using a more generic term for the delegation client, NDC. 1109 o Added an additional use case: public cloud services. 1110 o More detail on ACME authorization. 1112 A.10. draft-sheffer-acme-star-01 1114 o A terminology section. 1115 o Some cleanup. 1117 A.11. draft-sheffer-acme-star-00 1119 o Renamed draft to prevent confusion with other work in this space. 1120 o Added an initial STAR protocol: a REST API. 1121 o Discussion of CDNI use cases. 1123 A.12. draft-sheffer-acme-star-lurk-00 1125 o Initial version. 1127 Authors' Addresses 1129 Yaron Sheffer 1130 Intuit 1132 EMail: yaronf.ietf@gmail.com 1134 Diego Lopez 1135 Telefonica I+D 1137 EMail: diego.r.lopez@telefonica.com 1138 Oscar Gonzalez de Dios 1139 Telefonica I+D 1141 EMail: oscar.gonzalezdedios@telefonica.com 1143 Antonio Agustin Pastor Perales 1144 Telefonica I+D 1146 EMail: antonio.pastorperales@telefonica.com 1148 Thomas Fossati 1149 ARM 1151 EMail: thomas.fossati@arm.com