Subject: Re: [Acme] Pre-authorization approach

From: Richard Barnes <[email-masked]>
Date: Fri, 5 Aug 2016 14:12:59 -0400

On Wed, Jul 27, 2016 at 5:52 AM, Ilari Liusvaara <[email-masked]>
wrote:

> On Tue, Jul 26, 2016 at 02:29:54PM -0700, Andrew Ayer wrote:
> > On Tue, 26 Jul 2016 23:03:18 +0200
> > Richard Barnes <[email-masked]> wrote:
> >
> > > - Add an "identifiers" field to the application object
> > > - Each application MUST have exactly one of "csr" and "identifiers"
> > > - If "csr" is present, then do what's in the draft now
> > > - If "identifiers" is present, then do the same dance, but don't
> > > issue the certificate
> > >
> > > Does that sound sane to folks?  It still seems slightly gross to me,
> > > because of the switching based on the presence of fields.  Anyone have
> > > better ideas?
> >
> > This seems sane, and better than option 1.  The switching is gross, but
> > perhaps it can be made less gross with this logic:
> >
> > - "identifiers" MUST be present.
> > - "csr" MAY be present.
> > - If "csr" is present, its identifiers MUST match "identifiers".
> > - A certificate will only be issued if "csr" is present.
>
> IMO, that makes it even worse, by introducing duplication.
>
> Also, these pre-auth lists aren't actually valid applications,
> and I don't think one should treat those as applications.
>

Yeah, I'm sort of coming around to this opinion as well.  In addition to
this semantic mismatch, it's actually not that much additional machinery to
have the old new-authz endpoint present.  The authorization fulfillment
flow is already defined in Section 6.4, so all you have to specify is that
the client can also use the new-authz endpoint to initiate.

I'll take a cut at a PR.

--Richard

> -Ilari

---

From: Richard Barnes <[email-masked]>
Date: Fri, 5 Aug 2016 15:08:46 -0400

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

On Fri, Aug 5, 2016 at 2:12 PM, Richard Barnes <[email-masked]> wrote:

>
>
> On Wed, Jul 27, 2016 at 5:52 AM, Ilari Liusvaara <[email-masked]
> > wrote:
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sat, 6 Aug 2016 10:36:55 -0700

Having both new-application and new-authz seems simple enough from a
server perspective, but I think it will create interoperability problems
for clients. Specifically, most clients will choose to implement one
flow or the other. Most likely the existing clients will choose to
implement the new-authz flow because it will require minimal changes.

However, if I recall correctly, part of your reason for proposing the
new-application flow was that it more closely matches the workflow of
non-Let's Encrypt CAs, which tie actions to a certificate order or
certificate request. From that, I assume that such CAs would not
implement the new-authz flow. So we would have a large base of clients
that would not interoperate with CAs other than Let's Encrypt, which
defeats the purpose of having a standardized protocol.

The other motivation for the new-application flow was to provide a
framework that could support validation and issuance of wildcard names.
However, the current spec doesn't actually go into detail about a
validation method for wildcard names.

I also think EKR's comment that we need the ability to authorize domain
names without immediately issuing is a solid one*. So I think we should
take the conservative approach and roll back the new-application flow
for now. I do think we should document wildcard validation before we
finalize the spec, but new-application may not be the best way to do that.

*Eric, would you mind repeating what you said for the benefit of the
list? All we have right now are the notes and Richard's paraphrase.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 6 Aug 2016 10:49:27 -0700

> list? All we have right now are the notes and Richard's paraphrase.

To the best of my memory, my comment was that I thought it was unfortunate
that in order to register a domain you would have to generate a valid CSR
and potentially actually get it issued. This is especially true if the key
you
plan to use for authorization is of a type you never intend to issue into an
EE (e.g., you are authorizing with Ed255159 but you are planning to
issue ECDSA and RSA). And it may not be possible to make these align
if you have various restrictions due to HSMs.

-Ekr

---

From: Richard Barnes <[email-masked]>
Date: Sat, 6 Aug 2016 13:55:43 -0400

> defeats the purpose of having a standardized protocol.

To be clear, in the current spec, the new-app flow is not optional.  The
new-cert endpoint has been eliminated, so clients have to be able to at
least use new-app to request a certificate.

> validation method for wildcard names.

What else do you think is required for interoperability?  ISTM that the
current spec captures most current and suggested practices, including
everything from "validate the base name" to "validate some random
subdomains" to "validate some WHOIS information" (via OOB).  I'm skeptical
that we can define much more without ruling out some CAs' practices.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sat, 6 Aug 2016 11:11:09 -0700

> To be clear, in the current spec, the new-app flow is not optional. 
> The new-cert endpoint has been eliminated, so clients have to be able
> to at least use new-app to request a certificate.
Right. To rephrase: If part of the rationale for new-application is that
some CAs want all validation to be connected to a CSR, then those CAs
won't be able to implement an independent new-authz flow. So the
new-authz flow is incompatible with one of the main reasons you proposed
a new-application flow.
> What else do you think is required for interoperability?  ISTM that
> the current spec captures most current and suggested practices,
> including everything from "validate the base name" to "validate some
> random subdomains" to "validate some WHOIS information" (via OOB). 
> I'm skeptical that we can define much more without ruling out some
> CAs' practices.
I think providing one "ACME-approved" process for wildcards doesn't rule
out existing CA practices, any more than the ACME HTTP-01, TLS-SNI-02,
and DNS-01 challenges rule out existing DV methods.

The CA/Browser Forum's recent Ballot 169 specifies that validating
control of a base domain is sufficient to issue a wildcard. But I think
folks have have expressed a feeling that that's not strong enough. ACME
hasn't hesitated to take a stance on challenge methods. Similarly I
think it would be worthwhile to say "this is the default ACME way to get
a wildcard, but you can also use out-of-band methods."

---

From: Peter Bowen <[email-masked]>
Date: Sat, 6 Aug 2016 13:02:27 -0700

On Sat, Aug 6, 2016 at 11:11 AM, Jacob Hoffman-Andrews <[email-masked]> wrote:
> The CA/Browser Forum's recent Ballot 169 specifies that validating control
> of a base domain is sufficient to issue a wildcard. But I think folks have
> have expressed a feeling that that's not strong enough. ACME hasn't
> hesitated to take a stance on challenge methods. Similarly I think it would
> be worthwhile to say "this is the default ACME way to get a wildcard, but
> you can also use out-of-band methods."

ACME describes possible validation methods but does not tell any CA
what they _must_ use.  I think it is valid, under the current draft,
for a CA to only support out-of-band methods, right?

If ACME wants to specify a validation method for wildcards, then it
should be an option for CAs.  However, as you say, the CA can always
perform some other ritual and then expose the validation to the client
as an out of band authorization.  Or at least can in the current
draft.

Thanks,
Peter

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 6 Aug 2016 21:24:41 +0000

> ACME describes possible validation methods but does not tell any CA what
> they _must_ use.  I think it is valid, under the current draft, for a CA to only
> support out-of-band methods, right?

This is correct.

"Mechanism not policy" to bring back an old phrase :)

---

From: Andrew Ayer <[email-masked]>
Date: Tue, 9 Aug 2016 13:23:04 -0700

On Sat, 6 Aug 2016 10:36:55 -0700
Jacob Hoffman-Andrews <[email-masked]> wrote:

> So I think we should take the conservative approach and roll back the
> new-application flow for now.

I think the application flow should stay.  Many CAs, including the ones
that SSLMate abstracts over, tie authorizations to specific CSRs, so
SSLMate can't implement an ACME frontend without the application flow.
There's also a security reason to prefer CSR-tied authorizations
over account-tied authorizations: if you'd like to authorize a third party
to obtain a certificate on your behalf, being able to grant authorization
for only a single, specific certificate request is preferable to
granting carte blanche authorization to issue certificates for an
identifier.

I don't think there's a risk of interoperability problems if the
protocol supports both applications and new-authz.  All clients will
need to support both applications and authorizations in any case.  The
only difference in workflow is whether the authorization is retrieved by
POSTing to the new-authz endpoint, or by GETing a URL specified in the
application object.

There's one more reason to keep applications: if the CSR field is
mutable, applications provide a powerful abstraction to manage a
certificate over its entire lifetime, including across SAN changes and
renewals, as I discussed here:

	https://www.ietf.org/mail-archive/web/acme/current/msg01160.html

Regards,
Andrew

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 9 Aug 2016 16:55:00 -0700

> SSLMate can't implement an ACME frontend without the application flow.

Thanks, this is very helpful feedback.

> POSTing to the new-authz endpoint, or by GETing a URL specified in the

Given the above, how would SSLMate support POSTing to a new-authz endpoint?

---

From: Andrew Ayer <[email-masked]>
Date: Tue, 9 Aug 2016 17:27:36 -0700

On Tue, 9 Aug 2016 16:55:00 -0700
Jacob Hoffman-Andrews <[email-masked]> wrote:

> > need to support both applications and authorizations in any case.
> > The only difference in workflow is whether the authorization is
> > retrieved by POSTing to the new-authz endpoint, or by GETing a URL
> > specified in the application object.
> 

It wouldn't support that endpoint.  According to RLB's pull request, the
server can omit it from its directory if it's not supported.

This means that clients can't rely on the server offering this
endpoint.  Although there is a risk of half-baked implementations
assuming all servers support it, it seems unlikely that many would make
this mistake.  All clients have to go through the new-app workflow
anyways, and it's easier to just let the server create authorizations for
you.

Regards,
Andrew

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 9 Aug 2016 18:09:42 -0700

> anyways, and it's easier to just let the server create authorizations for

I disagree that the risk of half-baked clients. Experience shows that if
something works, some clients will do it, and will break if it's not
available.

This is exacerbated by the fact that the new-authz flow most closely
matches the flow currently implemented in Boulder and used by existing
ACME clients. So the reasonable and safe thing for a client maintainer
to do would be to keep using new-authz if Let's Encrypt continues to
offer it.

I think the only way to make sure the ecosystem of ACME clients is
actually interoperable with servers that don't implement new-authz is
for Let's Encrypt not to implement new-authz in its next API revision.
Which is reasonable, but it means that EKR's issue goes unaddressed.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 26 Aug 2016 14:19:59 -0400

This line of argument isn't really useful.  No matter what we specify here,
clients can choose to only implement a part of the spec.  (There are TLS
clients that only do RSA.)  Our responsibility here isn't to make sure that
there's nothing a client can skip, it's to make sure that a client that
wants to implement the whole spec can.

This change meets that bar.  The behavior specified for the client is clear
and implementable:

if (directory['new-authz']) {
  // do pre-auth if you want to
}
// do new-app

Given that, I think we should go ahead and land this change.

--Richard

On Tue, Aug 9, 2016 at 9:09 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 26 Aug 2016 18:25:49 +0000

As co-chair:

Let’s think about this over the weekend and – if you have something new, please post early next week.  Perhaps review the mailing list archives before posting.  Then we’ll try to determine consensus at the end of the week.

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Fri, 26 Aug 2016 12:09:40 -0700

On 08/06/2016 10:49 AM, Eric Rescorla wrote:
> 
> 
> On Sat, Aug 6, 2016 at 10:36 AM, Jacob Hoffman-Andrews <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> and potentially actually get it issued. This is especially true if the
> key you

Sorry to jump into this so late but could you elaborate on the use case
your are suggesting here? I am slightly confused about in what
circumstances you would want to authorize a domain for issuance, but not
actually issue for it.

In a situation where you i.e. don't know all of the names you want to
issue for in the future why not just wait until you do know all of those
names to create the authorizations? The same goes for the HSM situation
you describe, the key will be needed to sign the CSR at some point
anyway so why do the authorizations need to be created before the key is
used?

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Aug 2016 12:25:00 -0700

> anyway so why do the authorizations need to be created before the key is

The pattern here is you would have a management box that was responsible for
the domain authorization process and for signing off on CSRs for other
devices
but was not itself intended to act as a Web server for the domain (this is
more
plausible with non-SimpleHTTPS authentication). In that case, you might
pre-authorize all the domains but then on-the-fly have the actual origin
servers
make their own CSRs and get them signed off on by the management box. In
this case, you wouldn't ever need an account key to sign the CSR.

-Ekr

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Fri, 26 Aug 2016 13:33:34 -0700

On 08/26/2016 12:25 PM, Eric Rescorla wrote:
> 
> 
> On Fri, Aug 26, 2016 at 12:09 PM, Roland Bracewell Shoemaker
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > On Sat, Aug 6, 2016 at 10:36 AM, Jacob Hoffman-Andrews <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >
> but was not itself intended to act as a Web server for the domain (this
> is more

I'm still unsure why this is not currently possible with the new-app flow?

Assuming in your example the management box passes back a certificate
after receiving a CSR from a origin server the only difference I can see
is there may be increased latency as the management box has to complete
authorizations instead of instantly getting a certificate back from the
ACME server.

>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/acme>
>     >
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/acme>
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Aug 2016 14:17:08 -0700

On Fri, Aug 26, 2016 at 1:33 PM, Roland Bracewell Shoemaker <
[email-masked]> wrote:

> >     >     finalize the spec, but new-application may not be the best way
> to do
> >     >     that.
> >     >

Who says that the origin server is even up at the time you are authorizing
the
management box.

-Ekr