Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

["Fossati, Thomas (Nokia - GB/Cambridge)" <[e-mail]>]

+1

As noted by Felipe, the implication that the service effectively
consuming the certificate has to have the ACME account's key at hand is
not always a practical nor a particularly secure arrangement.  (Another
example where this wouldn't work out particularly well is a single ACME
STAR certificate shared across multiple service instances in a HA
configuration.)
Broadly speaking, it looks like this is going to be problematic in all
cases where you'd want to decouple the certificate requester from the
certificate consumer roles.

In particular, I'm very concerned about the impact on STAR Requests.
In both its forms - as an ACME profile [1] as well as a standalone
protocol [2] - the design postulates that the certificate resource is
public.  This is a core precondition to allow delegation without sharing
credentials between the delegating and the delegated entities.  The
authenticated POST-as-GET access to the certificate resource completely
wrecks this architecture.

So, my question (just to be super clear: scoped only to the "POST-as-GET
certificate" part of the proposed change) is: Can we let the ACME user
decide whether to enable or disable this specific behaviour instead of
making it mandatory for everyone?

Cheers, thanks

[1] https://github.com/thomas-fossati/I-D/blob/acme-delegation-profile/STAR-Request/draft-sheffer-acme-star-delegation.md
[2] https://github.com/thomas-fossati/I-D/blob/acme-delegation-profile/STAR-Request/draft-sheffer-acme-star-request.md
________________________________________
From: Acme <[e-mail]> on behalf of Felipe Gasper <[e-mail]>
Sent: 30 August 2018 20:17
To: Salz, Rich
Cc: [e-mail]
Subject: Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

Would it work to keep certificate fetches as plain GET?

In shared hosting environments it’s common for a privileged process to request certificates on behalf of user accounts. This avoids having 1,000s of ACME server registrations from a single server. While certificates are generally made available within seconds, theoretically the delay between request and issuance could be much longer (e.g., for OV/EV), such that it might be prudent for that privileged process to give the order ID to the user and have the user poll for the certificate, e.g., via cron.

-Felipe Gasper
Mississauga, Ontario


> On Aug 30, 2018, at 11:51 AM, Salz, Rich <rsalz=[e-mail]> wrote:
>
> It appears that we missed a security issue.
>
> Please take a look at the PR mentioned below.  It removes many GET requests and turns them into POST so that the client payload can have authentication information.
>
> If you object to this change, please post a note to the list and explain why.  Try to do that within a week.
>
> Thanks.
>
> From: Richard Barnes <[e-mail]>
> Date: Thursday, August 30, 2018 at 11:42 AM
> To: Adam Roach <[e-mail]>
> Cc: "felix=[e-mail]" <felix=[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
>
> My preference here would be for approach (1).  I appreciate that it's a big change to make this late in the process, but that's the price we pay for missing a pretty significant issue up until now.  For existing implementations, the code impact should be modest, as long as they have been architected to isolate fetch logic (i.e., the have a get() method that you could just change to do the right POST thing).  And as long as we don't *forbid* responding to GET requests, servers can support both options for the time being.
>
> To illustrate what change we'd need to make, I went ahead and wrote up a PR:
>
> https://github.com/ietf-wg-acme/acme/pull/445
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme

_______________________________________________
Acme mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/acme