Hi all, I'm a subscriber & relying party in the STIR/SHAKEN ecosystem.
I agree with both the comments from Chris Wendt and the proposal from Richard Barnes. I do believe that the "x5u" parameter should be optional and should only be presented when the CA is offering/committing to publicly publish the certificate & chain in the form which would be expected of an x5u being referenced in a signed JWT, such as the case in the STIR/SHAKEN scheme. I agree that hosting the issued certificate is optional in the space, but a quick review of call traffic from one of my systems shows that a majority of the certificates we're seeing referenced are being served up from URLs that are hosted by the issuing CAs. The offering is common among STIR/SHAKEN CAs. It is also hypothetically possible that other types of certificates from other spaces may also find value in the hosted certificate publication, particularly if these services are sending messages with any kind of signed JWT which will reference the issued certificate. Thanks, Matt Hardeman > On Aug 29, 2022, at 8:19 AM, 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 >> <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
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
