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

[Benjamin Kaduk <[e-mail]>]

On Tue, Oct 08, 2019 at 10:07:12AM +0000, Thomas Fossati wrote:
> Hi Ben,
> 
> On 05/10/2019, 02:07, "Benjamin Kaduk" <[e-mail]> 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