Re: [Acme] Backing-out capability URLs from the spec (added in #445)
I'm strongly in favour of Jacob's suggestions in 459. On Fri, Oct 5, 2018 at 7:17 PM Jacob Hoffman-Andrews wrote: > Here's my proposal that removes the STAR special-casing in ACME, making > certificate URLs behave the same way as all other fetchable resources: > https://github.com/ietf-wg-acme/acme/pull/459. > > Sticking STAR concerns into the ACME draft so late in ACME development is > only going to cause issues. At the point, we need to be locking things down > and removing unused features, not introducing new fiddly bits for the sake > of drafts that can easily be implemented as an extension to the main draft. > > On 10/05/2018 03:55 PM, Jacob Hoffman-Andrews wrote: > > > The removed language is a non-normative statement of fact > > You can't introduce a new authentication method in post-Last Call > revisions, and claim they are non-significant simply because they are not > formally normative. > > > It seems like you're trying to get rid of a better option to maintain > the appearance architectural purity. > > Nope, this is not a matter of architectural purity. Capability URLs are a > strictly weaker authentication method than the JWS-based POSTs used > everywhere in the protocol. If you read the doc ( > https://www.w3.org/TR/capability-urls/), it's all about the risks > involved and how they should only be used as a last resort. The language we > had up to draft 13 made this very explicit: GETs are not authenticated. > > It seems like this was introduced in response to the STAR group requesting > that final certificates be made GETtable. This was a pretty tenuous claim > anyhow: If most ACME servers require POST for certificates, STAR-shaped > clients won't be able to interoperate with them. So if you feel like STAR > needs some special way to authenticate GETs, with lower security > requirements than ACME, let's punt that to the STAR spec. Certificate GETs > in ACME can be a MUST POST like everything else, and STAR can declare a > "gettable certificate" extension. > > > ___ > Acme mailing listAcme@ietf.orghttps://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] Backing-out capability URLs from the spec (added in #445)
Here's my proposal that removes the STAR special-casing in ACME, making certificate URLs behave the same way as all other fetchable resources: https://github.com/ietf-wg-acme/acme/pull/459. Sticking STAR concerns into the ACME draft so late in ACME development is only going to cause issues. At the point, we need to be locking things down and removing unused features, not introducing new fiddly bits for the sake of drafts that can easily be implemented as an extension to the main draft. On 10/05/2018 03:55 PM, Jacob Hoffman-Andrews wrote: >The removed language is a non-normative statement of fact You can't introduce a new authentication method in post-Last Call revisions, and claim they are non-significant simply because they are not formally normative. > It seems like you're trying to get rid of a better option to maintain the appearance architectural purity. Nope, this is not a matter of architectural purity. Capability URLs are a strictly weaker authentication method than the JWS-based POSTs used everywhere in the protocol. If you read the doc (https://www.w3.org/TR/capability-urls/), it's all about the risks involved and how they should only be used as a last resort. The language we had up to draft 13 made this very explicit: GETs are not authenticated. It seems like this was introduced in response to the STAR group requesting that final certificates be made GETtable. This was a pretty tenuous claim anyhow: If most ACME servers require POST for certificates, STAR-shaped clients won't be able to interoperate with them. So if you feel like STAR needs some special way to authenticate GETs, with lower security requirements than ACME, let's punt that to the STAR spec. Certificate GETs in ACME can be a MUST POST like everything else, and STAR can declare a "gettable certificate" extension. ___ 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] Backing-out capability URLs from the spec (added in #445)
>The removed language is a non-normative statement of fact You can't introduce a new authentication method in post-Last Call revisions, and claim they are non-significant simply because they are not formally normative. > It seems like you're trying to get rid of a better option to maintain the appearance architectural purity. Nope, this is not a matter of architectural purity. Capability URLs are a strictly weaker authentication method than the JWS-based POSTs used everywhere in the protocol. If you read the doc (https://www.w3.org/TR/capability-urls/), it's all about the risks involved and how they should only be used as a last resort. The language we had up to draft 13 made this very explicit: GETs are not authenticated. It seems like this was introduced in response to the STAR group requesting that final certificates be made GETtable. This was a pretty tenuous claim anyhow: If most ACME servers require POST for certificates, STAR-shaped clients won't be able to interoperate with them. So if you feel like STAR needs some special way to authenticate GETs, with lower security requirements than ACME, let's punt that to the STAR spec. Certificate GETs in ACME can be a MUST POST like everything else, and STAR can declare a "gettable certificate" extension. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Backing-out capability URLs from the spec (added in #445)
On Fri, Oct 5, 2018 at 1:41 PM Adam Roach wrote: > [as an individual] > > On 10/5/18 11:21 AM, Jacob Hoffman-Andrews wrote: > > In the rounds of reviews on https://github.com/ietf-wg-acme/acme/pull/445, > I missed an addition: the suggestion to use capability URLs for access > control on certificate URLs. We should definitely not introduce this into > the spec: ACME has one authentication model, based on JWS signing. We > shouldn't introduce another, weaker authentication model. I pointed this > out way back in 2015: > https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712. > > At the time, the WG decision was to split resources into sensitive ones > (authenticated) and non-sensitive ones (unauthenticated). The recent round > of POST-as-GET changes consolidates things so nearly everything is > authenticated. I don't think there's a strong case to introduce a new, > halfway level of authentication based on capability URLs. If we want > certificates to be authenticated, let's authenticate them the same way as > everything else, and let the STAR group define an extension for > unauthenticated URLs. Here's my PR backing out the change: > https://github.com/ietf-wg-acme/acme/pull/457 > > > I oppose this change. The removed language is a non-normative statement > of fact for the benefit of implementors. Removing it does not change the > fact that capability URLs can be used in this context; it simply hides this > fact from the reader. > I think Adam is on the right track here. Jacob: The change you're proposing makes security worse. The security properties of GET-without-capability-URLs are strictly worse than GET-with-capability-URLs. It seems like you're trying to get rid of a better option to maintain the appearance architectural purity. --Richard /a > ___ > 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] Backing-out capability URLs from the spec (added in #445)
[as an individual] On 10/5/18 11:21 AM, Jacob Hoffman-Andrews wrote: In the rounds of reviews on https://github.com/ietf-wg-acme/acme/pull/445, I missed an addition: the suggestion to use capability URLs for access control on certificate URLs. We should definitely not introduce this into the spec: ACME has one authentication model, based on JWS signing. We shouldn't introduce another, weaker authentication model. I pointed this out way back in 2015: https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712. At the time, the WG decision was to split resources into sensitive ones (authenticated) and non-sensitive ones (unauthenticated). The recent round of POST-as-GET changes consolidates things so nearly everything is authenticated. I don't think there's a strong case to introduce a new, halfway level of authentication based on capability URLs. If we want certificates to be authenticated, let's authenticate them the same way as everything else, and let the STAR group define an extension for unauthenticated URLs. Here's my PR backing out the change: https://github.com/ietf-wg-acme/acme/pull/457 I oppose this change. The removed language is a non-normative statement of fact for the benefit of implementors. Removing it does not change the fact that capability URLs can be used in this context; it simply hides this fact from the reader. /a ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Backing-out capability URLs from the spec (added in #445)
In the rounds of reviews on https://github.com/ietf-wg-acme/acme/pull/445, I missed an addition: the suggestion to use capability URLs for access control on certificate URLs. We should definitely not introduce this into the spec: ACME has one authentication model, based on JWS signing. We shouldn't introduce another, weaker authentication model. I pointed this out way back in 2015: https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712. At the time, the WG decision was to split resources into sensitive ones (authenticated) and non-sensitive ones (unauthenticated). The recent round of POST-as-GET changes consolidates things so nearly everything is authenticated. I don't think there's a strong case to introduce a new, halfway level of authentication based on capability URLs. If we want certificates to be authenticated, let's authenticate them the same way as everything else, and let the STAR group define an extension for unauthenticated URLs. Here's my PR backing out the change: https://github.com/ietf-wg-acme/acme/pull/457 ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
