On Tue, Oct 08, 2019 at 10:07:12AM +0000, Thomas Fossati wrote: > Hi Ben, > > On 05/10/2019, 02:07, "Benjamin Kaduk" <[email protected]> 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.
You are right -- I must have misread and missed the "auto-renewal" namespacing. Sorry about that. > > > 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. > > OK, will add. > > > > 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. > > 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... > > > > "potential for lack of timeliness in the revocation taking effect" is > > perhaps a way to word it (I did not wordsmith very much). > > 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? > > > > > > 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. > > I don't think it harms to spell it out explicitly. > > Thanks again. Thanks for the updates! -Ben _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
