idnits 2.17.1 draft-nir-saag-star-00.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 14, 2017) is 2379 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5246' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC7296' is defined on line 606, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-07 == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-07 -- Duplicate reference: draft-ietf-acme-acme, mentioned in 'I-D.ietf-acme-star', was also mentioned in 'I-D.ietf-acme-acme'. -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAAG Y. Nir 3 Internet-Draft Dell EMC 4 Intended status: Informational T. Fossati 5 Expires: April 17, 2018 Nokia 6 Y. Sheffer 7 Intuit 8 October 14, 2017 10 Considerations For Using Short Term Certificates 11 draft-nir-saag-star-00 13 Abstract 15 Recently there has been renewed interest in an old idea: Issue 16 certificates with short validity periods and forego revocation 17 processing, reasoning that expiration is a sufficient replacement for 18 revocation as long as that expiration is not too far off. 20 This document covers considerations, both security and operational, 21 for using such Short Term Auto Renewed (STAR) certificates for 22 various scenarios where Using a revocation protocol is considered 23 inappropriate. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 17, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 61 2. Short Term Auto Renewed Certificates . . . . . . . . . . . . 4 62 2.1. Alternative Design: OCSP Stapling . . . . . . . . . . . . 5 63 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Data Center Network Hosts . . . . . . . . . . . . . . . . 5 65 3.2. Distributed System Installed in One Or More Data Centers 5 66 3.2.1. Distributed Network Security Functions . . . . . . . 5 67 3.3. Certificate Delegation for Content Delivery Networks . . 6 68 4. Operational Considerations . . . . . . . . . . . . . . . . . 6 69 4.1. Certificate Lifetime and Renewal Schedule . . . . . . . . 6 70 4.2. Availability of the Certificate Authority . . . . . . . . 7 71 4.3. Clock Skew and the notBefore Field . . . . . . . . . . . 7 72 4.4. Automatic Renewal . . . . . . . . . . . . . . . . . . . . 8 73 4.5. Certificate Transparency . . . . . . . . . . . . . . . . 9 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 5.1. Reasons for Revocation . . . . . . . . . . . . . . . . . 10 76 5.2. Longevity and Revocation . . . . . . . . . . . . . . . . 10 77 5.3. Clock Skew and Security . . . . . . . . . . . . . . . . . 11 78 5.4. CA availability . . . . . . . . . . . . . . . . . . . . . 11 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 7.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 Certificates ([RFC5280]) are used in multiple protocols such as the 88 Internet Key Exchange (IKEv2-[RFC7296]) and the Transport Layer 89 Security protocol (TLS-[RFC5246]). Certificates are used to 90 authenticate communicating parties to each other. Certificates are 91 issued by Certificate Authorities (CAs) to End Entities (EE) to be 92 used to authenticate them to Relying Parties (RPs) in security 93 protocols. Systems that use secure communications typically include 94 certificate authorities, end entities and relying parties, with some 95 nodes in the network having more than one of these roles. 97 When deploying a system involving secure communications, one of the 98 challenges is how to deal with an End Entity losing control of its 99 private key or having its secrecy potentially compromised. The 100 standardized ways of dealing with this is adding a protocol layer for 101 revocation such as CRLs ([RFC5280]) or OCSP ([RFC6960]). 103 Such revocation protocols have drawbacks. Although caching of CRLs 104 and OCSP responses is allowed, each setup of a secure channel may 105 require accessing the CRL distribution point (DP) or the OCSP 106 responder. This is both time consuming and provides the system with 107 a few more modes of failure. Assuring reliability of the revocation 108 service increases the cost, and overcoming the latency issue requires 109 changes to the security protocols. 111 For these reasons it is attractive to forego revocation checking. 112 Some deployed systems do this by either eliminating the CRL DP and 113 OCSP extensions from the certificates, or ignoring network and 114 timeout errors in fetching revocation information. Both practices 115 reduce the efficacy of revocation. 117 An alternative solution to the revocation problem is to issue 118 certificates with a short validity period. Normally certificates are 119 issued with a validity period of between a few months and a few 120 years. With a shorter validity period if the private key is 121 compromised the potential for abuse is lower because the certificate 122 and its private key expire within a short period of time - a few 123 hours to a few days. 125 The rest of this document describes operational and security 126 considerations with using short term certificates. 128 1.1. Conventions Used in This Document 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 Throughout this document we will use the term DP to denote a server 135 for revocation information, either a CRL distribution point or an 136 OCSP Responder. For our purposes they are the same. 138 We use the term longevity for the period of time between certificate 139 issuance and the time of its expiration as indicated in the notAfter 140 field of the certificate. Note that issuance time may be different 141 from the notBefore field in the certificate. 143 The text describes end entities as renewing their certificates 144 because the usual operational model for certificates is one of 145 "pull": end entities create certificate requests and send them to CAs 146 for signature. Some systems are designed around a "push" operation 147 where either the CA or a management function generates a new 148 certificate and installs it on the end entity. The text in the 149 document uses pull terminology, but is equally relevant for push 150 design. 152 2. Short Term Auto Renewed Certificates 154 Short term certificates are like any other [RFC5280] certificates 155 except that the period of time between their issuance and their 156 notAfter date is relatively short. Whereas normally certificates are 157 issued for a period of time between a few months and a few years, 158 short term certificates usually expire after a few hours, a few days, 159 or at a limit a couple of weeks. 161 While it is not a part of the definition, short term certificates 162 typically have neither a CRL DP extension nor an OCSP 163 authorityInformationAccess extension. In other words such 164 certificates cannot be revoked. Instead, they are valid until they 165 expire. 167 Automatic certificate renewal is getting ever more popular with 168 enrollment protocols such as EST ([RFC7030]) or ACME 169 ([I-D.ietf-acme-acme]). For short term certificates automatic 170 renewal is essential as a human cannot be expected to flawlessly 171 perform a manual renewal every few days or hours. This document does 172 not recommend any particular automatic renewal method, but does 173 recommend (Section 4.4) that some such method be used. Automatic 174 renewal processing can roll over the keys from one certificate to its 175 successor, or it can generate new keys with each Certificate 176 generation. As revocation may not exist, multiple certificates for 177 the same EE may be valid at any given time. 179 The solution for revocation in this scheme is to stop the automatic 180 renewal. The existing compromised certificate will remain valid 181 until it expires. See the considerations in Section 5.1 about 182 revocation. 184 [Topalovic] describes the design of a system involving STAR 185 certificates for the web, and analyzes its security and efficacy. It 186 concludes that STAR certificates can be as secure as certificates 187 with OCSP revocation. 189 2.1. Alternative Design: OCSP Stapling 191 Relying parties can also avoid the need for contacting the DP at 192 connection setup by having the End Entities implement OCSP stapling. 193 This feature has the EEs rather than the RPs retrieve the OCSP 194 response and send it as part of the protocol. OCSP stapling is 195 described for TLS in [RFC6961] and [RFC6066], and for IKE in 196 [RFC4806]. 198 STAR has two advantages over OCSP stapling: 200 o A CA that only signs certificates is simpler than a CA that both 201 signs certificates and issues OCSP responses. In fact, a CA for 202 STAR does not need to keep any record of issued certificates. 204 o OCSP stapling in TLS works only for the server as end entity. 205 There is no provision for sending the OCSP response for a client 206 certificate in the protocol. 208 3. Use Cases 210 This section lists some use cases where STAR certificates seem to be 211 more appropriate than long-lived certificates with revocation 212 checking. The purpose of this section is only motivational. None of 213 the following sections are intended to be a definition of the use 214 case or the standard by which future documents or implementations 215 will be measured for sufficiency. 217 3.1. Data Center Network Hosts 219 TBA 221 3.2. Distributed System Installed in One Or More Data Centers 223 This is a system installed in multiple hosts in one or more data 224 centers that fulfills some task and requires mutual authentication of 225 its components. An example of such a system is a Storage Area 226 Network (SAN). 228 3.2.1. Distributed Network Security Functions 230 This example of a distributed system is multiple network security 231 functions (NSF) [RFC8192] where the SDN controller needs to 232 authenticate the NSFs with which it communicates, and some NSFs need 233 to communicate with each other. 235 3.3. Certificate Delegation for Content Delivery Networks 237 TBA 239 4. Operational Considerations 241 The motivations for using short-term certificates are operational. 242 We don't want the latency introduced by fetching the CRL from the DP; 243 we don't want the cost of making the DP 99.999% reliable, and we 244 don't want the cost of making the network paths from all RPs to the 245 DP always available. 247 Deploying short term certificates comes with its own set of 248 operational considerations, and some of these are enumerated in the 249 following sub-sections. 251 4.1. Certificate Lifetime and Renewal Schedule 253 Since we do not assume the CA to be close to 100% available it makes 254 sense for End Entities to renew their certificates well in advance. 255 While the security considerations in Section 5.2 set an upper limit 256 on the longevity of a STAR certificate, operational necessity sets 257 the frequency of renewal. It is necessary to strike a balance 258 between renewing too often which leads to increased load on the CA 259 and renewing too seldom which increases the risk of having the 260 certificate expire while either the CA or the End Entity are down. 262 Individual system properties play a significant role here. Systems 263 where both the CA and the EEs are expected to be up all of the time 264 absent a fault may choose to renew a day or even an hour before 265 expiration, while systems with nodes that are only up infrequently 266 and for short periods of time may choose to renew the certificates 267 whenever the EEs happen to be up. 269 As a general rule of thumb for systems where the CA is mostly 270 available it makes sense for the EE to make the first attempt to 271 renew its certificate about half-way through its lifetime. If that 272 attempt fails because the CA is not available an EE SHOULD retry at 273 regular intervals until it succeeds. Shortly before expiration, the 274 EE SHOULD increase the frequency of retires. 276 For example, suppose a STAR certificate is issued for 8 days. The EE 277 will first attempt to renew the certificate 4 days before expiration. 278 If that fails it will retry every three hours until only six hours 279 are left before expiration. At that point it will increase the 280 frequency and retry every five minutes. If this is part of the 281 system design, at this point it should also alert the user that 282 something is wrong. 284 4.2. Availability of the Certificate Authority 286 While the STAR design does not require 99.999% availability, the CA 287 does need to be available for renewing certificates. Downtimes of 288 more than a quarter of the certificate longevity SHOULD NOT happen. 289 For most modern hardware this is entirely possible even without 290 exotic clustering solutions, but when configuring the system 291 administrators should consider that the longevity of the certificates 292 constrains the required availability of the CA. 294 When setting the longevity for certificates administrators SHOULD 295 consider how long it takes to recover from a failure of the CA. That 296 length of time can be seconds with a good clustering solution, but 297 can span hours or days without one, especially if the fault happens 298 at a bad time. A failure of a CA should be considered a conceivable 299 occurrence, and longevity should be set so that such a failure does 300 not lead to expiration and outage. 302 Conversely, if short longevity is required by security targets, the 303 CA should be made more reliable with clustering solutions. 305 4.3. Clock Skew and the notBefore Field 307 Despite NTP ([RFC5905]) being over thirty years old and implemented 308 in every major operating system clock skew is a fact of life and many 309 deployed systems don't have the right time. It is also not possible 310 to just mandate the use of NTP because the systems that use STAR 311 certificates are often installed on hosts and networks where NTP is 312 either not configured or blocked. We cannot assume that these 313 systems can enable NTP at will. 315 Skewed clocks have always been a problem for certificates. Because 316 STAR certificates are always just a few days or hours from expiration 317 they are more sensitive to clock skew. A sufficiently skewed clock 318 can cause three different disfunctions and for STAR certificate such 319 disfunction happens with considerably less skew than with long term 320 certificates: 322 o A valid certificate may be rejected as not yet valid if the 323 current system time is earlier than its notBefore time. 324 Fortunately this issue can be safely mitigated by setting the 325 notBefore field to a time earlier than the time of issuance. 327 o A valid certificate may be rejected as expired if the current 328 system time is later than its notAfter time. As long as the clock 329 skew is not too great this is solved by a sensible renewal policy. 330 If as in the example in Section 4.1 the certificate is renewed 4 331 days before expiration or within a few hours after that, a clock 332 skew of up to 3 days will not be a problem. 334 o An expired certificate may be accepted if the current system time 335 is earlier than its notAfter time. This is a security issue that 336 is discussed in Section 5.3. 338 There are several common modes of clock skew: 340 o The system that doesn't have its clock set at all. These systems 341 might be set to January 1st, 1970 or to some date that was 342 interesting for the hardware vendor. Such systems are 343 incompatible with certificates and MUST NOT be used for STAR 344 certificates. 346 o The system has its timezone set wrong, and the system time was set 347 so that local time looks good. This limits the clock skew to 24 348 hours and is generally workable. 350 o A system that has the time set right but the date set wrong. 351 These are also not usable with certificates. 353 o A system that was set to the correct time once but has since 354 drifted away. Computer hardware varies wildly between systems 355 with quartz clocks that drift only a few seconds a month and 356 systems that can lose or gain minutes a day. The former are quite 357 usable, the latter are not. 359 Because of the prevalence of systems with a relatively small skew it 360 is RECOMMENDED to set the notBefore field to a time 72 hours before 361 the actual issuance date. 363 End Entities MUST NOT use expired certificates and Relying Parties 364 SHOULD alert whenever an expired certificate is presented. This will 365 help the users keep their host clocks set or encourage them to enable 366 NTP. 368 4.4. Automatic Renewal 370 Automatic enrollment and renewal is recommended for any system using 371 certificates. While it is possible to renew certificates manually on 372 time, even organizations with the best of IT departments occasionally 373 miss this: [cert-expires] 375 With short term certificates, this becomes even more important. 376 Renewing a certificate manually every few days or hours is extremely 377 labor intensive, especially when the system contains hundreds, 378 thousands or more end entities, and the risk of outages becomes a 379 certainty. 381 This document does not mandate any particular enrollment or renewal 382 mechanism. Any of a myriad of standard and proprietary methods can 383 be used and systems with proprietary methods have been shipping for 384 years. The IETF is in the process of standardizing the ACME protocol 385 for enrollment and renewal ([I-D.ietf-acme-acme]) and an extension is 386 proposed to make it more suitable for STAR certificates 387 ([I-D.ietf-acme-star]). 389 4.5. Certificate Transparency 391 Certificate Transparency (CT), [RFC6962] is about keeping a log of 392 all issued certificates. 394 A system that issues a certificate every few days to thousands or end 395 entities will create more records for a CT log than a web host that 396 gets one certificate every year. 398 TBA: Discussion about this. 400 5. Security Considerations 402 STAR certificates eliminate an important security feature of PKI 403 which is the ability to revoke certificates. Revocation allows the 404 administrator to limit the damage done by a rogue node or an 405 adversary who has control of the private key. With STAR certificates 406 expiration replaces revocation so there is a timeliness issue. 408 It should be noted that revocation also has timeliness issues, 409 because both CRLs and OCSP responses have nextUpdate fields that tell 410 RPs how long they should trust this revocation data. These fields 411 are typically set to hours, days, or even weeks in the future. Any 412 revocation that happens before the time in nextUpdate goes unnoticed 413 by the RP. 415 Section 5.1 discusses the reasons why a certificate would be revoked 416 if revocation was available and how STAR certificates do the same. 417 Section 5.2 discusses considerations for setting the longevity of a 418 certificate, and Section 5.3 discusses how longevity should be 419 adjusted to deal with clock skew. 421 More discussion of the security of STAR certificates is available in 422 [Topalovic]. 424 5.1. Reasons for Revocation 426 There are two types of compromise that require administrators to 427 revoke a certificate: 429 o A host has lost control of the private key. There are many ways 430 that this can happen: a host can be hacked and a file containing 431 the private key may or may not have been copied; a disk may be 432 replaced and the old one has not been securely disposed of; a 433 fault causes the private key to be erased. In all these cases we 434 would like to revoke the certificate to make sure an adversary 435 cannot use the private key for nefarious purposes. For STAR 436 certificates the only solution is to wait for the certificate to 437 expire and the system is vulnerable until that happens. Longevity 438 should be set so that this risk is acceptable. 440 o A host may begin doing unintended things, either due to a software 441 fault or due to a malicious takeover. Again without revocation 442 RPs will continue to trust this node until its certificate 443 expires. 445 When a node "goes rogue" or an adversary gets control of the private 446 key it is important to block renewal or these certificates or else 447 the attack can persist forever. No matter how short-term these short 448 term certificates are, there is a certain window of time when the 449 attacker can use the certificate. This can often be mitigated with 450 application-level measures. 452 With most systems relying parties are configured with the names of 453 nodes with which they are allowed to communicate. When revocation is 454 not available changing the configuration so that the rogue node 455 cannot connect is RECOMMENDED. This is useful even when revocation 456 is available because timeliness issues are common to both revocation 457 and expiration. 459 5.2. Longevity and Revocation 461 There is always a period of time between when a compromise is 462 discovered and when RPs stop trusting the certificate. With 463 revocation this has to do with the time it takes to process the 464 revocation and the span of time between the thisUpdate and nextUpdate 465 fields. With STAR certificates this is controlled by the time it 466 takes to inhibit renewals and the longevity of the certificates. 468 For this reason it makes sense to set the longevity to a period of 469 time similar to the span of time that we would set for the CRL or 470 OCSP updates. Typically a few days is an appropriate time. For some 471 cases this can be as low as a few hours. Setting the renewal time 472 too short may cause operational problems as discussed in Section 4.3 473 and Section 4.2. In general longevity should not be set shorter than 474 the availability of the CA allows. 476 Fortunately modern hardware is powerful enough and reliable enough 477 that even a system with tens of thousands of end entities with 478 longevity of 1-2 days should not suffer an outage because of expired 479 certificates. 481 5.3. Clock Skew and Security 483 As discussed in Section 4.3 clock skew can lead to expired 484 certificates being treated as valid. While even the use of NTP may 485 leave clocks with a few seconds of inaccuracy, all installations MUST 486 take steps to limit the clock skew on their hosts. 488 An upper bound for the amount of skew allowed for hosts in a 489 particular system is one of the parameters for such a system. For 490 systems using NTP this can be 2 seconds. For systems where the 491 clocks are set manually, this tends to be far greater, but without an 492 upper bound no guarantees can be made about the security of 493 certificate use. 495 This upper bound is also a limit on the target certificate longevity. 496 For example, if hosts and CAs can each have a clock skew of 24 hours 497 then it is impossible to achieve a longevity of under 48 hours. With 498 a reasonable skew and a reasonable target longevity we can achieve 499 our security targets by reducing the certificate longevity by twice 500 the upper bound for skew. So if skew is bounded by 24 hours (the bad 501 timezone case) and target longevity is 7 days, it makes sense to set 502 the longevity on the CA to 5 days. 504 5.4. CA availability 506 A successful Denial of Service (DoS) attack against a CA prevents it 507 from issuing certificates. With short-term certificates this could 508 quickly lead to outages as certificates expire. 510 The important period of time here is the time between when the EE 511 first attempts to renew the certificate and the time that the 512 certificate expires. For example, if the EE attempts to renew the 513 certificates a mere five minutes before expiration, then a five- 514 minute CA outage can lead to an invalid certificate and failed 515 connections. 517 This issue is no different from DoS attacks against the DP for 518 certificates with revocation. The methods of protection are also 519 similar: 521 o Certificate renewal should first be attempted plenty of time in 522 advance as recommended in Section 4.1. This will leave enough 523 time for administrators to deal with the attack. 525 o As for all important infrastructure, network defenses SHOULD be 526 deployed to mitigate DoS attacks. 528 6. IANA Considerations 530 There are no requests to IANA in this document. 532 7. References 534 7.1. Normative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, 538 DOI 10.17487/RFC2119, March 1997, 539 . 541 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 542 Housley, R., and W. Polk, "Internet X.509 Public Key 543 Infrastructure Certificate and Certificate Revocation List 544 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 545 . 547 7.2. Informative References 549 [cert-expires] 550 Lennon, M., "Google Lets SMTP Certificate Expire", April 551 2015, . 554 [I-D.ietf-acme-acme] 555 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 556 Certificate Management Environment (ACME)", draft-ietf- 557 acme-acme-07 (work in progress), June 2017. 559 [I-D.ietf-acme-star] 560 Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor 561 Perales, A., and T. Fossati, "Use of Short-Term, 562 Automatically-Renewed (STAR) Certificates to Delegate 563 Authority over Web Sites", draft-ietf-acme-acme-07 (work 564 in progress), June 2017. 566 [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status 567 Protocol (OCSP) Extensions to IKEv2", RFC 4806, 568 DOI 10.17487/RFC4806, February 2007, 569 . 571 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 572 (TLS) Protocol Version 1.2", RFC 5246, 573 DOI 10.17487/RFC5246, August 2008, 574 . 576 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 577 "Network Time Protocol Version 4: Protocol and Algorithms 578 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 579 . 581 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 582 Extensions: Extension Definitions", RFC 6066, 583 DOI 10.17487/RFC6066, January 2011, 584 . 586 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 587 Galperin, S., and C. Adams, "X.509 Internet Public Key 588 Infrastructure Online Certificate Status Protocol - OCSP", 589 RFC 6960, DOI 10.17487/RFC6960, June 2013, 590 . 592 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 593 Multiple Certificate Status Request Extension", RFC 6961, 594 DOI 10.17487/RFC6961, June 2013, 595 . 597 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 598 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 599 . 601 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 602 "Enrollment over Secure Transport", RFC 7030, 603 DOI 10.17487/RFC7030, October 2013, 604 . 606 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 607 Kivinen, "Internet Key Exchange Protocol Version 2 608 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 609 2014, . 611 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 612 and J. Jeong, "Interface to Network Security Functions 613 (I2NSF): Problem Statement and Use Cases", RFC 8192, 614 DOI 10.17487/RFC8192, July 2017, 615 . 617 [Topalovic] 618 Topalovic, E., Saeta, B., Huang, L., Jackson, C., and D. 619 Boneh, "Towards Short-Lived Certificates", 2012, 620 . 622 Authors' Addresses 624 Yoav Nir 625 Dell EMC 626 9 Andrei Sakharov St 627 Haifa 3190500 628 Israel 630 EMail: ynir.ietf@gmail.com 632 Thomas Fossati 633 Nokia 635 EMail: thomas.fossati@nokia.com 637 Yaron Sheffer 638 Intuit 640 EMail: yaronf.ietf@gmail.com