Re: [stir] [Acme] Authority Token WGLC

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 <debcooley1@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
>