Hello everyone, Please find my responses below:
> On 20 Oct 2022, at 21:11, Ilari Liusvaara <[email protected]> wrote: > > And some quick comments from quick read: > > > I suppose one is supposed to provision the base64url encoding of the > hashed key authorization as value of the TXT record (just like in > dns-01). However, I find that the text about what the value of the > TXT record is a bit confusing. The text that describes the value of the TXT record is taken as-is from RFC8555. We had a few people give us this feedback in the past, but it’s a bit difficult to make a good decision here: We felt that if we keep the exact same text, it would create less confusion and less ambiguity about the value users need to include. We thought that this is better than trying to redefine, using different words, the same thing. If however you want us to do this, we can update the text. An alternative, if the working group agrees, is to add something like “the value is calculated according to RFC8555” and avoid defining it altogether. What do you think? > I suppose that it would be more conventional to use label of > '_acme-challenge-*' instead of '_acme-challenge_*' (at least there > is precedent for former kind of name, specifically '_ta-*'). Also, > the name should be registered into 'Underscored and Globally Scoped > DNS Node Names' registry under 'Domain Name System (DNS) Parameters'. The main reason we used _ instead of - was to separate the fields better (visually). Since “acme-challenge” already contains a “-“ but it’s the same “part” of the label, we thought that _ would make it more clear that it’s two “fields” and not three. Indeed, _ta- is different though. We have no preference over the character used, we just thought that this would be easier to parse. If you believe that - is better than _, we can always update the text. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
