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

[Benjamin Kaduk <[e-mail]>]

On Thu, Oct 03, 2019 at 05:33:49PM +0000, Thomas Fossati wrote:
> 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.
> 
> > 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.
> 
> 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.

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.

> > 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?
> 
> Yes, there's a balance.  The intention is to allow clients that know
> their clock-skewed population some control.

Okay.

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

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

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

Sounds good; thanks for the extra explanation.

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

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

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

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

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

> Cheers, thanks.
> 
> [1] https://github.com/yaronf/I-D/commit/839eaefb6bce7e192985ddc31412a95c163ef332
> [2] https://github.com/yaronf/I-D/commit/e7f1caa016d71bd9bf758f532e7015f45f316f52
> 
> 
> 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.