Subject: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-star-09: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 02 Oct 2019 11:06:21 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-star-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-star/

----------------------------------------------------------------------
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.

----------------------------------------------------------------------
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?

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 3 Oct 2019 12:59:47 +0000

Hi Ben,

First of all thank you very much for this excellent review.

On your DISCUSS points:

On 02/10/2019, 19:06, "Benjamin Kaduk via Datatracker" <[email-masked]> wrote:
> 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".

This is a great catch -- I wonder how we failed to notice it.  I don't
think tweaking the registry would be a good way to tackle this and I
agree with your proposal to remove the canceled state and add a
cancellation URL instead.  I am going to work on an update and have it
ready ASAP (though I'm on leave starting tomorrow, so it might take a
bit more than just a couple of days.)

> 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.

OK, no problems.

Cheers!

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 3 Oct 2019 07:19:11 -0700

> bit more than just a couple of days.)

So, it turns out that I was confused on this (probably a remnant of my
confusion on the related issues during the processing of RFC 8555) --
https://tools.ietf.org/html/rfc8555#section-9.7.2 is clear that the
"configurable" column refers only to "included in a newOrder request".  The
usage here is not in the newOrder request, and thus is not inherently
problematic, if my (new) understanding is correct.  But hopefully we can
get some more input, e.g., from people who better remember the discussions
around the time of draft-ietf-acme-acme's processing.

-Ben

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 3 Oct 2019 17:33:49 +0000

Hi Ben,

Upon further review, I agree with your assessment on the first part of
your DISCUSS, which is a relief.

I'm addressing your COMMENTs [1] and the second part of your DISCUSS
[2] that are for the most part straightforward.  I have a few things
I'd like to discuss further though.  See below.

> 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.

We don't want to design a generic feature here, it makes sense to scope
narrowly.  If "allow GET" proves to be important to other use cases in
the future we'll have left a clean namespace.

> fulfilling them.  Is that exception intended here?

Yes, there's a balance.  The intention is to allow clients that know
their clock-skewed population some control.

> fetching the same certificate (as in a CDN)?

Yes, one of the motivating use cases of this work was support of
delegation from content providers (name owners) to CDNs, where multiple
edge caches might need to fetch the same STAR cert.

> when we expect the next certificate to be available?

This is entirely a server choice.  The MUST here is really a baseline
which captures the only fundamental requirement that a stale cert stored
in an on-path cache does not prevent fetching a fresh one.  The server
will most likely work out its own, more refined, caching strategies.

> traditional-model certificate issuance, in order to retain similar

Not sure I follow the line of reasoning.  CSRs are one-off
proofs-of-possession and certificates are issued from CSRs with varying
validities.  I think what you are saying instead is that (end-date -
start-date) of STAR certificates should be comparable to (notAfter -
notBefore) of "traditional" certs?

> issue" (but maybe it's just me).

"timeliness issue" in the sense that with STAR you need to sit and wait
the cert to expire.  I'm not sure it's the right English word...

> producing renewed certificates?

Not if it refuses to accept new requests at the ACME interface.

Cheers, thanks.

[1] https://github.com/yaronf/I-D/commit/839eaefb6bce7e192985ddc31412a95c163ef332
[2] https://github.com/yaronf/I-D/commit/e7f1caa016d71bd9bf758f532e7015f45f316f52

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 Oct 2019 17:07:17 -0700

> the future we'll have left a clean namespace.

I'm trying to think about the risk that a future use case for
"allow-certificate-get" might want slightly different semantics for when
it's used, or need the certificate to be at a different URL, or similar.
Right now the GET option only applies to the star-certificate resource and
trying to retroactively expand its scope could be messy.

> their clock-skewed population some control.

Okay.

> edge caches might need to fetch the same STAR cert.

It might be worth mentioning that in the treatment of caching.

> will most likely work out its own, more refined, caching strategies.

Sounds good; thanks for the extra explanation.

> notBefore) of "traditional" certs?

That's what I was trying to say, yes.

> the cert to expire.  I'm not sure it's the right English word...

"potential for lack of timeliness in the revocation taking effect" is
perhaps a way to word it (I did not wordsmith very much).

> Not if it refuses to accept new requests at the ACME interface.

I'd consider noting that this limit has to take account of
already-scheduled renewal issuances as well as new incoming requests.
Maybe it's sufficiently obvious that it goes without saying, though; I
don't think I have the same context that most readers will have.

-Ben

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 8 Oct 2019 10:07:12 +0000

Hi Ben,

On 05/10/2019, 02:07, "Benjamin Kaduk" <[email-masked]> wrote:
> On Thu, Oct 03, 2019 at 05:33:49PM +0000, Thomas Fossati wrote: I'm
> trying to think about the risk that a future use case for
> "allow-certificate-get" might want slightly different semantics for
> when it's used, or need the certificate to be at a different URL, or
> similar.  Right now the GET option only applies to the
> star-certificate resource and trying to retroactively expand its scope
> could be messy.

I might be seeing this from the wrong angle, but I'm not sure I
understand what the concrete risk is: "allow-certificate-get" is
isolated in the "auto-renewal" sub-namespace.  A future, slightly
different "allow-certificate-get" can either be assigned to the
top-level namespace (if it provides general enough semantics) - and
deprecate the "auto-renewal" version - or carve its own special name
and exist in parallel.

> > delegation from content providers (name owners) to CDNs, where
> > multiple edge caches might need to fetch the same STAR cert.
>

OK, will add.

> > proofs-of-possession and certificates are issued from CSRs with
> > varying validities.  I think what you are saying instead is that
> > (end-date - start-date) of STAR certificates should be comparable to
> > (notAfter - notBefore) of "traditional" certs?
>

OK, will add.

> > "timeliness issue" in the sense that with STAR you need to sit and
> > wait the cert to expire.  I'm not sure it's the right English
> > word...
>

Thanks, that sounds very good -- at least to my Italian ear :-)

> > >    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?
> >

I don't think it harms to spell it out explicitly.

Thanks again.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Oct 2019 09:00:16 -0700

> deprecate the "auto-renewal" version - or carve its own special name

You are right -- I must have misread and missed the "auto-renewal"
namespacing.  Sorry about that.

> I don't think it harms to spell it out explicitly.

Thanks for the updates!

-Ben