On 25/07/16 23:42, Alan Doherty wrote: > its the sort of thing i think is not a case for acme having normal > or short term certs but for acme to allow CA to provide fixed term > certs > > provider/CA X can decide themselves to profit from your > use-scenario by offering normal user acme api (certs of nominal term) > special user acme api (delivering all certs with a shorter fixed > term) > > rather than having a selector in the design of the protocol for user > custom terms [...]
Note that the current ACME draft already has "notBefore" and "notAfter" fields for this purpose. The actual certificate lifetime a CA permits is a policy decision and shouldn't be anything ACME dictates (which no one is suggesting). The question here is whether the kind of "Certificate Delegation" you'd typically see with a CDN (or similar use-case) should be part of ACME, or rather something that happens behind the scenes. I'd lean towards Option 1. Regarding the pro arguments for Option 2: 1. It's not clear whether not submitting the actual certificates to CT is feasible or even a good idea. How would logging only a delegation ticket interact with something like Expect-CT (or CT stapling in general)? Seems like this would require changes to various existing software infrastructure in order to work. I also don't expect the 3-day certificates to become the default, so this might be a bit of a premature optimization with regards to CT submission load if only a small number of high-profile targets decide to make use of it. 2. The domain owner-controlled "certificate management server" seems like it would be a more flexible option in general. This would allow organizations to add their own auditing and validation controls to the process, as opposed to a simple "here's your delegation ticket, now go talk to the ACME server." It also doesn't sound like a huge obstacle for the kind of organization that would even consider the risk of CDN delegation/revocation, IMO. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
