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
requests for certificate resources...":
The server MAY choose to allow GET requests to certain certificate
resources but not to others. The server can base this decision on
out-of-band knowledge (e.g., to allow GET requests to certificates owned
by a certain account) or on order-specific information, such as the
extension defined in {{?I-D.ietf-acme-star}}.
Thanks,
Yaron
On 01/09/18 01:08, Richard Barnes wrote:
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 analysis?
It seems like there's pretty strong agreement that we should get rid
of GET, as the architecturally cleanest option.
===
ISSUE 2: How should we signal that POST-as-GET request is different
from other POST requests?
The current PR signals this by sending a JWS with an empty
(zero-octet) payload, instead of a JSON object. Jacob and Daniel
suggested that we should instead use the payload being an empty JSON
object as the signal. An earlier draft PR used a field in the
protected header.
===
ISSUE 3: Should servers be required to allow GET requests for
certificate URLs?
I had proposed this earlier today; Jacob and Daniel pushed back. I
have implemented a compromise in the latest PR, where servers MAY
accept GET requests.
===
ISSUE 4: How should we address the risk that an attacker can discover
URLs by probing for Unauthorized vs. Not Found?
There seemed to be agreement on the list that this should be addressed
with some guidance to servers on how to assign URLs. I have just
added some text to the PR for this.
===
It seems to me we're pretty much closed on the first issue, and the
other three are still open. Please send comments, so we can resolve
this issue and get the document back in motion!
Thanks,
--Richard
[1] https://github.com/ietf-wg-acme/acme/pull/445
On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews <j...@eff.org
<mailto:j...@eff.org>> 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.
Adam Roach recently pointed out in his Area Director review that even
when the contents of GET URLs aren’t sensitive, their correlation may
be. For instance, some CAs might consider the grouping of
certificates
by account to be sensitive.
Richard Barnes proposes[2] to change all GETs to POSTs (except
directory
and new-nonce). This will be a breaking change. Clients that were
compatible with previous drafts, informally called ACMEv1 and ACMEv2,
will not be compatible with a draft that mandates POSTs
everywhere. It
will be a painful change, since the ecosystem just started
switching to
ACMEv2, which looked to be near-final.
I think this is the right path forwards. ACME will be a simpler,
better
protocol long-term if all requests are authenticated. However, if
we’re
taking this path we should aim to come to consensus and land the
final
spec quickly to reduce uncertainty for ACME client implementers.
[1]
https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712
[2] https://github.com/ietf-wg-acme/acme/pull/445/files
_______________________________________________
Acme mailing list
Acme@ietf.org <mailto:Acme@ietf.org>
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
