Hey all,
This thread forked into a couple of different issues, so I wanted to post a
little end-of-day summary of the issues and where we stand. I've updated
the PR [1] to reflect most of today's discussion.
===
ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the
privacy
Hi Richard,
> I was able upgrade the lego client in a pretty short patch (5 files
> changed, 26 insertions(+), 16 deletions(-)) [0]. It interoperates
> with Daniel's branch of pebble.
you were faster :) I've adjusted Ansible's acme_certificate module to
also work with Daniel's branch in
On Fri, Aug 31, 2018 at 3:30 PM Jacob Hoffman-Andrews wrote:
> On 08/31/2018 07:25 AM, Richard Barnes wrote:
> > The problem with using POST-as-GET for certificate resources, as
> > Felipe I think pointed out, is that the thing that downloads the
> > certificate URL is often not an ACME player,
On Fri, Aug 31, 2018 at 3:30 PM Daniel McCarney wrote:
> here's a PR[0] for the Pebble ACME server that implements Richard's
>> proposal[1] to establish viability. The proposal seems OK to me given
>> the trade-offs/alternatives on the table.
>
>
> One of the changes Richard made in his second
I was able upgrade the lego client in a pretty short patch (5 files
changed, 26 insertions(+), 16 deletions(-)) [0]. It interoperates with
Daniel's branch of pebble.
--Richard
[1] https://github.com/bifurcation/lego/pull/1
On Fri, Aug 31, 2018 at 2:56 PM Daniel McCarney wrote:
> I think
On Fri, Aug 31, 2018 at 01:57:06PM -0700, Eric Rescorla wrote:
> On Fri, Aug 31, 2018 at 12:43 PM, Nico Williams
> wrote:
>
> > On Fri, Aug 31, 2018 at 03:37:01PM -0400, Daniel McCarney wrote:
> > > > How does using POST address this?
> > >
> > > Please read the draft. We're talking about POSTs
On 8/31/18 3:58 PM, Jacob Hoffman-Andrews wrote:
On 08/31/2018 01:51 PM, Adam Roach wrote:
The baseline problem here is that the original analysis that
determined that orders, authorizations, challenges, and certificates
were "not sensitive" was incorrect. These are all potentially
sensitive
On Fri, Aug 31, 2018 at 4:15 PM Jacob Hoffman-Andrews wrote:
> On 08/31/2018 12:30 PM, Jacob Hoffman-Andrews wrote:
> > /account/100/certificate/3438
> > /account/201/certificate/3439
> > /account/100/certificate/3440*
>
> Here's an issue that came up during code review: When you POST-as-GET to
On Fri, Aug 31, 2018 at 12:43 PM, Nico Williams
wrote:
> On Fri, Aug 31, 2018 at 03:37:01PM -0400, Daniel McCarney wrote:
> > > How does using POST address this?
> >
> > Please read the draft. We're talking about POSTs authenticated with JWS
> not
> > vanilla HTTP POSTs.
>
> That really should
On 8/31/18 3:14 PM, Jacob Hoffman-Andrews wrote:
That winds up leaving us pretty close to being back at draft-14: Since
POST-as-GET protects resource bodies, and the currently-specified
resources are already broken down into sensitive (account) and not
(orders, authorizations, challenges,
On 08/31/2018 12:30 PM, Jacob Hoffman-Andrews wrote:
/account/100/certificate/3438
/account/201/certificate/3439
/account/100/certificate/3440*
Here's an issue that came up during code review: When you POST-as-GET to
a resource you don't own, should you get Not Found or Unauthorized? The
On Fri, Aug 31, 2018 at 03:37:01PM -0400, Daniel McCarney wrote:
> > How does using POST address this?
>
> Please read the draft. We're talking about POSTs authenticated with JWS not
> vanilla HTTP POSTs.
That really should have been an HTTP authentication method :(
> How does using POST address this?
Please read the draft. We're talking about POSTs authenticated with JWS not
vanilla HTTP POSTs.
On Fri, Aug 31, 2018 at 3:34 PM, Nico Williams
wrote:
> On Thu, Aug 30, 2018 at 04:20:41PM -0700, Jacob Hoffman-Andrews wrote:
> > ACME currently has
On Thu, Aug 30, 2018 at 04:20:41PM -0700, Jacob Hoffman-Andrews wrote:
> ACME currently has unauthenticated GETs for some resources. This was
> originally discussed in January 2015[1]. We decided to put all sensitive
> data in the account resource and consider all GET resources public, with a
>
>
> In short, I think certificates should be POST-as-GET just like the other
> resources.
+1. If we're replacing the GETs to Orders, Authorizations and Challenges
there's no sense in excluding Certificates. I prefer the uniformity over
exceptions for use-cases that don't have strong real-world
>
> here's a PR[0] for the Pebble ACME server that implements Richard's
> proposal[1] to establish viability. The proposal seems OK to me given the
> trade-offs/alternatives on the table.
One of the changes Richard made in his second iteration of PR #445 was to
differentiate a POST from a
On 08/31/2018 07:25 AM, Richard Barnes wrote:
The problem with using POST-as-GET for certificate resources, as
Felipe I think pointed out, is that the thing that downloads the
certificate URL is often not an ACME player, doesn't have an account,
etc. It's a web server or something. (cf. the
I think its an anti-pattern to standardize protocol features that haven't
been implemented by anyone so here's a PR[0] for the Pebble ACME server
that implements Richard's proposal[1] to establish viability. The
proposal seems
OK to me given the trade-offs/alternatives on the table.
I would
STAR only requires that the server be able to GET the certificate URL,
right? If that's the case, I don't see a problem, given that the latest
version of the PR allows GET to certificate resources.
I don't think we can make authentication optional. That would revert us
back to having to do
+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
On Fri, Aug 31, 2018 at 01:46:24PM -0400, Richard Barnes wrote:
> On Fri, Aug 31, 2018 at 1:39 PM Benjamin Kaduk wrote:
>
> > On Fri, Aug 31, 2018 at 12:32:08PM -0400, Richard Barnes wrote:
> > >
> > > > Do you want to mention that the caaIdentities element gives a leaf cert
> > > > some control
On Fri, Aug 31, 2018 at 1:39 PM Benjamin Kaduk wrote:
> On Fri, Aug 31, 2018 at 12:32:08PM -0400, Richard Barnes wrote:
> > I've started a PR for your DISCUSS comments here:
> >
> > https://github.com/ietf-wg-acme/acme/pull/447
> >
> > Right now, there are the following major edits there:
> >
>
No, if a server receives a GET request for a resource other than those
specified, then it MUST return 405. But please check out the PR and see if
it's clear there.
On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich wrote:
>
>- * Servers MUST return a 405 if they get a GET for a resource other
>
Responses to COMMENT comments inline below (DISCUSS part trimmed). PR here:
https://github.com/ietf-wg-acme/acme/pull/448
On Thu, Aug 30, 2018 at 12:50 AM Adam Roach wrote:
>
> --
> COMMENT:
>
* * Servers MUST return a 405 if they get a GET for a resource other than
directory/newNonce/certificate.
They means client? Or there’s a word missing, and “they get a” is “they do not
support”
___
Acme mailing list
Acme@ietf.org
I've started a PR for your DISCUSS comments here:
https://github.com/ietf-wg-acme/acme/pull/447
Right now, there are the following major edits there:
- Added some text to the Security Considerations that clarifies that the
only protection we provide against an ACME MitM is that we prevent it
I have updated the pull request here with a couple of major changes:
* Instead of using the "typ" header parameter to signal POST-as-GET, the
client signals a POST-as-GET request by sending an empty JWS payload. It
seems like all of the actual-POST requests we have send a JSON object, so
this
The capability URL stuff introduces a level of complexity that I'd rather not
try to analyze at this point. I'm afraid people will rush to implement it and
get it wrong in hard to anticipate ways, or that there are consequences we
haven't foreseen at this late hour.
POSTs seem to be the right
The problem with using POST-as-GET for certificate resources, as Felipe I
think pointed out, is that the thing that downloads the certificate URL is
often not an ACME player, doesn't have an account, etc. It's a web server
or something. (cf. the STAR drafts.) What I'm saying is that it's
To be clear, I'm proposing that the server MUST allow GET for a certificate
resource (as well as POST-as-GET). It can protect those GETs with
capability URLs if it wants to.
On Fri, Aug 31, 2018 at 10:21 AM Felipe Gasper
wrote:
> I wonder, then, if it’s worth making it discoverable whether the
I wonder, then, if it’s worth making it discoverable whether the server allows
a plain GET for a certificate … other than, of course, getting a 405 back when
the client tries to request a certificate via GET.
-F
> On Aug 31, 2018, at 10:16 AM, Richard Barnes wrote:
>
> TBH, I'm not averse to
* - If a server is concerned about the privacy of certificate resources,
then they SHOULD assign them capability URLs.
Not a fan of capability URL’s; does get/post handle things well enough?
___
Acme mailing list
Acme@ietf.org
TBH, I'm not averse to allowing GETs for certificate resources. It seems
analogous to allowing them for the directory resource, just on the opposite
side of the process. That is, the directory and certificate resources are
the interfaces between ACME and the outside world, so it makes sense not
33 matches
Mail list logo
