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