Re: [Acme] WGLC for ACME DTN Node ID

[Ryan Sleevi <[e-mail]>]

With admittedly very little context for this specific use case, a few
things stand out:

Section 2 states "Any identifier of type "uri" in a newOrder request MUST
NOT have a wildcard ("*") character in its value." This seems to
unnecessarily constrain the character space. While I suspect the purpose
was to exclude wildcards from the authority-part of a generic URI/specific
to a particular scheme, it ends up defining the semantics for all URIs.
Given URI's well-known ambiguity in representation across implementations,
and the ability to do things like include pct-encoded characters in
reg-name (it's only a must requirement, not a MUST requirement), this both
seems unnecessarily restrictive and fails to achieve the goal, especially
since such decoding to prevent this scenario, at the ACME server, is SHALL
NOT'd by the same section.

If the goal is to prevent wildcards that imply certain semantics for a
given scheme (e.g. "dtn:"), then that probably deserves a separate section
detailing the requirements for the extraction and validation of the Node ID
from the URI, and can define any restrictions on the character namespace.

Alternatively, since identifier labels are cheap, making the identifier
type a dtn-uri (rather than the acknowledge-generic URI) seems like a way
to impose requirements specific to DTN URIs without risk of overfitting for
other types of URIs.

Section 3 describes how this cribs from ietf-acme-email-smime, but provides
no clear explanation as to the _why_, only the _how_. For example, the
statement "requires that the ACME client have access to the results of each
channel to get both parts of the token" describes a result, but does not
describe the motivation that necessitates such a design. This seems like it
might be relevant for security considerations, but documenting the
rationale for this design seems relevant to successfully and securely
implementing/extending this spec. This becomes equally relevant when
attempting to understand why the choice of 128-bits of entropy within
Section 3.1, since it seems the choice in the size of the parts is equally
related to this undocumented threat.

In Section 3.1, I'm probably just not familiar enough with the underlying
specs, but as far as I could tell, it's not clear why Step 3 the ACME
client needs to indicate the <token-part2> to the BP agent, versus just the
source. The source Node ID is clear, at least, but it seems like, at best,
<token-part2> might just be serving as a "request ID" of sorts (judging by
3.4)

The reason I highlight this is because I think it diverges from some of the
classic assumptions about ACME and challenge design, because it seems to
suggest that <token-part2> may transit the network in the clear and/or be
held by multiple parties, which is a very different model than the history
of ACME's DNS/TLS challenges being tied to the CA/Browser Forum's Request
Token (which not simply a random value, but uniquely bound to the original
request and is single-use). I *think* this might just be a terminology
issue here, but would it make sense to name these according to their
structural purpose, rather than just "token-part1" / "token-part2"?

In Section 3.3, it's stated "The ACME server SHOULD NOT perform URI
normalization on the Node ID given by the ACME client.". It seems like this
deserves its own section within Security Considerations, because as with
the above remarks, when, where, and how URI normalization is performed
seems like it has significant security impact. Even if this protocol uses
unnormalized URIs throughout the entire protocol, if implemented on top of
anything that performs normalization, or the certificates that are issued
are used by clients that perform normalization, you can end up with
ambiguities / confused deputies. Normally in a security protocol you would
want to validate and normalize your 'hostile' inputs as early as possible
in this flow, and that's one of the key roles of the ACME Server / CA, so
that it uses identifiers that are post-normalized/unambiguous. This seems
like a major oversight, but it could be that I'm misunderstanding something
specific to DTN.

Section 3.3 states "BP agents SHALL refuse to respond to a Challenge Bundle
which is signed by a known ACME server but has an invalid signature.". It
seems like this also deserves a note within the Security Considerations,
both in terms of how BP agents/ACME clients should determine whether an
ACME server is "known" and how they can successfully determine an invalid
signature (i.e. how to maintain the expected signing keys). This might
merely be a spec reference to DTN, but this normative language appears to
be trying to mitigate an undocumented security threat.

I agree with Russ' comments on Section 4 where the EKU MUST be included in
the issued certificate. Related, the profile from that Section 4.4.2 seems
problematic for implementation (around keyUsage), but alas, that's a whole
other issue for a whole other spec :)

Section 6.1 feels unnecessarily light for explaining why it's not a
concern. It feels like a bit of a handwave, rather than a statement of how
the conclusions are reached. If I'm correctly understanding, the reason
you're saying both the challenge and response are fine to be publicly known
is that they can only be used in conjunction with the ACME account
performing the challenge, which relies on a private key which is not
communicated. Is that right? It doesn't seem like that provides much
assurance, for the reasons detailed in Section 6.2