Re: [Acme] WGLC for ACME DTN Node ID

[Brian Sipos <[e-mail]>]

Ben,
Thank you for the feedback. Given that this document is earlier in the stream,
we still have opportunities to improve its encoded structure or properties.

> My recollection from the email+S/MIME document (which is to be published as
> an RFC imminently) is that the token-part2 was playing the role of a way to
> bind the authorization to the specific ACME order.  I also wanted to have a
> unique identifier that binds the challenge email to the ACME order, and
> that aspect changed a fair amount during the review process, but IIRC we
> ended up with a bit of a fudge where the ACME exchange includes the "From:"
> header field for the challenge email, and that could be unique to the order
> but isn't required to be.

Unfortunately in the case of bundles the source must be a fixed Node ID so we
don't have the option of a similar challenge-specific address. Is there any
value in having the ACME server use a unique-but-constant-per-order, and shown-
to-the-client, <token-part1> value?
Currently the distinguishing characteristic of <token-part1> is that it _only_
comes via bundle so knowing it means that you've seen the challenge bundle
(which an on-path attacker can do equally as well) but this avoids the
possibility of a response bundle being able to be produced before the challenge
bundle is even received.

Any value in a three-part nonce token (as recommended earlier, the names can be
changed to reflect the use) as defined here?
* Part 1 arrives only via challenge bundle, unique to that bundle (not just the
order).
* Part 2 arrives only via ACME HTTPS, unique to the order.
* Part 3 is indicated in both the ACME HTTPS and the challenge bundle and
provides a unique filter in the tuple of (Source Node ID, token-part3). This
would be similar to the randomized email address.

> That said, I have a (very vague, for which I apologize) recollection that
> earlier in the evolution of the TCPCLv4 document there was an option where
> certain TLS certificates would have an indication that the CA asserts that
> the holder of the private key is trusted to provide its Node ID in the
> TCPCL SESS_INIT even if the Node ID itself is not included in the
> certificate.  If that indication from the CA was the id-kp-bundleSecurity
> EKU, then requiring ACME to always include that EKU in the issued
> certificate would have surprising semantics.  That said, it looks like in
> at least the latest version of the TCPCLv4 draft, id-kp-bundleSecurity does
> not play that role, so there is no issue.  I'm only mentioning it now
> because the potential scope of consequences is so large, and I am sure that
> you will do the right thing (assuming I have been able to describe the
> situation I'm worried about clearly enough).

You are correct in your conclusion. The last recommended security policy (sent
to the RFC editor) is to require a proper Node ID SAN and ignore any other SANs
present. There is no recommended policy about implying the ownership/validity of
a Node ID.