Yeah, I was definitely thinking it would be optional. If the new field is present, a client could use it as its x5u parameter. If not, the client knows it has to download and republish the certificate.
—Richard On Mon, Aug 29, 2022 at 09:19 Chris Wendt <chris-i...@chriswendt.net> wrote: > Hi Richard, > > Thanks for the review. So, just to make sure i’m understanding, you are > saying that we should have a feature where both the POST-as-GET standard > ACME certificate URL is kept, but we also (maybe optionally or are you > saying should mandate this?) offer the ability for a CA hosted URL that > would be used directly in PASSporT for making the certificate available for > relying party consumption? > > The idea that a CA offers direct URL to certificate has always been > considered optional in SHAKEN, originally the thought was that it would be > hosted under HTTPS address of the ACME client customer (service provider). > I think as things have been implemented in the industry where it turns out > many of the CAs are also hosted by vendors of the entire hosted STIR/SHAKEN > solutions, as you state that hasn’t been the case and is often hosted under > vendor/CA URL. > > I think if we include it as optional, I have no issue including it, if we > think it needs to be mandatory would probably want to get more feedback > from others. > > -Chris > > On Aug 26, 2022, at 5:02 PM, Richard Barnes <r...@ipv.sx> wrote: > > 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
