Hi Libor, Mark,
Thanks both for the feedback!
On 18/07/2024 10:47, libor.peltan wrote:
My point was that
example.com. IN DS49172 13 130
e2c8c32fb3c40586e0dabc367bfde4368b8dff52a7ffc60f619c720ec7767320
example.com. IN DS49172 13 2
e2c8c32fb3c40586e0dabc367bfde4368b8dff52a7ffc60f619c720ec7767320
is more equivalent (i.e. the change from the first to the second looks
safer and more straightforward) than
example.com. IN DS49172 13 7
02e2c8c32fb3c40586e0dabc367bfde4368b8dff52a7ffc60f619c720ec7767320
example.com. IN DS49172 13 2
e2c8c32fb3c40586e0dabc367bfde4368b8dff52a7ffc60f619c720ec7767320
/Libor
Dne 18. 07. 24 v 10:27 Mark Andrews napsal(a):
It would look like a regular DS. The only difference would be that the first
byte of the digest would contain the sub type. This is just internal
structure of the digest.
We did consider both options:
- single dry-run algorithm with the real algorithm as part of the digest;
- multiple dry-run algorithms by burning a bit.
and they were both part of the 01 version.
Based on feedback from the IETF114 era
(https://datatracker.ietf.org/doc/html/draft-yorgos-dnsop-dry-run-dnssec-02#name-feedback-from-ietf-114-3)
the burning a bit way was selected.
The deciding factor was that burning a bit was the only disadvantage of
the "burning a bit" option. Halving a not so much populated space with
little prospect of exploding anytime soon as noted in the feedback.
On the other hand, variable length did find some opposition wrt EPP
constrains.
And I do agree with Libor that as close the dry-run DS resembles the
real DS the better.
Swapping the dry-run DS with the real DS is the turn-key action that
should be made confidently.
Best regards,
-- Yorgos
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
