Hi All, I coordinated a bit offline with Richard on new text, so this is integrated in the new draft revision as an optional technique.
-Chris > On Aug 29, 2022, at 9:21 AM, Richard Barnes <r...@ipv.sx> wrote: > > 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 > <mailto: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 >> <mailto: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 >> <mailto: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/> >> https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token-tnauthlist/ >> <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 <mailto:Acme@ietf.org> >> https://www.ietf.org/mailman/listinfo/acme >> <https://www.ietf.org/mailman/listinfo/acme> >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
