At 16:03 10/09/2018 Monday, Erica Portnoy wrote:
>> I think you must have
>> as all this discussion relates to traffic from acme-client to acme-server
>> thus both https
>> and obviously 1 known api/name
>>
>> you seem to be discussing traffic to an acme-customer's webserver
>
>Yes, because
[as an individual]
On 9/7/18 6:48 PM, Erica Portnoy wrote:
If someone's in a position to watch traffic going *from* a server
trying to authenticate, they can certainly watch traffic going *to*
that server, and note the various domain names being hosted on that
server (since no encrypted sni
> I think you must have
> as all this discussion relates to traffic from acme-client to acme-server
> thus both https
> and obviously 1 known api/name
> > you seem to be discussing traffic to an acme-customer's webserver Yes, because the acme client and the client's web server are often the same
uot;<mailto:acme@ietf.org>acme@ietf.org"
>><<mailto:acme@ietf.org>acme@ietf.org>
>>Cc: "<mailto:acme-cha...@ietf.org>"
>><<mailto:acme-cha...@ietf.org>acme-cha...@ietf.org>, Eric Rescorla
>><<mailto:e...@rtfm.c
>
>
> *From: *Richard Barnes
> *Date: *Thursday, September 6, 2018 at 11:02 AM
> *To: *"acme@ietf.org <mailto:acme@ietf.org>" <mailto:acme@ietf.org>>
> *Cc: *"" <mailto:acme-cha...@ietf.org>>, Eric Rescorla
, September 6, 2018 at 11:02 AM
To: "acme@ietf.org"
Cc: "" , Eric Rescorla
, Adam Roach
Subject: Re: [Acme] ACME breaking change: Most GETs become POSTs
Resent-From:
Resent-To: Rich Salz , Yoav Nir
Resent-Date: Thursday, September 6, 2018 at 11:02 AM
After the weekend's discu
After the weekend's discussions, I've updated the PR to reflect what I
understand to be emerging agreement on these topics:
ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the
privacy analysis?
PROPOSED RESOLUTION: Yes.
ISSUE 2: How should we signal that POST-as-GET request
On 08/31/2018 03:08 PM, Richard Barnes wrote:
ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing
the privacy analysis?
Agreed we're solved on this.
ISSUE 2: How should we signal that POST-as-GET request is different
from other POST requests?
Started a separate thread on this.
Hi Richard,
I think we're in a good place, even from a STAR perspective (where
certificates must be accessible with a GET, or the whole thing breaks
down). To clarify the behavior further, I suggest to add the following
text after the paragraph that says that "The server MAY allow GET
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
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
>
* * 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 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
elipe Gasper
> Cc: ACME WG
> Subject: Re: [Acme] ACME breaking change: Most GETs become POSTs
>
> On Thu, Aug 30, 2018 at 08:45:50PM -0400, Felipe Gasper wrote:
> > I suppose if I have:
> >
> > GET /order/123/certificate=> cert for yin.com
> >
>
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
> On Aug 30, 2018, at 7:48 PM, Jacob Hoffman-Andrews wrote:
>
> (Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's
> Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)")
>
> On 08/30/2018 11:17 AM, Felipe Gasper wrote:
> > Would it work to keep certificate
On 8/30/18 6:20 PM, 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 slant towards transparency.
(Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's
Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)")
On 08/30/2018 11:17 AM, Felipe Gasper wrote:
> Would it work to keep certificate fetches as plain GET?
>
> In shared hosting environments it’s common for a
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 slant towards transparency.
Adam Roach recently pointed out in his Area
40 matches
Mail list logo
