From b27ebeb2260bd3a8b6a6f1d78126541f8501d114 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Sat, 10 Feb 2024 01:55:00 +0000 Subject: [PATCH] Reference size limits --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 3385dd7..5bc1a80 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -293,7 +293,7 @@ To allow for seamless account key rollover without the label changing, the dynam In terms of the construction of the account label prepended to the domain name, there is no need for a cryptographic hash. The goal is to simply create a long-lived and statistically distinct label of minimal size. SHA-256 was chosen due to its existing use in the `dns-01` challenge ({{!RFC8555, Section 8.1}}). -The first 10 bytes were picked as a tradeoff: the value needs to be short enough to not significantly impact DNS label length, long enough to provide sufficient probability of collision avoidance across ACME accounts, and just the right size to have Base32 require no padding. As the algorithm is used for a uniform distribution of inputs, and not for integrity, we do not consider the trimming a security issue. +The first 10 bytes were picked as a tradeoff: the value needs to be short enough to stay lower than the size limits for DNS ({{!RFC1035, Section 2.3.4}}), long enough to provide sufficient probability of collision avoidance across ACME accounts, and just the right size to have Base32 require no padding. As the algorithm is used for a uniform distribution of inputs, and not for integrity, we do not consider the trimming a security issue. # IANA Considerations