Re: [Acme] Authority Token WGLC

[Chris Wendt]

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  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  > 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 > > 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-174 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 > > 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

Re: [Acme] Authority Token WGLC

[Chris Wendt]

Hi Sean,

Thanks, i have incorporated the text changes you suggested into new release of 
the tnauthlist document that incorporates Richard’s suggestions as well.

-Chris

> On Sep 6, 2022, at 10:40 PM, Sean Turner  wrote:
> 
> Hi! 
> 
> I had a read of these two I-Ds. Comments follow:
> 
> # -authority-token
> 
> tl;dr: editorial and nits
> 
> 0) s8: I-D Nits complains about "Authority Tokens SHOULD not”. So s/SHOULD 
> not/SHOULD NOT
> 
> 1) s9.1: I-D Nits complains about dancing references to RFCs 3986 and 4648. I 
> guess you could work them in, but if not then just drop them.
> 
> 2) s3: Expand CAs on first use: s/CAs/Certification Authorities (CAs)
> 
> 3) s3.1: Consider adding a reference to 8126, where Specification Required is 
> defined:
> 
> s/The IANA will maintain a registry of tkauth-types under a policy of 
> Specification Required./The IANA will maintain a registry of tkauth-types 
> under a policy of Specification Required [RFC8126].
> 
> 4) s3.1: Wording tweak - requirements just kind of hangs there:
> 
> s/In order to register a new tkauth-type, specifications must address the 
> following requirements; in cases where a tkauth-type admits of its own 
> subtypes, subtypes inherit these requirements./s/In order to register a new 
> tkauth-type, specifications must address the requirements in this section; in 
> cases where a tkauth-type admits of its own subtypes, subtypes inherit these 
> requirements.
> 
> 5) s.3.1: 2119 it:
> 
> s/Therefore, in defining tkauth-types, future specifications must 
> indicate/Therefore, in defining tkauth-types, future specifications MUST 
> indicate
> 
> 6) s8: 2119 it:
> 
> s/ … HTTPS REST client and the Token Authority must also exist …
> /… HTTPS REST client and the Token Authority MUST also exist …
> 
> s/Implementations should follow the best practices identified in [RFC8725].
> /Implementations SHOULD follow the best practices identified in [RFC8725].
> 
> 7) s8: dangling )
> 
> s/Section 4)./Section 4.
> 
> 8) s8: algorithms for keys:
> 
> s/permit other keys/permit other algorithms
> s/define new keys/define new algorithms
> 
> 
> # -authority-token-tnnauthlist
> 
> (note I also did the ARTART review)
> 
> tl;dr: looks like -09 fixed my ARTART review comments and now I have but one 
> new nit:
> 
> 1) algorithms for keys:
> 
> s/permit other keys/permit other algorithms
> s/define new keys/define new algorithms
> 
> Cheers,
> spt
> 
>> On Aug 23, 2022, at 15:58, Deb Cooley  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

Re: [Acme] Authority Token WGLC

[Sean Turner]

Hi! 

I had a read of these two I-Ds. Comments follow:

# -authority-token

tl;dr: editorial and nits

0) s8: I-D Nits complains about "Authority Tokens SHOULD not”. So s/SHOULD 
not/SHOULD NOT

1) s9.1: I-D Nits complains about dancing references to RFCs 3986 and 4648. I 
guess you could work them in, but if not then just drop them.

2) s3: Expand CAs on first use: s/CAs/Certification Authorities (CAs)

3) s3.1: Consider adding a reference to 8126, where Specification Required is 
defined:

s/The IANA will maintain a registry of tkauth-types under a policy of 
Specification Required./The IANA will maintain a registry of tkauth-types under 
a policy of Specification Required [RFC8126].

4) s3.1: Wording tweak - requirements just kind of hangs there:

s/In order to register a new tkauth-type, specifications must address the 
following requirements; in cases where a tkauth-type admits of its own 
subtypes, subtypes inherit these requirements./s/In order to register a new 
tkauth-type, specifications must address the requirements in this section; in 
cases where a tkauth-type admits of its own subtypes, subtypes inherit these 
requirements.

5) s.3.1: 2119 it:

s/Therefore, in defining tkauth-types, future specifications must 
indicate/Therefore, in defining tkauth-types, future specifications MUST 
indicate

6) s8: 2119 it:

s/ … HTTPS REST client and the Token Authority must also exist …
/… HTTPS REST client and the Token Authority MUST also exist …

s/Implementations should follow the best practices identified in [RFC8725].
/Implementations SHOULD follow the best practices identified in [RFC8725].

7) s8: dangling )

s/Section 4)./Section 4.

8) s8: algorithms for keys:

s/permit other keys/permit other algorithms
s/define new keys/define new algorithms


# -authority-token-tnnauthlist

(note I also did the ARTART review)

tl;dr: looks like -09 fixed my ARTART review comments and now I have but one 
new nit:

1) algorithms for keys:

s/permit other keys/permit other algorithms
s/define new keys/define new algorithms

Cheers,
spt

> On Aug 23, 2022, at 15:58, Deb Cooley  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

Re: [Acme] Authority Token WGLC

[Matthew D. Hardeman]

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  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 > > 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-174 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 > > 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

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Authority Token WGLC

[Richard Barnes]

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  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  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-174 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  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

Re: [Acme] Authority Token WGLC

[Chris Wendt]

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  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-174 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  > 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

Re: [Acme] Authority Token WGLC

[Richard Barnes]

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-174 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  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