One minor point: STIR PASSporT objects reference certificates via the JWS "x5u" header, which requires that the URL respond to GET, vs. the POST-as-GET that is used for the ACME certificate URL. On the face of it, this would seem to require a STIR signer to download their certificate from the CA and republish it on a different server, and in fact ATIS-1000074 describes this behavior. However, current STIR CAs already offer GET-friendly URLs for their certificates, avoiding the need for such republication. It would be helpful (for STIR, but also more broadly) if this protocol had a field where a CA that provides this service could specify an "x5u"-friendly certificate URL.
It seems like there's a simple solution here, namely to add a field to completed order objects (state = "valid") that responds to GET requests and provides the certificate in the format "x5u" expects. You could even just call the field "x5u" :) Anyway, I realize it's late for a feature request, but this seems like a minor addition, and it seems like fixing this gap would allow the ecosystem to fit together a little more smoothly. --Richard On Tue, Aug 23, 2022 at 3:59 PM Deb Cooley <debcool...@gmail.com> wrote: > As we agreed at the acme session at IETF 114, this is a limited WGLC for > both: > > https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token/ > > https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token-tnauthlist/ > > I've added stir to the to line for good measure (and to broaden the pool > of reviewers a bit). We need to see if we can push these forward again. > > The review deadline is 6 Sep 2022. > > Deb Cooley > acme co-chair > > _______________________________________________ > 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
