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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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?