Two comments - one major and one very minor.
Major: I'm sorry for the late comment, but I didn't realize you were
planning on starting to provide prospective DS's for unpublished keys.
Telling people there's a new trust anchor, and that the live key matches
this file is one thing - easy enough for a relying party to match up a
few things and accept the TA update. Telling them there's an
unpublished key and "trust me, when you see it it will have this digest
and you should go ahead now and install it in your trust anchors" seems
to be a bit more risky.
Looking at the Security Considerations - I don't think the updates to
this section made this is sufficiently evident. I'd suggest two
things: 1) Talk about the above in the security considerations, and 2)
Place a disclaimer in the TA file with similar language about the
prospective key material.
Minor minor minor nit - feel free to ignore this:
The flags field for the DNSKEY is represented in most DNS presentation
modes as an unsigned decimal integer - but it's actually a bit field of
two bytes. The representation is used mostly because that's what a DNS
Zone File used (e.g. either Base64 or a decimal integer) for most
non-text fields. Unclear decimal should be used for XML.
It may make some sense here to use <xsd:hexBinary { length = 2 }/> is
the field type the appropriate mapping here - <Flag>0101</Flag> instead
of the decimal 257. Easier to see what bits have been set.
Later, Mike
On 8/9/2024 2:22 PM, Paul Hoffman wrote:
To everyone who reviewed draft-ietf-dnsop-rfc7958bis in WG Last Call: please
carefully review the diff. Based on a very good IETF Last Call review from Petr
Špaček, we had to make a significant technical change to the XML format, and we
want to be sure that it works for everyone. We also updated the example (of
course), and in doing so found a way to simplify the material around the
example.
All comments welcome (until my birthday, August 18).
--Paul Hoffman
On Aug 9, 2024, at 11:05, Warren Kumari <war...@kumari.net> wrote:
Dear DNSOP,
During the DNSDIR review of draft-ietf-dnsop-rfc7958bis-03, Petr Špaček
identified an issue: if you include the DNSKEY material you also need to
include the flags.
The authors have published a new version addressing these changes, as well as
addressing more minor comments received during IETF LC.
As this required a change to the XML syntax, I'd like to get the DNSOP WGs
review / feedback on these changes.
The IANA is eagerly awaiting this becoming a standard so that they can update
their trust anchor with the DNSKEY material - so, if you have any strong
objections to these changes, please let me know by end of day (anywhere!) on
Aug 18th
Latest version: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/
Diff from -03:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-rfc7958bis-03&url2=draft-ietf-dnsop-rfc7958bis-04&difftype=--html
Thanks,
W
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
