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

[Stefan Eissing <[e-mail]>]

> Am 19.02.2022 um 00:03 schrieb Rob Stradling <[e-mail]>:
> 
> > Pragmatically, I dislike the proposed path, because the renewalInfo isn’t information relevant to a relying party, but rather, the certificate subscriber.
> 
> I agree that conveying "information relevant to a relying party" is true for some access descriptors (e.g., "id-ad-caIssuers...is intended to aid certificate users"), but AFAICT there's no text in https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.2.1 that states that the Authority Information Access extension is intended to be limited to that audience.  I think "...describes the format and location of additional information provided by the issuer of the certificate in which this extension appears" best describes the scope, and ISTM that renewalInfo falls inside that scope.
> 
> > I just disagree with using the certificate as the appropriate means of conveying that information.
> 
> I suppose that an alternative solution for publicly-trusted CAs could be to (optionally) publish renewalInfo URLs in CPSes and the CCADB, much like how CAs publish their CAA domain names today (since, like renewalInfo, the intended audience for CAA domain names is certificate subscribers).  Then non-ACME subscriber software could consume a CCADB report to discover the appropriate renewalInfo URL.
> 
> > 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,
> 
> ACME's great, but I think it's unreasonable and unrealistic to expect CAs to be able to force all of their customers to adopt ACME any time soon.
> 
> ACME doesn't have a monopoly on automation.  Some CAs were using proprietary automation solutions with their RFC2459/3280/5280 CA implementations long before ACME was conceived.  Although some of those same CAs have now implemented ACME too, it remains the case that those CAs and many of their customers are still heavily invested in the older proprietary solutions.  I don't see why these implementations shouldn't be able to benefit from ARI too.
> 
> > and only then evaluate whether it’s worth the complexity to have ARI support those use cases.
> 
> draft-aaron-acme-ari-01 seems pretty simple to me; and as I pointed out, the core protocol (section 4) already supports non-ACME use cases.  I'm not sure what "complexity" you're referring to.
> 
> > 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.
> 
> draft-aaron-acme-ari-00 described a protocol that was tied to ACME, but I'm MUCH happier with the decoupled protocol in draft-aaron-acme-ari-01.  For Sectigo, my plan is to implement our ARI server capability within our OCSP responders rather than within our CA / ACME server software.  I wouldn't be able to do that with -00, because our OCSP responders have no knowledge of ACME accounts.
> 
> I appreciate that the level of traffic from (subscriber) ARI requests will probably be significantly smaller than the level of traffic from (relying party) OCSP requests, but it's much easier for us to scale our OCSP responders than our CA / ACME servers.


I think ARI draft-01 is very lightly coupled to ACME itself. ACME just provides the discovery of an ARI endpoint (url template basically) and what information can be discovered there.

Even if the ARI resource is discovered via an ACME server, it can point to any host that is best able to handle the requests. So, in your case, that could be your OCSP infrastructure.

If you have proprietary solutions not using ACME, those could incorporate ARI URLs as well. That is not forbidden and no ACME specific auth* is involved in querying such resources. Only the format of the URL composition, e.g. how to use the cert to create the URL for it, and the content returned in JSON would have to be standard. That seems fine.

For a proprietary solution, reusing the ideas of ARI, but with other URL patterns or response formats, is of course possible. But then you are outside of any standard. Given that defining a new proprietary ARI variant has its pitfalls, it may work better to just reuse ARI as is (once standardized) and place the burden of reading a small JSON object onto your clients. If that is acceptable can only be judged by you, of course.

Using something like "just HTTP headers" sounds very simple, but HTTP headers and their semantics do not come for free either. There is a large caching infrastructure out there that might, or might not, be sensible to added Headers. Those complications might quickly outweight any JSON parsing burdens.

Kind Regards,
Stefan

> 
> From: Ryan Sleevi <[e-mail]>
> Sent: 18 February 2022 18:49
> To: Rob Stradling <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> Subject: Re: [Acme] Extending (A)RI to non-ACME use cases
>  
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> 
> On Fri, Feb 18, 2022 at 12:51 PM Rob Stradling <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme