<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc rfcedstyle="yes" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >

<rfc ipr="trust200902" docName="draft-nir-saag-star-01" category="info">
  <front>
    <title abbrev="STAR Certificates">Considerations For Using Short Term Certificates</title>
    <author initials="Y." surname="Nir" fullname="Yoav Nir">
      <organization >Dell EMC</organization>
      <address>
        <postal>
          <street>9 Andrei Sakharov St</street>
          <city>Haifa</city>
          <code>3190500</code>
          <country>Israel</country>
        </postal>
        <email>ynir.ietf@gmail.com</email>
      </address>
    </author>
        <author initials="T." surname="Fossati" fullname="Thomas Fossati">
      <organization>Nokia</organization>
      <address>
        <email>thomas.fossati@nokia.com</email>
      </address>
    </author>
    <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
      <organization>Intuit</organization>
      <address>
        <email>yaronf.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Toerless Eckert" initials="T.T.E" surname="Eckert">
      <organization abbrev="Huawei">Huawei USA - Futurewei Technologies Inc.</organization>
      <address>
        <postal>
          <street>2330 Central Expy</street>
          <city>Santa Clara</city>
          <code>95050</code>
          <country>USA</country>
        </postal>
        <email>tte+ietf@cs.fau.de</email>
      </address>
    </author>

    <date year="2018"/>

<workgroup>SecDispatch</workgroup>

    <abstract>
      <t> Recently there has been renewed interest in an old idea: Issue certificates with
        short validity periods and forego revocation processing, reasoning that expiration
        is a sufficient replacement for revocation as long as that expiration is not too
        far off.</t>
      <t> This document covers considerations, both security and operational, for using 
        such Short Term Auto Renewed (STAR) certificates for various scenarios where Using
        a revocation protocol is considered inappropriate.</t>
    </abstract>
  </front>
  <middle>
    <!-- ====================================================================== -->
    <section anchor="introduction" title="Introduction">
      <t> Certificates (<xref target="RFC5280"/>) are used in multiple protocols such as 
        the Internet Key Exchange (IKEv2-<xref target="RFC7296"/>) and the Transport Layer 
        Security protocol (TLS-<xref target="RFC5246"/>). Certificates are used to 
        authenticate communicating parties to each other. Certificates are issued by 
        Certificate Authorities (CAs) to End Entities (EE) to be used to authenticate them 
        to Relying Parties (RPs) in security protocols. Systems that use secure 
        communications typically include certificate authorities, end entities and relying
        parties, with some nodes in the network having more than one of these roles.</t>
      <t> When deploying a system involving secure communications, one of the challenges 
        is how to deal with compromise of an End Entity's private key. The standard way of 
        dealing with this is adding a protocol layer for revocation such as CRLs 
        (<xref target="RFC5280"/>) or OCSP (<xref target="RFC6960"/>).</t>
      <t> Such revocation protocols have drawbacks. Although caching of CRLs and OCSP 
        responses is allowed, each setup of a secure channel may require accessing the CRL
        distribution point (DP) or the OCSP responder. This is both time consuming and 
        provides the system with a few more modes of failure. Assuring reliability of the
        revocation service increases the cost, and overcoming the latency issue requires
        changes to the security protocols. All other things being equal, a system that 
        includes revocation checking is more complex and less reliable than a system that
        does not include it.</t>
      <t> For these reasons it is attractive to forego revocation checking. Some deployed 
        systems do this by either eliminating the CRL DP and OCSP extensions from the 
        certificates, or ignoring network and timeout errors in fetching revocation 
        information. Both practices reduce the security of the system.</t>
      <t> An alternative solution to the revocation problem is to issue certificates with
        a short validity period and forego revocation checking. Normally certificates are 
        issued with a validity period of between a few months and a few years. With a 
        shorter validity period if the private key is compromised the potential for abuse 
        is lower because the certificate and its private key expire within a short period 
        of time - a few hours to a few days.</t>
      <t> The rest of this document describes operational and security considerations with
        using short term certificates.</t>
      <section anchor="mustshouldmay" title="Conventions Used in This Document">
        <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
          "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
          interpreted as described in <xref target="RFC2119"/>.</t>
        <t> Throughout this document we will use the term DP to denote a server for 
          revocation information, either a CRL distribution point or an OCSP Responder. 
          For our purposes they are the same.</t>
        <t> We use the term longevity for the period of time between certificate issuance
          and the time of its expiration as indicated in the notAfter field of the 
          certificate. Note that issuance time may be different from the notBefore field
          in the certificate.</t>
        <t> The text describes end entities as renewing their certificates because the 
          usual operational model for certificates is one of "pull": end entities create
          certificate requests and send them to CAs for signature. Some systems are
          designed around a "push" operation where either the CA or a management function
          generates a new certificate and installs it on the end entity. The text in the
          document uses pull terminology, but is equally relevant for a push design.</t>
      </section>
    </section>
    <section anchor="star" title="Short Term Auto Renewed Certificates">
      <t> Short term certificates are like any other <xref target="RFC5280"/> certificates 
        except that the period of time between their issuance and their notAfter date is 
        relatively short. Whereas normally certificates are issued for a period of time 
        between a few months and a few years, short term certificates usually expire after
        a few hours, a few days, or at a limit a couple of weeks.</t>
      <t> The certificates discussed in this document have neither a CRL DP extension nor 
        an OCSP authorityInformationAccess extension. In other words such certificates 
        cannot be revoked. Instead, they are valid until they expire.</t>
      <t> Automatic certificate renewal is getting ever more popular with enrollment 
        protocols such as EST (<xref target="RFC7030"/>) or ACME (<xref target="I-D.ietf-acme-acme"/>). 
        For short term certificates automatic renewal is essential as a human cannot be 
        expected to flawlessly perform a manual renewal every few days or hours. This 
        document does not recommend any particular automatic renewal method, but <xref 
        target="auto"/> recommends that some such method be used. Automatic renewal 
        processing can roll over the keys from one certificate to its successor, or 
        it can generate new keys with each Certificate generation. As revocation may not 
        exist, multiple certificates for the same EE may be valid at any given time.</t>
      <t> The solution for revocation in this scheme is to stop the automatic renewal. The 
        existing compromised certificate will remain valid until it expires. See the 
        considerations in <xref target="sec-revoc"/> about revocation.</t>
      <t> <xref target="Topalovic"/> describes the design of a system involving STAR
        certificates for the web, and analyzes its security and efficacy. It concludes 
        that STAR certificates can be as secure as certificates with OCSP revocation.</t>
      <section anchor="altdesign" title="Alternative Design: OCSP Stapling">
        <t> Relying parties can also avoid the need for contacting the DP at connection 
          setup by having the End Entities implement OCSP stapling. This feature has the 
          EEs rather than the RPs retrieve the OCSP response and send it as part of the 
          protocol. OCSP stapling is described for TLS in <xref target="RFC6961"/> and
          <xref target="RFC6066"/>, and for IKE in <xref target="RFC4806"/>.</t>
        <t> STAR has several advantages over OCSP stapling: <list style="symbols">
          <t> A CA that only signs certificates is simpler than a CA that both signs 
            certificates and issues OCSP responses. In fact, a CA for STAR does not need
            to keep any record of issued certificates.</t>
          <t> A system that does not use CRLs or OCSP need not have an always-available 
            DP for delivering those CRLs or OCSP responses. This reduces both complexity 
            and attack surface.</t>
          <t> OCSP stapling in TLS versions prior to 1.3 works only for the server as end 
            entity. There was no provision for sending the OCSP response for a client 
            certificate in the protocol.</t></list></t>
      </section>
      <section anchor="casefor" title="The Case For Foregoing Revocation">
        <t> When explaining PKI to people, it is hard to justify why the CA or a delegate
          needs to both sign blob-1 (the certificate) and also sign blob-2 (the CRL or 
          OCSP response) to tell relying parties that blob-1 is still valid. Surely one 
          signed blob should be enough.</t>
        <t> The explanation that we come up with is that traditionally issuing a 
          certificate required human intervention, while the revocation checking object
          could be issued automatically and at great frequency. So blob-1 would have to
          be valid for long enough to not over-burden the human charged with maintaining 
          them, while blob-2 could be re-issued frequently.</t>
        <t> This explanation no longer holds up. While the initial certificate enrollment 
          may need to be initiated by a human, protocols exist today that make certificate
          renewal just as automated as CRL issuance. Certificates can be just as frequently 
          issued as CRLs were in the past. The added complexity is no longer needed.</t>
        <t> In real systems such as the web relying parties or end entities cache 
          revocation objects as long as it's allowed. If a CRL has a nextUpdate field that
          is 4 days in the future, a typical system will not attempt to fetch a new one 
          before those 4 days have elapsed. For this reason, moving to STAR certificates 
          provides a similar level of security to what is generally practiced on the web.</t>
      </section>
    </section>
    <section anchor="usecases" title="Use Cases">
      <t> This section lists some use cases where STAR certificates seem to be more 
        appropriate than long-lived certificates with revocation checking. The purpose of
        this section is only motivational. None of the following sections are intended to
        be a definition of the use case or the standard by which future documents or 
        implementations will be measured for sufficiency.</t>
      <section anchor="dcnodes" title="Data Center Network Hosts">
        <t> TBA</t>
      </section>
      <section anchor="dcsys" title="Distributed System Installed in One Or More Data Centers">
        <t> This is a system installed in multiple hosts in one or more data centers that 
          fulfills some task and requires mutual authentication of its components. An 
          example of such a system is a Storage Area Network (SAN).</t>
        <section anchor="dcnsf" title="Distributed Network Security Functions">
          <t> This example of a distributed system is multiple network security functions
            (NSF) <xref target="RFC8192"/> where the SDN controller needs to authenticate 
            the NSFs with which it communicates, and some NSFs need to communicate with 
            each other.</t>
        </section>
      </section>
      <section anchor="deleg" title="Certificate Delegation for Content Delivery Networks">
        <t> TBA</t>
      </section>
      <section anchor="ANI" title="Autonomic Networking Infrastructure">
        <t>The Autonomic Network Infrastructure (see <xref target="I-D.ietf-anima-reference-model"/>)
          is an IETF ANIMA Working Group developed network system architecture to provide  the
	  foundation for both future "autonomic networks" (AN), as well as the infrastructure to
	  enable zero-touch secure bootstrapping of domain-wide PKI certificates for network
	  equipment (BRSKI, see <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>) as well as the
	  set-up of a zero-touch, secure communications fabric for management of existing networks
	  (ACP, see <xref target="I-D.ietf-anima-autonomic-control-plane"/>, especially in the context
	  of evolving SDN control &amp; management (see <xref target="I-D.ietf-anima-stable-connectivity"/>) .
          These domain certificates are furthermore meant to be reuseable across
	  all network services between network equipment in that domain, therefore allowing to
	  eliminate the need for per-service crypto management (IGP, multicast, BGP, netconf/COPS/radius
	  connections,...).</t>
	<t>Overall, the PKI related functions of ANI intend to increase proliferation of PKI
	  security through simplification, achieved through automation and making solutions more
	  resilient by minimizing managed component requirements. CRL or OCSP introduce another
	  set of servers/services that needs to be managed/automated/distributed. The connectivity
	  requirement to such servers and/or the grace periods during which connectivity to them
	  is not required introduce more complex system/security design parameters.</t>
	<t>With ANI/ACP/BRSKI, renewal of certificates is fully automated and therefore shorter lifetimes
	  of certificates can easily be used to avoid the additional need for CRL/OCSP.
	  The limitation on reducing certificate lifetimes is only the desired maximum length of
	  time during which connectivity to a CA for renewal may not exist - and the maximum renewal
	  rate of certificates that can be supported by those CA.</t>
        <t>Because of the ACP, connectivity to the CA is also more resilient against
	  network/provisioning/configuration problems than network without an ACP.
	  Lastly, the whole ANI is built and maintained autonomously without the need of
	  any configurations except for one or more seed-nodes that perform an expanded version
	  of a PKI Registration Authority.</t>
      </section>
    </section>
    <section anchor="op" title="Operational Considerations">
      <t> The motivations for using short-term certificates are operational. We don't want
        the latency introduced by fetching the CRL from the DP; we don't want the cost of 
        making the DP 99.999% reliable, and we don't want the cost of making the network 
        paths from all RPs to the DP always available.</t> 
      <t> Deploying short term certificates comes with its own set of operational 
        considerations, and some of these are enumerated in the following sub-sections.</t>
      <section anchor="schedule" title="Certificate Lifetime and Renewal Schedule">
        <t> Since we do not assume the CA to be close to 100% available it makes sense for
          End Entities to renew their certificates well in advance. While the security 
          considerations in <xref target="sec-longevity"/> set an upper limit on the 
          longevity of a STAR certificate, operational necessity sets the frequency of 
          renewal. It is necessary to strike a balance between renewing too often which 
          leads to increased load on the CA and renewing too seldom which increases the 
          risk of having the certificate expire while either the CA or the End Entity are
          down.</t>
        <t> Individual system properties play a significant role here. Systems where both
          the CA and the EEs are expected to be up all of the time absent a fault may 
          choose to renew a day or even an hour before expiration, while systems with 
          nodes that are only up infrequently and for short periods of time may choose to
          renew the certificates whenever the EEs happen to be up.</t>
        <t> As a general rule of thumb for systems where the CA is mostly available it 
          makes sense for the EE to make the first attempt to renew its certificate about
          half-way through its lifetime. If that attempt fails because the CA is not 
          available an EE SHOULD retry at regular intervals until it succeeds. Shortly 
          before expiration, the EE SHOULD increase the frequency of retires.</t>
        <t> For example, suppose a STAR certificate is issued for 8 days. The EE will 
          first attempt to renew the certificate 4 days before expiration. If that fails
          it will retry every three hours until only six hours are left before expiration.
          At that point it will increase the frequency and retry every five minutes. If 
          this is part of the system design, at this point it should also alert the user
          that something is wrong.</t>
      </section>
      <section anchor="ca-avail" title="Availability of the Certificate Authority">
        <t> While the STAR design does not require 99.999% availability, the CA does need
          to be available for renewing certificates. Downtimes of more than a quarter of
          the certificate longevity SHOULD NOT happen. For most modern hardware this is 
          entirely possible even without exotic clustering solutions, but when configuring
          the system administrators should consider that the longevity of the certificates
          constrains the required availability of the CA.</t>
        <t> When setting the longevity for certificates administrators SHOULD consider how
          long it takes to recover from a failure of the CA. That length of time can be 
          seconds with a good clustering solution, but can span hours or days without one,
          especially if the fault happens at a bad time. A failure of a CA should be 
          considered a conceivable occurrence, and longevity should be set so that such a 
          failure does not lead to expiration and outage.</t>
        <t> Conversely, if short longevity is required by security targets, the CA should 
          be made more reliable with clustering solutions.</t>
      </section>
      <section anchor="clock" title="Clock Skew and the notBefore Field">
        <t> Despite NTP (<xref target="RFC5905"/>) being over thirty years old and 
          implemented in every major operating system clock skew is a fact of life and
          many deployed systems don't have the right time. It is also not possible to just
          mandate the use of NTP because the systems that use STAR certificates are often
          installed on hosts and networks where NTP is either not configured or blocked. 
          We cannot assume that these systems can enable NTP at will.</t>
        <t> Skewed clocks have always been a problem for certificates. Because STAR 
          certificates are always just a few days or hours from expiration they are more 
          sensitive to clock skew. A sufficiently skewed clock can cause three different 
          disfunctions and for STAR certificate such disfunction happens with considerably
          less skew than with long term certificates:
          <list style="symbols">
            <t> A valid certificate may be rejected as not yet valid if the current system
              time is earlier than its notBefore time. Fortunately this issue can be 
              safely mitigated by setting the notBefore field to a time earlier than the
              time of issuance.</t>
            <t> A valid certificate may be rejected as expired if the current system time
              is later than its notAfter time. As long as the clock skew is not too great
              this is solved by a sensible renewal policy. If as in the example in <xref
              target="schedule"/> the certificate is renewed 4 days before expiration or 
              within a few hours after that, a clock skew of up to 3 days will not be a 
              problem.</t>
            <t> An expired certificate may be accepted if the current system time is 
              earlier than its notAfter time. This is a security issue that is discussed 
              in <xref target="sec-skew"/>.</t>
          </list></t>
          <t> There are several common modes of clock skew: <list style="symbols">
            <t> The system that doesn't have its clock set at all. These systems might be
              set to January 1st, 1970 or to some date that was interesting for the 
              hardware vendor. Such systems are incompatible with certificates and MUST 
              NOT be used for STAR certificates.</t>
            <t> The system has its timezone set wrong, and the system time was set so that
              local time looks good. This limits the clock skew to 24 hours and is 
              generally workable.</t>
            <t> A system that has the time set right but the date set wrong. These are 
              also not usable with certificates.</t>
            <t> A system that was set to the correct time once but has since drifted away.
              Computer hardware varies wildly between systems with quartz clocks that 
              drift only a few seconds a month and systems that can lose or gain minutes a
              day. The former are quite usable, the latter are not.</t>
          </list></t>
          <t> Because of the prevalence of systems with a relatively small skew it is 
            RECOMMENDED to set the notBefore field to a time 72 hours before the actual
            issuance date.</t>
          <t> End Entities MUST NOT use expired certificates and Relying Parties SHOULD 
            alert whenever an expired certificate is presented. This will help the users
            keep their host clocks set or encourage them to enable NTP.</t>
      </section>
      <section anchor="auto" title="Automatic Renewal">
        <t> Automatic enrollment and renewal is recommended for any system using 
          certificates. While it is possible to renew certificates manually on time, even
          organizations with the best of IT departments occasionally miss this: 
          <xref target="cert-expires"/></t>
        <t> With short term certificates, this becomes even more important. Renewing a 
          certificate manually every few days or hours is extremely labor intensive, 
          especially when the system contains hundreds, thousands or more end entities, 
          and the risk of outages becomes a certainty.</t>
        <t> This document does not mandate any particular enrollment or renewal mechanism.
          Any of a myriad of standard and proprietary methods can be used and systems with
          proprietary methods have been shipping for years. The IETF is in the process of
          standardizing the ACME protocol for enrollment and renewal (<xref 
          target="I-D.ietf-acme-acme"/>) and an extension is proposed to make it more 
          suitable for STAR certificates (<xref target="I-D.ietf-acme-star"/>). The ANI as 
          described in <xref target="ANI"/> is a complete zero touch system design 
          providing and relying on automatic certificate renewal.</t>
      </section>
      <section anchor="re-enrollments" title="Secure (Re-)Enrollments">
         <t>When short lived certificates expire, automatic re-enrollment can further help
	   to provide survivable, resilient PKI security. Traditionally, initial enrollments,
	   even with otherwise automated solutions such as EST (<xref target="RFC7030"/>) required
	   a manual interaction, or else the device had to perform TOFU (Trust On First Use)
	   to be automatically enrolled. TOFU is even more problematic for re-enrollments
	   and becomes more problematic, the shorter lived certificates and/or trust
	   anchors are. Consider the risk where during re-enrollment, the device may already be
	   fully configured and could be taken over by an attacker just having to wait for a short
	   lived certificate device certificate or trust anchor to expire.  Or consider devices
	   auto-resetting themselves to factory conditions to avoid this problem and then not having
	   to be re-enrolled, but also be re-configured - in the absence of fully zero-touch 
	   provisioning solutions.</t>
	   
	   <t>ANIs BRSKI protocol (<xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>, which
	   introduces extensions to EST), and NetConf Zero Touch
	   (<xref target="I-D.ietf-netconf-zerotouch"/> allow fully automated enrollment and
	   re-enrollment of device certificate and trust anchors through the use of "vouchers"
	   (<xref target="I-D.ietf-anima-voucher"/>). These are new digital artifacts that
	   allow enrolling devices to securely trust domains to (re-)enroll them. They work
	   by providing a signed statement by a representative of the manufacturer of the
	   device, that the device with a specified identity (e.g: IDevID) should trust a
	   particular domain - identified by an initial trust anchor. This allows to overcome
	   the biggest challenge of expired short lived certificates/trust-anchors.</t>

	   <t>Furthermore, if the certificate and/or trust anchors are required for security
	   of network connectivity - such as routing protocol security or network layer encryption -
	   to even reach a re-enrollment server, then there is yet another challenge with
	   short lived certificates/trust-anchors and their higher likelyhood of expiring.</t>

	   <t>In the case of ANI, network layer security (e.g.: IPsec) is used for protecting
	   network connectivity including to reach the EST renewal server. When certificate/TA
	   are expired, renewal can not be used. Instead though, automatic re-enrollment
	   can be used, which does not rely on generic network layer security, but instead
	   relies on its own proxy service to provide connectivity for such devices that need
	   to re-enroll. Nevertheless, re-enrollment may be a complex operation due to the
	   potential need to involve the above mentioned representative entity of the manufacturer
	   to generate vouchers.</t>
      </section>

      <section anchor="future" title="Future enhancements for renewal/re-enrollment">
         <t>One easy improvement that is specifically of interest with the use of short-lived
	   device certificates/trust-anchors is a new interpretation of the lifetime of certificates. 
	   Today, there is no clear distinction when or how to apply the lifetime, and in result,
	   it is usually assumed to be applicable to all operations relying on those certificates.</t>

	 <t>In the case of short-lived certificates, the elements performing certificate
	   renewal/re-enrollment can easily have a different interpretation of the lifetime
	   and may not rely on what the certificate itself says. This allows to turn
	   re-enrollments into renewals and avoid possible complexities or manual steps potentially
	   required for re-enrollment (depending on the system used).</t>
	 
	 <t>In the case of BRSKI/EST, there is only one TLS connection used for renewal
	   and/or re-enrollment and expiry affects the certificates used on this TLS connection.
	   The server uses EST for renewal or the extended signaling of BRSKI for re-enrollment.
	   When a device with expired, short-lived certificate connects to the BRSKI/EST server,
	   this server could allow to perform only simple EST renewal instead of re-enrollment
	   with a voucher by simply considering the lifetime of the presented (and expired)
	   device certificate to be extended.</t>

	 <t>This type of re-interpretation requires primarily some generic work to allow this
	   type of interpretation - and then per-solution work to leverage this interpretation. 
	   In the case of BRSKI/EST for example, devices would simply use their expired domain
	   certificate to authenticate themselves and perform certificate renewal - instead
	   of using their IDevID and trying to re-enroll (which is a more complex operation
	   with potentially external dependenices against the manufacturer component).</t>

      </section>
      <section anchor="ct" title="Certificate Transparency">
        <t> Certificate Transparency (CT), <xref target="RFC6962"/> is about keeping a log of
          all issued certificates.</t>
        <t> A system that issues a certificate every few days to thousands or end entities
          will create more records for a CT log than a web host that gets one certificate
          every year.</t>
        <t> TBA: Discussion about this.</t>
      </section>
    </section>
    <section anchor="security" title="Security Considerations">
      <t> STAR certificates eliminate an important security feature of PKI which is the 
        ability to revoke certificates. Revocation allows the administrator to limit the
        damage done by a rogue node or an adversary who has control of the private key.
        With STAR certificates expiration replaces revocation so there is a timeliness 
        issue.</t> 
      <t>It should be noted that revocation also has timeliness issues, because both CRLs
        and OCSP responses have nextUpdate fields that tell RPs how long they should trust
        this revocation data. These fields are typically set to hours, days, or even weeks 
        in the future. Any revocation that happens before the time in nextUpdate goes 
        unnoticed by the RP.</t>
      <t> <xref target="sec-revoc"/> discusses the reasons why a certificate would be 
        revoked if revocation was available and how STAR certificates do the same. 
        <xref target="sec-longevity"/> discusses considerations for setting the longevity
        of a certificate, and <xref target="sec-skew"/> discusses how longevity should be
        adjusted to deal with clock skew.</t>
      <t> More discussion of the security of STAR certificates is available in <xref 
        target="Topalovic"/>.</t>
      <section anchor="sec-revoc" title="Reasons for Revocation">
        <t> There are two types of compromise that require administrators to revoke a 
          certificate:<list style="symbols"> 
          <t> A host has lost control of the private key. There are many ways that this
            can happen: a host can be hacked and a file containing the private key may or 
            may not have been copied; a disk may be replaced and the old one has not been
            securely disposed of; a fault causes the private key to be erased. In all 
            these cases we would like to revoke the certificate to make sure an adversary 
            cannot use the private key for nefarious purposes. For STAR certificates the
            only solution is to wait for the certificate to expire and the system is 
            vulnerable until that happens. Longevity should be set so that this risk is
            acceptable.</t>
          <t> A host may begin doing unintended things, either due to a software fault or
            due to a malicious takeover. Again without revocation RPs will continue to 
            trust this node until its certificate expires.</t>
        </list></t>
        <t> When a node "goes rogue" or an adversary gets control of the private key it is 
          important to block renewal or these certificates or else the attack can persist
          forever. No matter how short-term these short term certificates are, there is a 
          certain window of time when the attacker can use the certificate. This can often 
          be mitigated with application-level measures.</t>
        <t> With most systems relying parties are configured with the names of nodes with
          which they are allowed to communicate. When revocation is not available changing
          the configuration so that the rogue node cannot connect is RECOMMENDED. This is 
          useful even when revocation is available because timeliness issues are common to 
          both revocation and expiration.</t>
      </section>
      <section anchor="sec-longevity" title="Longevity and Revocation">
        <t> There is always a period of time between when a compromise is discovered and
          when RPs stop trusting the certificate. With revocation this has to do with the 
          time it takes to process the revocation and the span of time between the 
          thisUpdate and nextUpdate fields.  With STAR certificates this is controlled by 
          the time it takes to inhibit renewals and the longevity of the certificates.</t>
        <t> For this reason it makes sense to set the longevity to a period of time 
          similar to the span of time that we would set for the CRL or OCSP updates. 
          Typically a few days is an appropriate time. For some cases this can be as low
          as a few hours. Setting the renewal time too short may cause operational 
          problems as discussed in <xref target="clock"/> and <xref target="ca-avail"/>. 
          In general longevity should not be set shorter than the availability of the CA 
          allows.</t>
        <t> Fortunately modern hardware is powerful enough and reliable enough that even a
          system with tens of thousands of end entities with longevity of 1-2 days should 
          not suffer an outage because of expired certificates.</t> 
      </section>
      <section anchor="sec-skew" title="Clock Skew and Security">
        <t> As discussed in <xref target="clock"/> clock skew can lead to expired 
          certificates being treated as valid. While even the use of NTP may leave clocks
          with a few seconds of inaccuracy, all installations MUST take steps to limit 
          the clock skew on their hosts.</t>
        <t> An upper bound for the amount of skew allowed for hosts in a particular system
          is one of the parameters for such a system. For systems using NTP this can be 2 
          seconds. For systems where the clocks are set manually, this tends to be far 
          greater, but without an upper bound no guarantees can be made about the security
          of certificate use.</t>
        <t> This upper bound is also a limit on the target certificate longevity. For 
          example, if hosts and CAs can each have a clock skew of 24 hours then it is
          impossible to achieve a longevity of under 48 hours. With a reasonable skew and
          a reasonable target longevity we can achieve our security targets by reducing 
          the certificate longevity by twice the upper bound for skew. So if skew is 
          bounded by 24 hours (the bad timezone case) and target longevity is 7 days, it
          makes sense to set the longevity on the CA to 5 days.</t>
      </section>
      <section anchor="casec" title="CA availability">
        <t> A successful Denial of Service (DoS) attack against a CA prevents it from 
          issuing certificates. With short-term certificates this could quickly lead to 
          outages as certificates expire.</t>
        <t> The important period of time here is the time between when the EE first 
          attempts to renew the certificate and the time that the certificate expires. For 
          example, if the EE attempts to renew the certificates a mere five minutes before
          expiration, then a five-minute CA outage can lead to an invalid certificate and
          failed connections.</t>
        <t> This issue is no different from DoS attacks against the DP for certificates 
          with revocation. The methods of protection are also similar:<list style="symbols">
          <t> Certificate renewal should first be attempted plenty of time in advance as 
            recommended in <xref target="schedule"/>. This will leave enough time for 
            administrators to deal with the attack.</t>
          <t> As for all important infrastructure, network defenses SHOULD be deployed to
            mitigate DoS attacks.</t></list></t>
      </section>
    </section>
    <section anchor="iana" title="IANA Considerations">
      <t> There are no requests to IANA in this document.</t>
    </section>  


  </middle>
  <!-- ====================================================================== -->
  <back>
    <references title="Normative References"> 
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5280"?>
    </references>
    <references title="Informative References"> 
<?rfc include="reference.RFC.4806"?>
<?rfc include="reference.RFC.5246"?>
<?rfc include="reference.RFC.5905"?>
<?rfc include="reference.RFC.6066"?>
<?rfc include="reference.RFC.6960"?>
<?rfc include="reference.RFC.6961"?>
<?rfc include="reference.RFC.6962"?>
<?rfc include="reference.RFC.7030"?>
<?rfc include="reference.RFC.7296"?>
<?rfc include="reference.RFC.8192"?>
      <reference anchor="I-D.ietf-acme-acme">
        <front>
          <title>Automatic Certificate Management Environment (ACME)</title>
          <author initials='R' surname='Barnes' fullname='Richard Barnes'>
            <organization />
          </author>
          <author initials='J' surname='Hoffman-Andrews' fullname='Jacob Hoffman-Andrews'>
            <organization />
          </author>
          <author initials='J' surname='Kasten' fullname='James Kasten'>
            <organization />
          </author>
          <date month='June' day='21' year='2017' />
        </front>
        <seriesInfo name='Internet-Draft' value='draft-ietf-acme-acme-07' />
        <format type='TXT'
          target='http://www.ietf.org/internet-drafts/draft-ietf-acme-acme-06.txt' />
      </reference>
      <reference anchor="I-D.ietf-acme-star">
        <front>
          <title>Use of Short-Term, Automatically-Renewed (STAR) Certificates to Delegate
                        Authority over Web Sites</title>
          <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
            <organization/>
          </author>
          <author initials="D." surname="Lopez" fullname="Diego Lopez">
            <organization/>
          </author>
          <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez de Dios">
            <organization/>
          </author>
          <author initials="A." surname="Pastor Perales" fullname="Antonio Agustin Pastor Perales">
            <organization/>
          </author>
          <author initials="T." surname="Fossati" fullname="Thomas Fossati">
            <organization/>
          </author>
          <date month='June' day='16' year='2017' />
        </front>
        <seriesInfo name='Internet-Draft' value='draft-ietf-acme-acme-07' />
        <format type='TXT'
          target='http://www.ietf.org/internet-drafts/draft-ietf-acme-acme-06.txt' />
      </reference>
      <reference anchor="cert-expires" target="http://www.securityweek.com/google-lets-smtp-certificate-expire">
        <front>
          <title>Google Lets SMTP Certificate Expire</title>
          <author initials="M." surname="Lennon" fullname="Mike Lennon">
            <organization>Security Week</organization>
          </author>
          <date month="April" day="4" year="2015" />
        </front>
      </reference>
      <reference anchor="Topalovic" target="http://www.w2spconf.com/2012/papers/w2sp12-final9.pdf">
        <front>
          <title>Towards Short-Lived Certificates</title>
          <author initials="E." surname="Topalovic" fullname="Emin Topalovic">
            <organization>Stanford University</organization>
          </author>
          <author initials="B." surname="Saeta" fullname="Brennan Saeta">
            <organization>Stanford University</organization>
          </author>
          <author initials="L." surname="Huang" fullname="Lin-Shung Huang">
            <organization>Carnegie Mellon University</organization>
          </author>
          <author initials="C." surname="Jackson" fullname="Colling Jackson">
            <organization>Carnegie Mellon University</organization>
          </author>
          <author initials="D." surname="Boneh" fullname="Dan Boneh">
            <organization>Stanford University</organization>
          </author>
          <date year="2012"/>
        </front>
      </reference>
      <?rfc include="reference.I-D.ietf-anima-reference-model"?>
      <?rfc include="reference.I-D.ietf-anima-bootstrapping-keyinfra"?>
      <?rfc include="reference.I-D.ietf-anima-autonomic-control-plane"?>
      <?rfc include="reference.I-D.ietf-anima-voucher"?>
      <?rfc include="reference.I-D.ietf-netconf-zerotouch"?>
      <?rfc include="reference.I-D.ietf-anima-stable-connectivity"?>
    </references>
    
    <!-- ====================================================================== -->
  </back>
</rfc>
