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

[Thomas Fossati <[e-mail]>]

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.

> > 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.


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.