Re: [stir] [Acme] Authority Token WGLC

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 <rlb@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-ietf@chriswendt.net <mailto: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 <mailto: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 <mailto: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/>
>> 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>
> 