On Fri, Feb 18, 2022 at 12:51 PM Rob Stradling <[email protected]> wrote:
> draft-aaron-acme-ari-01 describes an "extension to ACME", but ISTM that > the core, OCSP-inspired protocol is not specific to ACME at all. I > appreciate that the document author's employer and this WG are only > directly concerned with the ACME use case; however, ISTM that providing > "renewal information" is something that non-ACME CAs also care about, so > I'd like to explore how we could extend this capability to also support > their use cases. > > A non-ACME CA would need an alternative mechanism for advertising ARI > support, since it won't have an ACME directory object to which a > "renewalInfo" resource can be added. Continuing the "OCSP-inspired" > theme, I propose defining a new "access descriptor" for use in the > Authority Information Access certificate extension, so that CAs can > (optionally) embed a renewalInfo URL into a well-known field in each > certificate they issue. The obvious name for this access descriptor would > be "id-ad-renewalInfo". > > The JSON response format obviously makes sense for ACME, but might not be > optimal for non-ACME use cases that wouldn't otherwise use JSON. Perhaps > the "start" and "end" timestamps could be replicated to HTTP response > headers, so that the suggested window can be read by a non-ACME client > without having to parse the JSON? > > I wonder if WG scope considerations would mean that the logical outcome of > adopting my proposal would be that the document would need to be split in > two: (1) Core "renewal info" specification, handled by LAMPS; and (2) ACME > renewalInfo resource specification, handled here in ACME. > > One last thought: Both non-ACME and ACME use cases could use the proposed > core "renewal info" protocol, meaning that the ACME renewalInfo resource > could arguably become surplus to requirements. > > Comments? > Selfishly, I would rather see such CAs using no -ACME solutions engage more with ACME to see about addressing those needs. Pragmatically, I dislike the proposed path, because the renewalInfo isn’t information relevant to a relying party, but rather, the certificate subscriber. I think it’s reasonable to ask “Is this information critical to any/all of the protocols using certificates, such as IPSec, TLS, and S/MIME?” And the answer is resoundingly, and unambiguously, no. I don’t disagree the value in perhaps having a formalized protocol, such where information normally conveyed in-band within an ACME exchange (such as via renewalInfo) can, for those CAs that predominantly use bespoke protocols or out of band exchanges, can also be communicated out of band. I just disagree with using the certificate as the appropriate means of conveying that information. It’s easy to get further into suggestions about the transport semantics (legacy headers versus JSON vs structured headers, for example), but I think before going down that route, it would be more useful to crispy define why ACME would not be an appropriate path for those CAs, why it can never be a path, and only then evaluate whether it’s worth the complexity to have ARI support those use cases. Personally, I would prefer a simpler protocol for ACME, but I admit, I may be overlooking compelling reasons that justify the added complexity of decoupling. >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
