[Acme] Extending (A)RI to non-ACME use cases

[Rob Stradling <[e-mail]>]

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?


--
Rob Stradling
Senior Research & Development Scientist
Email: [e-mail]