Like Ryan, I'm pretty strongly opposed to including ARI URLs in certificates. The information is not intended for the relying party / user agent, so it amounts to extra bytes on the wire for every handshake that will just be ignored.
I'm also opposed to the protocol using HTTP headers or some form of information transport other than JSON. Rightly or not, JSON has become the lingua franca of structured data in web APIs. HTTP Headers are intended to carry metadata, like how long the response can be cached, not data. It would be inappropriate for this protocol to specify that the response be an empty body and that all semantically-meaningful information be conveyed in headers. Given that other proprietary automated issuance environments are not standardized, it is not clear to me what benefit standardizing ARI (or, I guess, just RI) under LAMPS would bring. Because those proprietary products do not expect to interoperate with a wide variety of clients, they are always welcome to choose to implement any subset of any specifications they like, regardless of what WG or document they come from. Aaron On Sat, Feb 19, 2022 at 2:54 AM Stefan Eissing <ste...@eissing.org> wrote: > > > > Am 19.02.2022 um 00:03 schrieb Rob Stradling <r...@sectigo.com>: > > > > > 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 <ryan-i...@sleevi.com> > > Sent: 18 February 2022 18:49 > > To: Rob Stradling <r...@sectigo.com> > > Cc: acme@ietf.org <acme@ietf.org> > > 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 <r...@sectigo.com> 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 > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
