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. > 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. > 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. > 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. > 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? > 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... > 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. 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. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
