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

From: Adam Roach <[email-masked]>
Date: Wed, 29 Aug 2018 21:50:31 -0700

Adam Roach has entered the following ballot position for
draft-ietf-acme-acme-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for all the work that everyone has put into this protocol. I'm excited by
what it's been able to do for the certificate issuance sector as a whole, and
truly appreciate all of the early implementors who have put both clients and
servers into active production. I'm definitely balloting YES once we get clarity
on my DISCUSS, below.

---------------------------------------------------------------------------

I've looked at this several different ways, and I must be missing something
obvious -- which should make this easy to clear.

§6.2:

>  Note that authentication via signed JWS request bodies implies that
>  GET requests are not authenticated.  Servers MUST NOT respond to GET
>  requests for resources that might be considered sensitive.  Account
>  resources are the only sensitive resources defined in this
>  specification.

This doesn't seem correct.

For example, let's imagine that I, as a user, get the directory for an ACME
server, the body of which is the example in §7.1.1. Then, I go through the
new-account process, and receive the Account object in §7.1.2:

   {
     "status": "valid",
     "contact": [
       "mailto:[email-masked]",
       "mailto:[email-masked]"
     ],
     "termsOfServiceAgreed": true,
     "orders": "https://example.com/acme/acct/1/orders"
   }

Huh. Suddenly, I'm not so interested in *my* orders, because I've noticed that
different users' orders are apparently at a predictable URL that varies only by
a small integer. Curious, I change the "1" to a "2" and send:

  GET /acme/acct/2/orders HTTP/1.1
  Host: example.com

And get back not *my* orders, but someone *else's* orders.

   HTTP/1.1 200 OK
   Content-Type: application/json

   {
     "orders": [
       "https://example.com/acme/acct/2/order/1",
       "https://example.com/acme/acct/2/order/2",
       "https://example.com/acme/acct/2/order/3",
       "https://example.com/acme/acct/2/order/4"
     ]
   }

Interesting. So now I can do four more unauthenticated GETs and grab those order
objects.

   HTTP/1.1 200 OK
   Content-Type: application/json

   {
     "status": "valid",
     ...
     "identifiers": [
       { "type": "dns", "value": "smithforcongress.example" }
     ],
     ...
     "certificate": "https://example.com/acme/cert/1234"
   }
----------
   HTTP/1.1 200 OK
   Content-Type: application/json

   {
     "status": "valid",
     ...
     "identifiers": [
       { "type": "dns", "value": "something-embarassing-with-goats.example" }
     ],
     ...
     "certificate": "https://example.com/acme/cert/5678"
   }
----------
   HTTP/1.1 200 OK
   Content-Type: application/json

   {
     "status": "valid",
     ...
     "identifiers": [
       { "type": "email", "value": "[email-masked]" }
     ],
     ...
     "certificate": "https://example.com/acme/cert/9abc"
   }
----------
   HTTP/1.1 200 OK
   Content-Type: application/json

   {
     "status": "valid",
     ...
     "identifiers": [
       { "type": "tn", "value": "+12025550172" }
     ],
     ...
     "certificate": "https://example.com/acme/cert/defg"
   }

So now I've learned that the same account has pulled certs for both
"smithforcongress.example" and "something-embarassing-with-goats.example"; that
they have control over the email address
"[email-masked]," and that their phone number is +1 202
555 0172. There's a pretty good chance that... someone didn't want all of that
to be generally known.

And... huh... that's interesting.

     GET /acme/cert/9abc HTTP/1.1
     Host: example.com

     HTTP/1.1 200 OK
     Content-Type: application/pem-certificate-chain
     Link: <https://example.com/acme/some-directory>;rel="index"

     -----BEGIN CERTIFICATE-----
     [X.509 Cert for [email-masked]]
     -----END CERTIFICATE-----
     -----BEGIN CERTIFICATE-----
     [Issuer certificate contents]
     -----END CERTIFICATE-----
     -----BEGIN CERTIFICATE-----
     [Other certificate contents]
     -----END CERTIFICATE-----

Whoa. That's cool. The next thing I'm doing is configuring Thunderbird to forge
mail from [email-masked] and going on an email spree
admitting to owning a rather embarrassing domain name, in which I ask concerned
constituents to call me on my unlisted phone number to discuss the issue.

Clearly I've missed something, because this just seems way too obvious. What
prevents this attack (or a similar one from observing that the order URLs are
predictable?)

If I *haven't* missed something, then there appears to have been an assumption
here, never written into the document, that the URLs generated for the orders
list and for the order objects are unguessable. If that's the case, I would:

(1) Expect this to be stated in section 7.1.2.1 and 7.1.3

(2) Expect a specification of a reasonable number of bits of entropy to use in
    orders list and order object URLs.

(3) Expect the examples to show appropriately random URLs (e.g.
    https://example.com/acme/acct/9258fac3-7866-4922-90e6-bbd0c89e751a/orders)

(4) Expect a treatment in section 10 of the risks that might arise from third
    parties gaining access to orders, as doing so provides free-and-clear access
    to private certificates (which, for dns, can be trivially used to
    revoke certs; and for other types, can be used for impersonation as well)

Again, I'm still expecting that I've simply missed something obvious -- I just
can't for the life of me figure out what it is.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have a small handful of substantive comments, and several editorial nits.

---------------------------------------------------------------------------

General:

This protocol specifies the use of RFC 3339 time formats in several places. Most
modern protocols that reference RFC 3339 choose to place further restrictions on
the format; commonly, the time-secfrac portion is required to be omitted, and
the time-offset portion is required to be "Z". In addition to making parsing
easier, these restrictions have the property of any given time having only one
possible string representation.

My suggestion would be for ACME to include similar restrictions. Alternately, if
the full range of optionality allowed by RFC 3339 is actually intended, please
adjust the examples so that at least a few of them include fractional seconds
and non-UTC timezones.

---------------------------------------------------------------------------

§5:

For avoidance of doubt, this section should probably indicate that values that
will appear in certificates will be used and conveyed in the form present in
certificates, possibly with a reference to RFC 5280 section 7.

---------------------------------------------------------------------------

§6.4.1:

>  The server MUST generate the value provided in
>  Replay-Nonce in such a way that they are unique to each message, with
>  high probability.  For instance, it is acceptable to generate Replay-
>  Nonces randomly.

It's not clear whether the values need to also be unpredictable; e.g., would it
be okay if the value of the nonce for operation n+1 could be easily derived or
guessed from the nonce for operation n?

---------------------------------------------------------------------------

§7.4.2:

>  GET /acme/cert/asdf HTTP/1.1
>  Host: example.com
>  Accept: application/pkix-cert
>
>  HTTP/1.1 200 OK
>  Content-Type: application/pem-certificate-chain

This pairing of "Accept: application/pkix-cert" with "Content-Type:
application/pem-certificate-chain" seems to be at odds with the description in
RFC 7231 §5.3.2. I know that proactive negotiation is optional in HTTP, but it
seems that it would be much better to show this as something like:

   GET /acme/cert/asdf HTTP/1.1
   Host: example.com
   Accept: application/pkix-cert, application/pem-certificate-chain;q=0.5

===========================================================================

All of my remaining comments are editorial in nature, and most of those are
minor editorial nits.

i-d nits reports:

  ** There are 3 instances of too long lines in the document, the longest one
     being 15 characters in excess of 72.

I'm not sure it's reasonable to expect the RFC editor to have enough knowledge
to know how to best split the key authorization across lines (or to elide
portions of it, whichever makes more sense).

---------------------------------------------------------------------------

i-d nits also reports:

  -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not
     defined in RFC 2119.  If it is intended as a requirements expression, it
     should be rewritten using one of the combinations defined in RFC 2119;
     otherwise it should not be all-uppercase.

---------------------------------------------------------------------------

§1:

>  Existing Web PKI certificate authorities tend to use a set of ad hoc
>  protocols for certificate issuance and identity verification.  In the
>  case of DV certificates, a typical user experience is something like:

I expect this text won't age gracefully. Even at the time of publication of
this document, over 64% of all certificates issued on the web have been issued
using the ACME protocol, arguably making it the "typical user experience." (see
https://censys.io/certificates/report?q=tags%3Atrusted&field=parsed.issuer.organization.raw&max_buckets=50)

I suggest caveating this paragraph with text along the lines of "prior to the
advent of the protocol described by this document, the typical user experience
was..."

---------------------------------------------------------------------------

§1:

>  For example, as of this writing, there is
>  ongoing work to use ACME for issuance of Web PKI certificates
>  attesting to IP addresses [I-D.ietf-acme-ip] and STIR certificates
>  attesting to telephone numbers [I-D.ietf-acme-telephone].

Suggestion: consider including [draft-ietf-acme-email-smime] in this list.

---------------------------------------------------------------------------

§6.2:

>  These intermediaries can also change values in the request that are
>  not signed in the HTTPS request, e.g., the request URL and headers.

Nit: "...header fields."

---------------------------------------------------------------------------

§6.4:

>  An error response with the
>  "badNonce" error type MUST include a Replay-Nonce header with a fresh
>  nonce.

Nit: "...header field..."

---------------------------------------------------------------------------

§6.5:

>  "urn:ietf:params:acme:error:rateLimited".  Additionally, the server
>  SHOULD send a "Retry-After" header [RFC7231] indicating when the
>  current request may succeed again.

Nit: "...header field..."

>  In addition to the human-readable "detail" field of the error
>  response, the server MAY send one or multiple link relations in the
>  "Link" header  [RFC8288] pointing to documentation about the specific
>  rate limit that was hit, using the "help" link relation type.

Nit: "...header field..."

---------------------------------------------------------------------------

§7.1:

>  The "->" is a mnemonic for a Location
>  header pointing to a created resource.

Nit: "...header field..."

---------------------------------------------------------------------------

§7.1.2.1:

>  The server MAY
>  return an incomplete list, along with a Link header with a "next"
>  link relation indicating where further entries can be acquired.

Nit: "...header field..."

---------------------------------------------------------------------------

§7.3.4:

>  This response MUST
>  include a Link header with link relation "terms-of-service" and the
>  latest terms-of-service URL.

Nit: "...header field..."

---------------------------------------------------------------------------

§7.4.2:

>  Because certificate resources are immutable once issuance is
>  complete, the server MAY enable the caching of the resource by adding
>  Expires and Cache-Control headers specifying a point in time in the
>  distant future.  These headers have no relation to the certificate's
>  period of validity.

Nit: "...header fields..." (twice)

>  The ACME client MAY request other formats by including an Accept
>  header [RFC7231] in its request.

Nit: "...header field..."

>  provide one or more "Link: rel="up"" headers pointing to an issuer or

Nit: "...header fields..."

---------------------------------------------------------------------------

§7.5:

>  When a client receives an order from the server it downloads the
>  authorization resources by sending GET requests to the indicated
>  URLs.

Nit: "...from the server, it downloads..."

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 Aug 2018 08:55:24 -0400

Focusing on DISCUSS comment for now, will pick up COMMENTs later.

On your DISCUSS, I think you're off on a couple of small things, but right
on the underlying point that the document doesn't really provide any
guidance as to which resources a server should consider sensitive.  I agree
that it would be good to say more, and I've started up a PR for this.

https://github.com/ietf-wg-acme/acme/pull/443

I don't agree that sensitivity entails a need for non-guessable URLs.  If
accessing the URL requires authentication, then it doesn't matter if
someone can guess it; unauthorized people can't access it even if they can
guess it.  I guess you could argue that if you made a random URL and only
distributed it in authenticated channels, then you could allow GETs to it,
using the URL itself as an authenticator.  But that seems super brittle; I
would rather just have all the authentication be based on signing.  So at
best, random URLs are a backstop against a CA making the wrong decision
about GETs.

You're also correct to note that some resources might be sensitive that we
now instruct clients to poll with GETs.  For example, the client is
supposed to poll an authorization resource to see when it validates, but if
the authz has a TN in it and so is considered sensitive, you won't be able
to do a GET.  I think the right answer here is to have the server return
405 Method Not Allowed if it gets a GET and have the client fall back to an
authenticated "POST {}", which should be equivalent to a GET in all cases.

--Richard

On Thu, Aug 30, 2018 at 12:50 AM Adam Roach <[email-masked]> wrote:

>        { "type": "dns", "value":
> "something-embarassing-with-goats.example" }
>      ],
>      ...

---

From: Adam Roach <[email-masked]>
Date: Thu, 30 Aug 2018 08:34:41 -0500

On 8/30/18 7:55 AM, Richard Barnes wrote:
> On your DISCUSS, I think you're off on a couple of small things

Yeah, I woke up with the sudden realization that I'd had the wrong model 
in my head when I talked through the cert endpoint. All that's there is 
a signed public cert rather than a public/private pair, so it's not 
sensitive.

> , but right on the underlying point that the document doesn't really 
> provide any guidance as to which resources a server should consider 
> sensitive.  I agree that it would be good to say more, and I've 
> started up a PR for this.
>

Thanks -- that fixes the text I cite.

>
> I don't agree that sensitivity entails a need for non-guessable URLs.  
> If accessing the URL requires authentication, then it doesn't matter 
> if someone can guess it; unauthorized people can't access it even if 
> they can guess it.  I guess you could argue that if you made a random 
> URL and only distributed it in authenticated channels, then you could 
> allow GETs to it, using the URL itself as an authenticator.  But that 
> seems super brittle; I would rather just have all the authentication 
> be based on signing.  So at best, random URLs are a backstop against a 
> CA making the wrong decision about GETs.

Yup, that seems better.

>
> You're also correct to note that some resources might be sensitive 
> that we now instruct clients to poll with GETs. For example, the 
> client is supposed to poll an authorization resource to see when it 
> validates, but if the authz has a TN in it and so is considered 
> sensitive, you won't be able to do a GET.  I think the right answer 
> here is to have the server return 405 Method Not Allowed if it gets a 
> GET and have the client fall back to an authenticated "POST {}", which 
> should be equivalent to a GET in all cases.

That seems like a good clarification. The one remaining issue is the 
table at the bottom of §7.1, which shows GETs for resources that the new 
text says CAs might consider sensitive. I catch the "might" in that 
sentence, but it seems that identification correlation is a pretty 
powerful privacy leak, and would strongly suggest that the table be 
revised to show POSTs for retrieval of order resources. Whether you take 
this suggestion is up to you -- I'll clear my DISCUSS either way.

/a

---

From: Felix Fontein <[email-masked]>
Date: Thu, 30 Aug 2018 15:48:50 +0200

Hello,

> Yeah, I woke up with the sudden realization that I'd had the wrong
> model in my head when I talked through the cert endpoint. All that's
> there is a signed public cert rather than a public/private pair, so
> it's not sensitive.

what happens if the cert URL is not
https://example.com/acme/cert/somerandomlookingidentifier, but
https://example.com/acme/acct/2/order/1/cert? Then someone can still do
identification correlation when the certificate can be downloaded
without authentication.

Cheers,
Felix

> > , but right on the underlying point that the document doesn't
> > really provide any guidance as to which resources a server should
> > consider sensitive.  I agree that it would be good to say more, and
> > I've started up a PR for this.
> >
> > I don't agree that sensitivity entails a need for non-guessable
> > URLs. If accessing the URL requires authentication, then it doesn't
> > matter if someone can guess it; unauthorized people can't access it
> > even if they can guess it.  I guess you could argue that if you
> > made a random URL and only distributed it in authenticated
> > channels, then you could allow GETs to it, using the URL itself as
> > an authenticator.  But that seems super brittle; I would rather
> > just have all the authentication be based on signing.  So at best,
> > random URLs are a backstop against a CA making the wrong decision
> > about GETs.  
> 
> 
> Yup, that seems better.
> 
> 
> >
> > here is to have the server return 405 Method Not Allowed if it gets
> > a GET and have the client fall back to an authenticated "POST {}",
> > which should be equivalent to a GET in all cases.  
> 
> 
> table at the bottom of §7.1, which shows GETs for resources that the
> new text says CAs might consider sensitive. I catch the "might" in
> that sentence, but it seems that identification correlation is a
> pretty powerful privacy leak, and would strongly suggest that the
> table be revised to show POSTs for retrieval of order resources.
> Whether you take this suggestion is up to you -- I'll clear my
> DISCUSS either way.
> 
> /a

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 30 Aug 2018 14:13:44 +0000

> I guess you could argue that if you made a random URL and only
    distributed it in authenticated channels, then you could allow GETs to it,
    using the URL itself as an authenticator.

Yuk.

We have seen too many instances where "guessable" private URL's exposed data where they shouldn't.  I don't think treating URL's as both the content-id and a security token is the way to go.

---

From: Adam Roach <[email-masked]>
Date: Thu, 30 Aug 2018 10:33:20 -0500

> identification correlation when the certificate can be downloaded

That's a good point as well.

After some further discussion, I think there are two potential paths 
forward:

 1. Remove all uses of GET from the specification (except for retrieving
    the directory), which causes all requests to be authenticated, or
 2. Scrub all of the ACME documents to ensure that the resources that
    can be retrieved without authentication cannot be correlated with
    each other.

Approach 1 (which is a stronger form of what Richard proposed in his PR) 
has the advantage of closing all privacy holes, even the ones that we 
can't identify at the moment. It has the disadvantage of differing from 
current deployed implementations.

Approach 2 has the advantage of being consistent with today's 
deployments, but has the drawback that it it requires significant new 
work to identify and address means of correlating resources with each 
other. It's worth noting that the extensibility of the protocol makes it 
necessary to perform this analysis every time a new field is added to a 
structure and every time a new HTTP endpoint type is defined, which 
makes this approach extremely fragile. In particular, the fact that 
individual implementations can include arbitrary JSON fields for 
debugging and/or proprietary behavior means that we're going to require 
implementations to independently perform this analysis for every 
nonstandard field they add to the structure as well.

/a

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 Aug 2018 11:42:13 -0400

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

On Thu, Aug 30, 2018 at 11:33 AM Adam Roach <[email-masked]> wrote:

> what happens if the cert URL is nothttps://example.com/acme/cert/somerandomlookingidentifier, buthttps://example.com/acme/acct/2/order/1/cert? Then someone can still do
>    1. Remove all uses of GET from the specification (except for
>    retrieving the directory), which causes all requests to be authenticated, or
>    can be retrieved without authentication cannot be correlated with each
>    other.
>
> has the advantage of closing all privacy holes, even the ones that we can't
> identify at the moment. It has the disadvantage of differing from current
> deployed implementations.
>
> Approach 2 has the advantage of being consistent with today's deployments,
> but has the drawback that it it requires significant new work to identify
> and address means of correlating resources with each other. It's worth
> noting that the extensibility of the protocol makes it necessary to perform
> this analysis every time a new field is added to a structure and every time
> a new HTTP endpoint type is defined, which makes this approach extremely
> fragile. In particular, the fact that individual implementations can
> include arbitrary JSON fields for debugging and/or proprietary behavior
> means that we're going to require implementations to independently perform
> this analysis for every nonstandard field they add to the structure as well.
>
> /a
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 30 Aug 2018 15:51:03 +0000

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 <[email-masked]>
Date: Thursday, August 30, 2018 at 11:42 AM
To: Adam Roach <[email-masked]>
Cc: "felix=[email-masked]" <felix=[email-masked]>, "[email-masked]" <[email-masked]>
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.

https://github.com/ietf-wg-acme/acme/pull/445<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=7dUyJM7__-T0aEsaHsL6mUJ8aY5ir3qquVg3g8SbiLs&s=6NSyMcFlAEWr3XtZ_GhVocgofBUBRZ3viFi5ZUdir-E&e=>

---

From: Felipe Gasper <[email-masked]>
Date: Thu, 30 Aug 2018 14:17:29 -0400

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=[email-masked]> wrote:
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Aug 2018 13:19:15 -0400

Responses to COMMENT comments inline below (DISCUSS part trimmed).  PR here:

https://github.com/ietf-wg-acme/acme/pull/448

Unless you can point me to an easy-to-specify,
univserally-supported-for-generation-and-consumption spec, I'm just going
to leave this as it is.

Done, but in the section 7.1.4 where we define the "dns" identifier type.

Done.

This was noted in Alexey's review, and is fixed in the corresponding PR:

https://github.com/ietf-wg-acme/acme/pull/442

Using my editorial discretion, I've just marked these as "Done" or
"Disagree".

> portions of it, whichever makes more sense).

Done.

This was noted in another IESG review (I think Ben's), and fixed in the
corresponding PR.

Disagree.

Disagree.

> >  not signed in the HTTPS request, e.g., the request URL and headers.

Done.

I think all of these were addressed in the response to Alexey's review.

https://github.com/ietf-wg-acme/acme/pull/442

> Nit: "...from the server, it downloads..."

Done.

---

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Fri, 31 Aug 2018 18:21:45 +0000

+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 <[email-masked]> on behalf of Felipe Gasper <[email-masked]>
Sent: 30 August 2018 20:17
To: Salz, Rich
Cc: [email-masked]
Subject: Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

-Felipe Gasper
Mississauga, Ontario

---

From: Richard Barnes <[email-masked]>
Date: Fri, 31 Aug 2018 14:32:29 -0400

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 privacy analysis for everything.  Note, however, that
the *authorization* that the server applies is still up to the server.  If
the server wants to have some external interface by which you could
authorize additional people to see your stuff, they are not forbidden from
doing so.

--Richard

On Fri, Aug 31, 2018 at 2:28 PM Fossati, Thomas (Nokia - GB/Cambridge) <
[email-masked]> wrote:

> [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
> 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=[email-masked]..org>
> wrote:
> >
> > 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.
> >
> > Cc: "felix=[email-masked]" <felix=
> [email-masked]>, "[email-masked]" <[email-masked]>
> > 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