Subject: [Acme] Backing-out capability URLs from the spec (added in #445)

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 5 Oct 2018 09:21:52 -0700

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

---

From: Adam Roach <[email-masked]>
Date: Fri, 5 Oct 2018 12:40:36 -0500

[as an individual]

On 10/5/18 11:21 AM, Jacob Hoffman-Andrews wrote:
> 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: 
> 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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 5 Oct 2018 15:41:26 -0400

On Fri, Oct 5, 2018 at 1:41 PM Adam Roach <[email-masked]> 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:
> (authenticated) and non-sensitive ones (unauthenticated). The recent round
> of POST-as-GET changes consolidates things so nearly everything is
> certificates to be authenticated, let's authenticate them the same way as
> everything else, and let the STAR group define an extension for
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 5 Oct 2018 15:55:29 -0700

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

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 5 Oct 2018 16:17:25 -0700

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:
> > 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 
> 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.
>
> 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.
>
>

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 9 Oct 2018 10:22:52 -0400

I'm strongly in favour of Jacob's suggestions in 459.

On Fri, Oct 5, 2018 at 7:17 PM Jacob Hoffman-Andrews <[email-masked]> wrote:

> 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.
>
> revisions, and claim they are non-significant simply because they are not
> formally normative.
>
> 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 [email-masked]://www.ietf.org/mailman/listinfo/acme
>
>