Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)
draft-ietf-acme-star-11

[Ballot comment]
Thank you for addressing my Discuss point!

I will note that https://example.com/acme/cert/mAt3xBGaobw is used
here as a star-certificate URL but was used in RFC 8555 as a certificate
URL; it's probably worth putting a different random string in this document.

[Ballot comment]
Thank you for the work put into this document. While I am balloting "no objection", I support Alexey's DISCUSS.

I am also wondering what is the impact of the increased rate of request to the ACME server. While sections 4 and 5 answered most of the questions popping up in my mind when reading the document; I am still concerned that going from a 90 days to a 3 days validity is probably multiplying the load by 30 on ACME server, are the free existing ACME server ready to continue their free services?

Regards,

-éric

[Ballot discuss]
RFC 8555 (and the IANA registry) list the 'status' field of the order object
as not configurable, yet we propose to configure it (in Sections 3.1.1
and 3.1.2).  It would perhaps be possible to make this work
procedurally, by updating the registry entry and maybe an Updates:
header, but it may be worth a broader rethink.  Specifically, if we add
a new field to the order instead, for the cancellation URL, then we do
not modify the order directly (but instead request the server to take an
action that does so as a side effect), and we also can avoid
state-machine concerns about attempting to enter "canceled" state from a
state other than "valid" by simply not making the cancellation URL
visible until the order is "valid".

A more minor concern, but when we consider the examples in this document
in conjunction with the examples in RFC 8555 itself, we find several
protocol invariants violated: we reuse a nonce for different requests,
but nonces are single-use; we use the same Order URL for two different
order contents, the same certificate URL for two different
(star-)certificates, and (not quite a protocol invariant, but "with very
high probability" so) the signature on a request is duplicated.  I also
note that we reuse an account URL from RFC 8555, which is not inherently
problematic, but my suggestion would be to generate a new one to make a
clean break.

[Ballot comment]
I support Alexey's Discuss point.

Section 3.1.1

  Section 7.1.6 of [RFC8555] defines the following values for the Order
  resource's status: "pending", "ready", "processing", "valid", and
  "invalid".  In the case of auto-renewal Orders, the status MUST be
  "valid" as long as STAR certificates are being issued.  We add a new
  status value: "canceled", see Section 3.1.2.

It might be nice to include an updated Order state diagram that
includes the new state.

  A STAR certificate is by definition a mutable resource.  Instead of

nit: I suggest s/mutable/dynamic/ -- it changes, but not because of
external requests for modification.

  overloading the semantics of the "certificate" attribute, this
  document defines a new attribute "star-certificate" to be used
  instead of "certificate".

  o  star-certificate (optional, string): A URL for the (rolling) STAR
      certificate that has been issued in response to this Order.

Presumably this means that there will never be a "certificate" Order
field for a STAR certificate?

Section 3.1.2

  Immediately after the Order is canceled, the server:

  o  MUST update the status of the Order resource to "canceled" and
      MUST set an appropriate "expires" date;

This seems like something that's done conceptually "during the
cancellation of the order" (vs. "immediately after").  RFC 8555 doesn't
seem to use this rhetorical style; perhaps we can follow it and use
something like "the status of a cancelled Order resources is
'cancelled'" instead.

  o  MUST respond with 403 (Forbidden) to any requests to the star-
      certificate endpoint.  The response SHOULD provide additional
      information using a problem document [RFC7807] with type
      "urn:ietf:params:acme:error:autoRenewalCanceled".

This one could then be a declarative "the server MUST respond to any
requests to the star-certificate endpoint for a cancelled order with 403
(Forbidden)".

  Issuing a cancellation for an Order that is not in "valid" state is
  not allowed.  A client MUST NOT send such a request, and a server
  MUST return an error response with status code 400 (Bad Request) and
  type "urn:ietf:params:acme:error:autoRenewalCancellationInvalid".

(As mentioned in the Discuss section) If we add a new Order object field
for a dedicated "cancel" URL, then we can get this property for free but
not having that field be present in the Order object until the Order is
in the "valid" state.

  Explicit certificate revocation using the revokeCert interface
  (Section 7.6 of [RFC8555]) is not supported for STAR certificates.  A
  server receiving a revocation request for a STAR certificate MUST
  return an error response with status code 403 (Forbidden) and type
  "urn:ietf:params:acme:error:autoRenewalRevocationNotSupported".

This seems very close to violating a "MUST" from 8555, wherein the
server "MUST consider [the account that issued the certificate]
authorized [to revoke] a certificate" and "server MUST also consider a
revocation request valid if it is signed with the private key
corresponding to the public key in the certificate."  The only rope we
seem to have is that "[i]f the revocation fails, the server returns an
error".  But there's not much discussion of why a revocation might fail,
just an example of "alreadyRevoked".

Section 3.2

I suggest adding some discussion of the relationship between
"max-duration" and the lifetime of a traditionally issued ACME
certificate, in terms of the analogues for proving possession of the
certificate private key, policy, etc..  I could see such discussion
either here or in the security considerations (or both)

  In order to support the discovery of STAR capabilities, the "meta"
  field inside the directory object defined in Section 9.7.6 of
  [RFC8555] is extended with a new "auto-renewal" object.  The "auto-

nit: pedantically, it's extended with a new "auto-renewal" field, whose
type is object (as specified below).

side note: the max-duration in Figure 4 does not allow for leap seconds
or leap years, but that seems unlikely to cause any problems for anyone.

Section 3.3

I would consider using timestamps for the Cert-Not-* headers that are
closer to the present; they will "always" be out of date for future
readers, but might make contextually make more sense to match the time
of publication.

The "further clarifications regarding usage" is the only place we
mention using HEAD for the star-certificate resource; it probably merits
a mention that when GET is allowed, HEAD is also allowed, but HEAD
otherwise remains disallowed.

RFC 7231's list of considerations includes "Whether it is appropriate to
list the field-name in the Connection header field (i.e., if the header
field is to be hop-by-hop; see Section 6.1 of [RFC7230])"; do we not
need to supply information on this topic?

                                                                      It
  is worth noting that this has an implication in case of cancellation:
  in fact, from the time the next certificate is made available, the
  cancellation is not completely effective until the latter also
  expires.  [...]

nit: I suggest avoiding "the latter" since we only implicitly talk about
the former (original certificate).

  To improve robustness, the next certificate MUST be made available by
  the ACME CA at the URL pointed by "star-certificate" at the latest
  halfway through the lifetime of the currently active certificate.  It
  is worth noting that this has an implication in case of cancellation:
  in fact, from the time the next certificate is made available, the
  cancellation is not completely effective until the latter also
  expires.  To avoid the client accidentally entering a broken state,
  the notBefore of the "next" certificate MUST be set so that the
  certificate is already valid when it is published at the "star-
  certificate" URL.  Note that the server might need to increase the
  auto-renewal lifetime-adjust value to satisfy the latter requirement.

I don't think this text paints a very clear picture of what is expected
to happen, since we now effectively have two different meanings for
"lifetime".  I believe that the intent is to have a schedule for
renewals, that occur at periodic intervals corresponding to the
'lifetime' field in the Order resource, but to have each certificate
available earlier than that (but with the scheduled notAfter) to allow
for deployment.  The notBefore would then not reflect the scheduled
interval, but instead the actual time of issuance/publication, but the
gap between successive notAfters would reflect the nominal lifetime:

                        Time
--------------------------------------------------------------->

regular issue cadence, offset by lifetime from Order
|      |      |      |      |      |      |      |      |
v      v      v      v      v      v      v      v      v
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| SN=1  | SN=2  | SN=3  | SN=4  | SN=5  | SN=6  | SN=7  | SN=8  |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    ^                              ^
    SN=2 made available            SN=6 made available

So in practice we have the lifetime from the Order as the nominal
lifetime, but the (notAfter - notBefore) time for any given cert after
the first will be (roughly) 1.5 times that lifetime.  I think this
paragraph needs to be rewritten and acknowledge that there are two
conceptual lifetimes in order to be able to clearly convey the intent.
Section 3.5 has a fair treatment already, so maybe we could get away
with removing most of this content and forward-referencing to Section
3.5.

  The server MUST NOT issue any additional certificates for this Order
  beyond its auto-renewal end-date.

nit: what is "additional"?  Why not just say "the server MUST NOT issue
any certificates for this order with notAfter after the auto-renewal end
time"?

  Immediately after the Order expires, the server MUST respond with 403
  (Forbidden) to any requests to the star-certificate endpoint.  The

nit: same style comment as above, re. "for expired Orders, the server
MUST respond with [...]"

Section 3.4

  In order to enable the name delegation workflow defined in
  [I-D.ietf-acme-star-delegation] as well as to increase the
  reliability of the STAR ecosystem (see Section 4.3 for details), this
  document defines a mechanism that allows a server to advertise
  support for accessing star-certificate resources via unauthenticated
  GET (instead of, or in addition to, POST-as-GET), and a client to
  enable this service with per-Order granularity.

How is "instead of" vs. "in addition to" negotiated?  I think it's just
"in addition to" (but the client doesn't have to keep using
POST-as-GET).

  o  allow-certificate-get (optional, boolean): If this field is
      present and set to true, the server allows GET requests to star-
      certificate URLs.

There's a scope-mismatch between the "allow-certificate-get" at the
top-level of the directory metadata and "allows GET requests *to
star-certificate URLs*".  If it only applies to star-certificate URLs,
than anything else in the future that wants to use GET for certificates
will need to also define directory metadata, but you're squatting on the
good name for the STAR-specific bits.

  A client states its will to access the issued star-certificate via
  unauthenticated GET by adding an allow-certificate-get attribute to
  the auto-renewal object of its Order and setting it to true.

nit: I think the client doesn't directly modify the Order, but instead
adds this to the payload of its newOrder request.
nit: I think s/will/desire/ or s/will/intent/ would be a more
conventional usage.

Section 3.5

  We define "nominal renewal date" the point in time when a new short-
  term certificate for a given STAR Order is due.  It is a multiple of
  the Order's auto-renewal lifetime that starts with the issuance of

nit: pedantically, the nominal renewal date is an absolute time but a
"multiple of the auto-renewal lifetime" is a time interval; the types
don't match.

      notAfter  = min(nrd[i] + T, end)
      notBefore = nrd[i] - max(adjust_client, adjust_server)

  Where "adjust_client" is the min between the auto-renewal lifetime-
  adjust value ("la"), optionally supplied by the client, and the auto-
  renewal lifetime of each short-term certificate ("T");

These formulas seem to require the server to respect a client's
lifetime-adjust (provided it is between 0.5*T and T), even when the
server's preference would be to use a smaller value (though still at
least 0.5*T).  That's unusual, in that we usually give the server leeway
to apply policy and reject or modify requests from the client before
fulfilling them.  Is that exception intended here?

Section 4.1

  facing certificates.  The exact number depends on the percentage of
  the "clock-skewed" population that the site owner expects to protect
  - 5 days cover 97.3%, 7 days cover 99.6% as well as the nominal auto-
  renewal lifetime of the STAR Order.  Note that exact choice is also

nit: I think there's a missing em dash to close the parenthetical remark
(presumably after "99.6%").  Also, RFC style uses two hyphens for an em
dash.

  likely to depend on the kind of clients that is prevalent for a given
  site or app - for example, Android and Mac OS clients are known to

nit: I think there's a singular/plural mismatch going on here, in that
if we want a plural we do "kinds of client" (and "are"), but "clients"
plural doesn't make sense.  (Also, two hyphens for em dash, as above.)

Section 4.3

I'm not entirely sure I see the connection between dependability and
caching at the HTTP layer -- in the simple model where there's a single
endpoint that needs to fetch the certificate, the certificate is only
served once and caching does not help.  Is the idea that the cache will
proactively populate itself, or that there will be many endpoints
fetching the same certificate (as in a CDN)?

  When using unauthenticated GET to fetch the STAR certificate, the
  server SHALL use the appropriate cache directives to set the
  freshness lifetime of the response (Section 5.2 of [RFC7234]) such
  that on-path caches will consider it stale before or at the time its
  effective lifetime is due to expire.

Is it better to have the HTTP cache expire when the certificate does, or
when we expect the next certificate to be available?

Section 7

I think we should have some discussion of the (cryptographic) role
played by the CSR in a traditional certificate issuance process (e.g.,
proving possession of the private key corresponding to the certified
public key) and the value of periodically running that process, and how
that relates to the STAR workflow.  Specifically, that the validity
period of the STAR order (i.e., difference between end-date and
start-date) should roughly align with the lifetime of a
traditional-model certificate issuance, in order to retain similar
properties.

Section 7.1

  adversary who has control of the private key.  With STAR
  certificates, expiration replaces revocation so there is a timeliness
  issue.  To that end, see also the discussion on clock skew in
  Section 4.1.

I don't think I understand the intent of saying there is "a timeliness
issue" (but maybe it's just me).

Section 7.2

  auto-renewal "lifetime".  Alternatively, the CA can set an internal
  certificate generation processes rate limit.

Wouldn't this run the risk of failing to meet the CA's guarantees on
producing renewed certificates?

[Ballot comment]
Thanks for the work that everyone put into this document! I have
a small number of very minor editorial nits.

[Sorry for the earlier DISCUSS; I had mixed up the cert issuance
model in my head again].

§3.3:

>  The Server SHOULD include the "Cert-Not-Before" and "Cert-Not-After"
>  HTTP headers in the response.

Nit: "...HTTP header fields..."

>  Following are further clarifications regarding usage of these
>  headers, as per [RFC7231] Sec. 8.3.1.  All apply to both headers.

Nit: "...header fields..."

>
>  o  This header is a single value, not a list.

Nit: "...header field..."

>  o  The header is used only in responses to GET, HEAD and POST-as-GET

Nit: "...header field..."

>    requests, and only for MIME types that denote public key
>    certificates.
>  o  Header semantics are independent of context.

Nit: "Header field..."

>  o  The header is not hop-by-hop.

Nit: "...header field..."

>  o  Intermediaries MAY insert or delete the value, but MUST ensure
>    that if present, the header value equals the corresponding value

Nit: "...header field..."

>    within the credential.
>  o  The header is not appropriate for a Vary field.

Nit: "...header field..."

>  o  The header is allowed within message trailers.

Nit: "...header field..."

>  o  The header is not appropriate within redirects.

Nit: "...header field..."

>  o  The header does not introduce additional security considerations.

Nit: "...header field..."

>    It discloses in a simpler form information that is already
>    available inside the credential.

---------------------------------------------------------------------------

§3.3:

>  o  Intermediaries MAY insert or delete the value, but MUST ensure
>    that if present, the header value equals the corresponding value
>    within the credential.

This probably isn't what you want to say. Read literally, this imposes
a requirements on intermediaries who are neither removing nor adding
these header fields to validate that they match the value in the certs.
That's clearly an unrealistic expectation. I suspect the intention here
is that any entity who inserts a value must ensure that the newly inserted
value matches the corresponding value in the certificate.

[Ballot discuss]
Thanks for the work that everyone put into this document! I have
one item that needs discussion, and then a small number of very
minor editorial nits. I plan to ballot YES once the issue I identify
below has been addressed.

7.3:

>  In order to avoid correlation of certificates by account, if
>  unauthenticated GET is negotiated (Section 3.4) the recommendation in
>  Section 10.5 of [RFC8555] regarding the choice of URL structure
>  applies, i.e. servers SHOULD choose URLs of certificate resources in
>  a non-guessable way, for example using capability URLs
>  [W3C.WD-capability-urls-20140218].

Thanks for reinforcing the privacy point from 8555 here; however, I think
the situation here is substantially more sensitive. With base 8555 behavior, the
existence of a URL (as can be deduced by distinguishing between 401 and 404
responses) poses a privacy risk, if parties can deduce a pattern to the URL
paths, allowing correlation of users' domains.

With unauthenticated GET, the ability to guess the associated URL would
be incredibly dire, allowing arbitrary unauthorized parties to download
the cert in question. While this may be somewhat obvious to the authors
and working groups, it's the kind of thing that really needs to be
spelled out in the security section, to avoid any oversight on the part
of implementors.

For a similar reason, I'm pretty sure that "SHOULD" is not the right
level of requirement for unguessability. An ACME STAR service with
guessable URLs may as well not perform validation at all, since it's
effectively handing out everyone's cert to everyone on the Internet.

Unguessability for unauthenticated GET needs to be a MUST, and the
document should explain why this is a hard requirement.

[Ballot comment]
§3.3:

>  The Server SHOULD include the "Cert-Not-Before" and "Cert-Not-After"
>  HTTP headers in the response.

Nit: "...HTTP header fields..."

>  Following are further clarifications regarding usage of these
>  headers, as per [RFC7231] Sec. 8.3.1.  All apply to both headers.

Nit: "...header fields..."

>
>  o  This header is a single value, not a list.

Nit: "...header field..."

>  o  The header is used only in responses to GET, HEAD and POST-as-GET

Nit: "...header field..."

>    requests, and only for MIME types that denote public key
>    certificates.
>  o  Header semantics are independent of context.

Nit: "Header field..."

>  o  The header is not hop-by-hop.

Nit: "...header field..."

>  o  Intermediaries MAY insert or delete the value, but MUST ensure
>    that if present, the header value equals the corresponding value

Nit: "...header field..."

>    within the credential.
>  o  The header is not appropriate for a Vary field.

Nit: "...header field..."

>  o  The header is allowed within message trailers.

Nit: "...header field..."

>  o  The header is not appropriate within redirects.

Nit: "...header field..."

>  o  The header does not introduce additional security considerations.

Nit: "...header field..."

>    It discloses in a simpler form information that is already
>    available inside the credential.

---------------------------------------------------------------------------

§3.3:

>  o  Intermediaries MAY insert or delete the value, but MUST ensure
>    that if present, the header value equals the corresponding value
>    within the credential.

This probably isn't what you want to say. Read literally, this imposes
a requirements on intermediaries who are neither removing nor adding
these header fields to validate that they match the value in the certs.
That's clearly an unrealistic expectation. I suspect the intention here
is that any entity who inserts a value must ensure that the newly inserted
value matches the corresponding value in the certificate.

[Ballot comment]
This is a fascinating approach / solution - thanks for writing this document, it's nice and clear.

Please review and address the comments in https://datatracker.ietf.org/doc/review-ietf-acme-star-06-opsdir-lc-ersue-2019-07-21/ -- they are useful (and thanks to Mehmet for the review)

[Ballot discuss]
Thank you for this well written document.

I have one small issue that I would like to discuss before recommending approval of this document:

Section 6.4 and 6.6 don’t seem to specify IANA registration procedure for new subregistries.

[Ballot comment]
1.1. Name Delegation Use Case

The proposed mechanism can be used as a building block of an efficient name-delegation protocol, for example one that exists between a CDN or a cloud provider and its customers [I-D.ietf-acme-star-delegation]. At any time, the service customer (i.e., the IdO) can terminate the delegation by simply instructing the CA to stop the automatic renewal and letting the currently active certificate expire shortly thereafter. Note that in this case the delegated entity needs to access the auto-renewed certificate without being in possession of the ACME account key that was used for initiating the STAR issuance.

Can you explain the last sentence? I am reading “in this case” as the delegated entity needs access to renewed certificate once delegation is cancelled, which doesn’t make sense. Please let me know if I misunderstood.

1. Summary
Rich Salz is the document shepherd; Roman Danyliw is the responsible AD.
The document defines an ACME extension to enable the issuance of short-term and automatically renewed (STAR) X.509 certificates. Such certificates will typically not have revocation information. The working group agrees that this should be a standards-track document.

2. Review and Consensus
The document has been in circulation for 2.5 years and a WG document for 2 years. During this time it has received a lot of review, resulting in significant changes. Although discussion has been light, the document reflects WG consensus. The document has received reviews so far from the OPSDir (nits) and GENART (ready).  The CDNI working group will be using this.

3. Intellectual Property
Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points
The question of whether short-term certificates are or are not a good idea did not come up in the discussion because that is viewed as the domain of the LAMPS working group and that working group did not adopt a document about the practice of using short-term certificates. It is also sort of a basic premise of ACME, as part of our work on automating certificate issuance.

1. Summary
Rich Salz is the document shepherd; Roman Danyliw is the responsible AD.
The document defines an ACME extension to enable the issuance of short-term and automatically renewed (STAR) X.509 certificates. Such certificates will typically not have revocation information. The working group agrees that this should be a standards-track document.

2. Review and Consensus
The document has been in circulation for 2.5 years and a WG document for 2 years. During this time it has received a lot of review, resulting in significant changes. Although discussion has been light, the document reflects WG consensus.
The document has received reviews so far from the OPSDir and IANA, both finding nits.

3. Intellectual Property
Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points
The question of whether short-term certificates are or are not a good idea did not come up in the discussion because that is viewed as the domain of the LAMPS working group. That working group did not adopt a document about the practice of using short-term certificates.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-acme-star-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the ACME Error Types registry on the Automated Certificate Management Environment (ACME) Protocol registry page located at:

https://www.iana.org/assignments/acme/

four, new registrations are to be made as follows:

Type: recurrentOrderCanceled
Description: The short-term certificate is no longer available because the recurrent order has been explicitly canceled by the IdO
Reference: [ RFC-to-be ]

Type: recurrentOrderExpired
Description: The short-term certificate is no longer available because the current order has expired
Reference: [ RFC-to-be ]

Type: recurrentCancellationInvalid
Description: A request to cancel a recurrent order that is not in state "valid" has been received
Reference: [ RFC-to-be ]

Type: recurrentRevocationNotSupported
Description: A request to revoke a recurrent order has been received
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the ACME Order Object registry also on the Automated Certificate Management Environment (ACME) Protocol registry page located at:

https://www.iana.org/assignments/acme/

seven, new registrations are to be made as follows:

Field Name: recurrent
Field Type: string
Configurable: true
Reference: [ RFC-to-be ]

Field Name: recurrent-start-date
Field Type: string
Configurable: true
Reference: [ RFC-to-be ]

Field Name: recurrent-end-date
Field Type: string
Configurable: true
Reference: [ RFC-to-be ]

Field Name: recurrent-certificate-validity
Field Type: integer
Configurable: true
Reference: [ RFC-to-be ]

Field Name: recurrent-certificate-predate
Field Type: integer
Configurable: true
Reference: [ RFC-to-be ]

Field Name: recurrent-certificate-get
Field Type: boolean
Configurable: true
Reference: [ RFC-to-be ]

Field Name: star-certificate
Field Type: string
Configurable: false
Reference: [ RFC-to-be ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the ACME Directory Metadata Fields registry on the Automated Certificate Management Environment (ACME) Protocol registry page located at:

https://www.iana.org/assignments/acme/

four, new registrations are to be made as follows:

Field Name: star-enabled
Field Type: boolean
Reference: [ RFC-to-be ]

Field Name: star-min-cert-validity
Field Type: integer
Reference: [ RFC-to-be ]

Field Name: star-max-renewal
Field Type: integer
Reference: [ RFC-to-be ]

Field Name: star-allow-certificate-get
Field Type: boolean
Reference: [ RFC-to-be ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fourth, in the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

two, new message header fields should be registered as follows:

Header Field Name: Not-Before
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

Header Field Name: Not-After
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

As this also requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-08-01):

From: The IESG
To: IETF-Announce
CC: rdd@cert.org, Rich Salz , rsalz@akamai.com, acme@ietf.org, draft-ietf-acme-star@ietf.org, acme-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Support for Short-Term, Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME)) to Proposed Standard


The IESG has received a request from the Automated Certificate Management
Environment WG (acme) to consider the following document: - 'Support for
Short-Term, Automatically-Renewed (STAR) Certificates in
  Automated Certificate Management Environment (ACME)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-08-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Public-key certificates need to be revoked when they are compromised,
  that is, when the associated private key is exposed to an
  unauthorized entity.  However the revocation process is often
  unreliable.  An alternative to revocation is issuing a sequence of
  certificates, each with a short validity period, and terminating this
  sequence upon compromise.  This memo proposes an ACME extension to
  enable the issuance of short-term and automatically renewed (STAR)
  X.509 certificates.

  [RFC Editor: please remove before publication]

  While the draft is being developed, the editor's version can be found
  at https://github.com/yaronf/I-D/tree/master/STAR.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-acme-star/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-acme-star/ballot/


No IPR declarations have been submitted directly on this I-D.

This is a being requested as an Internet Standard.  It is a profile of ACME to request a particular type of certificate, a short-lived certificate that might be used by a third party (such as a CDN) other than the origin, and with the origin's cooperation. There is growing interest in being able to securely deploy into this type of model.

The writeup in the abstract is appropriate for the Document Announcement.

The WG had very little feedback, except for one item: the document should be restructured as an ACME profile. This resulted in a major rewrite of the draft, and was an excellent decision. It brought the document into alignment with ACME, and being able to show this is as a profile is technically much better, but it also shows how ACME could be profiled for other use-cases.

STAR has been present at multiple hackathon's, and interop has been demonstrated.

The write-up was prepared by the ACME WG co-chair; ekr is the responsible AD. As a profile, this leverages the various HTTP, I18N, etc., work that has gone into ACME. There is nothing controversial or contentious in this document, and I expect it to pass the various directorate reviews without issue.

There are no known IPR issues. I have informally checked with the authors and will update this once I got all the formal replies.

The document had little WG discussion, has been presented a few times, and all feedback has been addressed. As is not unexpected, once the core document was done, the various "niche" protocol profiles and challenges receive much less interest. That does not mean that this is inappropriate for a standard, nor that the WG does not like the draft.

The only NIT is that the document refers to an ACME draft; it should refer to the RFC when published.  The references are correct.

There are no other production issues that I could find.