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: [email protected]
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
