Hello!
In section 4 of draft-ietf-acme-scoped-dns-challenges-00, an example is
given about how to calculate the hash of the account resource URL.
The example gives this account URL: "https://example.com/acme/acct/";
According to the example, the result of the
"base32(SHA-256()[0:10])" operat
it was "https://example.com/acme/acct/ExampleAccount"; but looks like
autometic line change was in bad place
2024-03-16 오후 8:19에 Richard Körber 이(가) 쓴 글:
Hello!
In section 4 of draft-ietf-acme-scoped-dns-challenges-00, an example
is given about how to calculate the hash of the account resourc
Thank you! Yes, that fixed the problem.
Looking at the specs again, I should have figured it out myself.
Thanks, again!
it was "https://example.com/acme/acct/ExampleAccount"; but looks like
autometic line change was in bad place
2024-03-16 오후 8:19에 Richard Körber 이(가) 쓴 글:
Hello!
In sect
Thank you! I've made this PR to be consistent between the KIDs:
https://github.com/aaomidi/draft-ietf-acme-scoped-dns-challenges/pull/41
On Sat, Mar 16, 2024 at 8:31 AM Richard Körber
wrote:
> Thank you! Yes, that fixed the problem.
>
> Looking at the specs again, I should have figured it out my
reading it again I'm no longer sure we can say account label isn't
security perpose: entire point of this challange is those
account-specific hostname CNAMEed to some delegated dns server for acme
perpose (like https://github.com/joohoi/acme-dns). and when clients are
using 3rd part DNS hosting
Hmm, so to understand properly this would require a malicious DNS server
that the CNAME has been delegated to, actively trying to cause a hash
collision?
That's fair. Although I do think this problem can be mitigated by using CAA
with account binding? https://www.rfc-editor.org/rfc/rfc8657
I woul
