Subject: [Acme] Pre-authorization approach

From: Richard Barnes <[email-masked]>
Date: Tue, 26 Jul 2016 23:03:18 +0200

Hey folks,

At the IETF meeting, EKR pointed out the need to have a "pre-authorization"
function in ACME, where the client can get authorization to issue for
certain names without causing a certificate to be issued.  Having thought
about this a bit on the way home from the meeting, I'd like to get some
feedback on how to go about this.

As a starting point, consider the following options:

Option 1: Add a "preAuth" flag to the application request/struct, such that
if that flag is set, then the server will not issue a certificate once the
application completes.  However, that would still require the client to
send a CSR, which on the one hand is a hassle (unneeded public-key
operations) and on the other hand, risks bad server implementations missing
the flag and issuing anyway.

Option 2: copy/paste the "new-authz" flow back into the spec.  However,
that's a lot of spec machinery to re-import, and it doesn't allow the CA to
express any sort of simplification due to multiple domain names, such as
the "just validate the top-level domain" policy in the other thread that's
going on right now.

Given those trade-offs, I wonder if some sort of intermediate approach
would be better.  The best thing that's come to me so far is to fork the
application process:

- 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?

Thanks,
--Richard

---

From: Andrew Ayer <[email-masked]>
Date: Tue, 26 Jul 2016 14:29:54 -0700

On Tue, 26 Jul 2016 23:03:18 +0200
Richard Barnes <[email-masked]> wrote:

> would be better.  The best thing that's come to me so far is to fork
> the application process:
> 
> - If "identifiers" is present, then do the same dance, but don't
> issue the certificate
> 

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.

Regards,
Andrew

---

From: Patrick Figel <[email-masked]>
Date: Tue, 26 Jul 2016 23:57:10 +0200

On 26/07/16 23:03, Richard Barnes wrote:
> Option 2: copy/paste the "new-authz" flow back into the spec. 
> However, that's a lot of spec machinery to re-import, and it doesn't
>  allow the CA to express any sort of simplification due to multiple 
> domain names, such as the "just validate the top-level domain" policy
> in the other thread that's going on right now.
> 
> Given those trade-offs, I wonder if some sort of intermediate 
> approach would be better.  The best thing that's come to me so far is
> to fork the application process:
> 

One problem I see here is that a identifier of type: "dns" is currently
defined as a FQDN, without a wildcard label, which would be a valid
value of a dNSName field in a CSR (the decision of whether that's
acceptable and which identifiers need to be validated for that value
being up to server policy).

With these options, we'd have to either:
1. Re-define identifiers to allow wildcard labels (probably not a good
idea?),
2. use a different name/type that allows wildcards (or more generally:
anything you might consider a valid identifier in a CSR), or
3. force clients to understand server policy if they want to use
pre-authorizations by asking them to predict exactly which FQDNs the
server would ask to be validated in advance (which might be more or less
impossible if, as an example, the server policy for wildcard domains is
"solve a challenge for a random subdomain"). Given that this was one of
the reasons for the "Application" refactor (IIRC), I don't think that's
a good option either.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Jul 2016 10:00:23 +0200

> - A certificate will only be issued if "csr" is present.

Yes, this seems basically sound...

-Ekr

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

---

From: Niklas Keller <[email-masked]>
Date: Wed, 27 Jul 2016 10:17:22 +0200

2016-07-26 23:03 GMT+02:00 Richard Barnes <[email-masked]>:

> Hey folks,
>
> At the IETF meeting, EKR pointed out the need to have a
> "pre-authorization" function in ACME, where the client can get
> authorization to issue for certain names without causing a certificate to
> be issued.  Having thought about this a bit on the way home from the
> meeting, I'd like to get some feedback on how to go about this.
>

Could you line out the reason for the need?

Thanks, Niklas

> Option 1: Add a "preAuth" flag to the application request/struct, such
> that if that flag is set, then the server will not issue a certificate once
> the application completes.  However, that would still require the client to

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 27 Jul 2016 12:52:06 +0300

> - 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.

-Ilari