[Acme] Re: I-D Action: draft-ietf-acme-dns-persist-01.txt

[Shiloh Heurich <[e-mail]>]

On Apr 4, 2026, at 01:17, Seo Suchan <[e-mail]> wrote:
> 
> accounturi in 3.1 challenge object need to be arrays of string not a single string to be used to be able to give any alternative uris: currently there is only one choice for client. to actually able to hide record we'd need something per domain name: hmac that uses account publickey as shared key and domain name as message?

I think this raises two distinct questions:

1. Does the challenge object need to carry multiple acceptable `accounturi` values?
2. Does the current alternative-URI text provide meaningful privacy?

My reading is that an array is not necessary if the intended model is that the CA tells the client the single `accounturi` value it expects in DNS for that validation attempt. That value could be either the canonical ACME account URL or a CA-issued opaque alias for the same account. In this model the client does not need a choice; it just uses the value from the challenge.

I agree that the draft is not clear enough on this today. The current text about the client verifying that an alternative URI "identifies the same account" is confusing. If the CA provides an opaque alternative URI, the client generally cannot verify that mapping independently and has to rely on the challenge object.

On the privacy point, I think the right approach is for the CA to issue distinct opaque aliases per validation domain name, or per small group of domains, rather than reusing one visible identifier everywhere. That avoids cross-domain correlation without needing to change `accounturi` to an array.

I do not think an HMAC construction using the account public key is the right primitive here. HMAC requires a secret key, and the account public key is public. If a CA wants deterministic per-domain aliases internally, that is better treated as a CA implementation detail using CA-held secret material, not something the client derives.

My preference would be to:
- keep `accounturi` as a single string,
- clarify that it is the specific value the CA expects for that validation attempt,
- clarify that privacy-preserving alternatives may be per-domain opaque aliases, and
- clarify that pre-provisioning without a challenge uses the canonical account URL unless the CA provides alternatives (e.g. out of band).

If there is a concrete case where the client needs to choose among multiple simultaneously valid identifiers, then an array may be worth considering. For now, this seems more like a clarity problem than a field-shape problem.

Shiloh