Re: [stir] [Acme] Authority Token WGLC

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-ietf@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 <rlb@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 <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
>>
>
>