Re: [Acme] Mail regarding craft of hash for draft-ietf-acme-dns-account-challenge

Amir Omidi <> Sat, 03 February 2024 21:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CB6DC14F68F for <>; Sat, 3 Feb 2024 13:18:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ay2xzi2AFpwI for <>; Sat, 3 Feb 2024 13:18:37 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id C5478C14F689 for <>; Sat, 3 Feb 2024 13:18:37 -0800 (PST)
Received: by with SMTP id a640c23a62f3a-a35e65df2d8so430346266b.0 for <>; Sat, 03 Feb 2024 13:18:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1706995116; x=1707599916;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4nXfXQFMNIeANFj/5dIW4CYhi8RljzWiqsWnkLWu/bQ=; b=AAhngzEWcynJwrl9Sd3h4LslWFzu2ukFbS3NL3QAQkFA0+e22rz3TrzeZhapskh5y3 z9StMHwbONxquc/00/oi3cXESqAsiChoOUZZCu1NjOeRhvbbXk24fN7NvkVAC0iJrOe4 XNa7lYLT+XlEvIUdEkCMl0/mm2NhUyns+N/gjkGxcZKy5HNQlKjX+yGHbbseo5LLLqKh i2Jvfv9pVi8Z65zPi5//uHQ/0g9bL/wGFKaYQ90EhN5KNR5YUpS12pwamU0fc4UafBuc Wl62Xr1EGqDo2AYONJpHpdnVwE4+DwMHcReow0WkRNPnz4YhIvx8klQW+I31qug4TzTU kIEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1706995116; x=1707599916; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4nXfXQFMNIeANFj/5dIW4CYhi8RljzWiqsWnkLWu/bQ=; b=WCZPVN9Xd23ygA8+24Wp/hSNnpLAiP97PErhEPdt61oNJ8uafI5kQDybu6Va3bPYy7 ursgXbAWnlIqIje5JobTS+u0A+TfluhmiEny910ksVRy9PCWzGNR9IXHvAVxIyDNg3Ww GN3HrjVc0/01bzNnUDeNCtkBCqHKPBu137n4721WJdCryuQlecF43ZI7Jt0btvsI8Fq5 eDhb3olobGDcaWKVXaPxZKy1b1kQmvM8M9CoxsMSOli2DIxcDOZilWr1Y0f03dQBvo8R ENd/XRfp5JxiDxZquM0JvJEaa1nXGa2DB7g0lNNaUGerMISK8aecec6eAQ6z+oXo1xHa OIWA==
X-Gm-Message-State: AOJu0YyDT8oe0rMMkCM3ZrpD6ad9p6uHJ2ySzxYDTEbht5cJUYFbwXOT C9HtPBx36l11DBleqwdkzCDmUvwMycbu425DKZIk4AjtAAvweTkKVmQQO4n+ZxCpkJKj7IdCMvc 3izz5O8l3YJYWS1Z2/p2FrAoSMYB03roMwwCEdcJFZsw5BlUJ
X-Google-Smtp-Source: AGHT+IGwkPtoJdEUIwp0sjF4i3Y2xYYhvu3KqsAzoV2W90nOQaTCaigxZ9SDEb/GW7fGvHsBP8FKG2Yi/+0iyranIJE=
X-Received: by 2002:a17:906:24cf:b0:a35:6667:b3ed with SMTP id f15-20020a17090624cf00b00a356667b3edmr4203479ejb.8.1706995115446; Sat, 03 Feb 2024 13:18:35 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Amir Omidi <>
Date: Sat, 03 Feb 2024 16:18:23 -0500
Message-ID: <>
To: Seo Suchan <>
Content-Type: multipart/alternative; boundary="0000000000007d6d75061080c522"
Archived-At: <>
Subject: Re: [Acme] Mail regarding craft of hash for draft-ietf-acme-dns-account-challenge
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Feb 2024 21:18:42 -0000

No, the accountURL/URI that new-account returns is the only authoritative
path. I'll make sure that it is spelled out in the RFC. If an acme client
has an account key, it can use the method described here: to find the
accountURL for that account.

Since ACME does not define "what the ID part of an accountURL is", I'm much
more inclined on just keeping the entire accountURL as the ID to be hashed
for the challenge label.

On Sat, Feb 3, 2024 at 3:59 AM Seo Suchan <> wrote:

> if it's stable but has multiple valid path (ex: and
> , would server need try for both subdomain and lookup
> every possible valid path?
> 2024-02-03 오전 1:35에 Amir Omidi 이(가) 쓴 글:
> From my understanding, under ACME we treat that entire accountURL as the
> userID. So I think that URL will need to be stable.
> On Fri, Feb 2, 2024 at 2:36 AM Seo Suchan <> wrote:
>> for some ACME servers they have multiple allowed acme endpoint domains,
>> and server doesn't know what domain name client used to access its API
>> duce don't have full accounturl that used to craft challenge subdomain:
>> like boulder (what Let's encrypt uses) allows to accessed from mulitple
>> path ex:
>> "accountURIPrefixes": [
>> "http://boulder.service.consul:4000/acme/reg/",
>> "http://boulder.service.consul:4001/acme/acct/"
>>          ]
>>   , and pebble and smallstep do not have host in config but allow any ip
>> or domain pointed to them and reflect them to create link to
>> account/order/ect
>> would only using userid part of accountURL (ExampleAccount) from
>> have problem? while it's
>> trivial to extract from hash to accounturl as accountID was
>> autoincrementing counter, but was there are so few large acme provider
>> it was trivial to make rainbow table anyway.
>> _______________________________________________
>> Acme mailing list