Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR

From: Hugo Landau <[email-masked]>
Date: Tue, 24 Oct 2017 14:45:01 +0100

My thoughts:

- Requiring an explicit action against the order after the fulfilment of
authorizations to cause issuance seems fine to me.

- I think moving the submission of the CSR to the end of this process is
a mistake.

The ACME protocol should permit CAs to implement policy as far as is
reasonably practicable with regard to the workflows around which the
protocol is organised. Providing the CSR up-front allows the CA to
predicate order processing on aspects of that CSR, both with regard to
the present protocol and any future extensions, both now and in the
future in ways that we can and cannot foresee. I don't think it's
appropriate to defer giving critical information to the CA until the
last minute due to a resource utilisation concern which LE has already
proven capable of dealing with, especially when the whole point of the
order flow in the first place was to provide more flexibility for CAs to
institute policy.

A possible compromise would be to require the CSR to be submitted both
on new-order and on finalization, but that's quite clumsy.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Oct 2017 17:17:32 +0300

> order flow in the first place was to provide more flexibility for CAs to

Example: Suppose that CAA-PKP got added (restrict issuance on SPKI
key). Implementing that without knowing the public key at validation
time is annoying.

As to why one would want something like that, it would allow limiting
trust on certficiate management system without deploying something as
dangerous as HPKP.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 28 Oct 2017 13:25:35 +0300

> trust on certficiate management system without deploying something as

Specifically, this would be a top-level CAA property that is satisfied
by certificate request having SubjectPublicKeyInfo matching at least
one of the listed hashes.

The contents of property consist of one or more hash=hasval pairs,
where hash is a hash function (unknown ones are ignored) and hashval is
base64-encoded hash of the SPKI.

There is no max-age, as the restriction is not sticky and thus can be
replaced quickly if needed. It can be signed using DNSSEC as usual.

Example:

foo.example.net IN CAA 128 pin "sha256=AIPH49+A9F1e650YMzRPJG9OkBA0F24Mwa5ru5ZmsCo=,sha256=FmbTUrJD2lBK8H501MKenwkFg+639r/x6eZp22qUd/I="

This property is satisfied only by requests containing
SubjectPublicKeyInfo key with either SHA-256 hash of

0083c7e3df80f45d5eeb9d1833344f246f4e901034176e0cc1ae6bbb9666b02a or
1666d352b243da504af07e74d4c29e9f090583eeb7f6bff1e9e669db6a9477f2.

The usecase is as follows:

Suppose certificate management system runs with the least authority.
If it  gets compromised, the attacker can not aquire the private keys.
However, he can abuse its authority to solve challenges for his own
keypairs. The end result is attacker getting  maliscous certificates
he controls the private key for. The account keypair does not help,
since it can be abused too.

However, if the public keys one can get certificates are restricted,
the attacker can not aquire useful certificates, as he can not
specify his own keypairs for the certifciate, nor get the private key
for any of the whitelisted keypairs.

Similar attacks could be also mounted on some other least-authority
components of the whole system, components that could be at even
higher risk of compromise.

The current solution to this usecase is the HPKP. However, HPKP is
known to be difficult to deploy, quite of a footgun and worst of all
is being deprecated. Expect-CT will not even begin to solve it. A
partial solution would be to use CAA to restrict issuance to CAs that
either do not support automation, or support "vanity CAAs" with
corresponding restrictions.

-Ilari

---

From: Daniel McCarney <[email-masked]>
Date: Mon, 30 Oct 2017 10:13:33 -0400

Hi Hugo,

Providing the CSR up-front allows the CA to predicate order processing on
> aspects of that CSR, both with regard to the present protocol and any
> future extensions, both now and in the future in ways that we can and
> cannot foresee. I don't think it's appropriate to defer giving critical
> information to the CA until the last minute due to a resource utilisation
> concern which LE has already proven capable of dealing with

The open-ended policy accommodations you mention sound nice in theory but
at the start of this thread I offered concrete cases that suffer as a
result of this decision and I would like to see concrete use-cases used as
counter argument. Are there any CAs that have expressed interest in policy
decisions based on the CSR? If so, can they please explain in concrete
terms how they would *not* be able to do so with the CSR submitted at
finalization time?

This thread was specifically started because the LE implementation showed
that the current design would pose considerable problems with resource
utilization. I don't think it's appropriate to assume that in contradiction
to that direct experience it will be a problem LE is capable of dealing
with without more concrete suggestions as to how.

- cpu

---

From: Daniel McCarney <[email-masked]>
Date: Mon, 30 Oct 2017 10:15:56 -0400

> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key).
Implementing that without knowing the public key at validation time is
annoying.

Can you expand on "annoying"?

It seems completely possible to reject the order finalization message based
on a CAA-PKP property. In-fact, we already have to be rechecking CAA for
authorizations validated more than 8 hours ago at the time of issuance so
there must be code in place to check CAA at finalization and clients must
be prepared for their order to be rejected at finalization based on CAA
already.

I don't see how this is any more annoying.

- cpu

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Oct 2017 15:33:46 -0400

On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney <[email-masked]>
wrote:

> It seems completely possible to reject the order finalization message
> based on a CAA-PKP property.
>

Wouldn't it be a lot better not to do the validations at all if you can
tell at new-order time that you're not going to be willing to issue?

> In-fact, we already have to be rechecking CAA for authorizations validated
> more than 8 hours ago at the time of issuance so there must be code in
> place to check CAA at finalization and clients must be prepared for their
> order to be rejected at finalization based on CAA already.
>
> On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara <
> [email-masked]> wrote:
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Daniel McCarney <[email-masked]>
Date: Mon, 30 Oct 2017 15:48:04 -0400

> tell at new-order time that you're not going to be willing to issue?

Yes, that would be better in this one capacity. However I don't think it
comes close to justify the scaling issues associated with accepting the CSR
up-front, and as mentioned, there are other reasons why validations may
occur for an order that the CA isn't willing to issue at the time of
finalization.

There also isn't a CAA-PKP so we're bikeshedding about impact on features
that are both unspecified & unimplemented.

- Daniel / cpu

On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes <[email-masked]> wrote:

>> In-fact, we already have to be rechecking CAA for authorizations
>> validated more than 8 hours ago at the time of issuance so there must be
>> code in place to check CAA at finalization and clients must be prepared for
>> their order to be rejected at finalization based on CAA already.
>>