On Aug 9, 2024, at 12:16, Michael StJohns <m...@nthpermutation.com> wrote:
>
> 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.
This is unchanged from RFC 7958, published in 2016. It was done for the key
rollover to KSK-2017. If you propose to change this activity now, I propose
that you take this to IANA; the current draft and RFC 7958 reflect IANA's
long-established policies.
> Looking at the Security Considerations - I don't think the updates to this
> section made this is sufficiently evident.
That's because this part of RFC 7958 was not updated in this draft.
> 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.
The latter is a suggestion to IANA.
> 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.
Section 2.2 of RFC 4034 says "The Flag field MUST be represented as an unsigned
decimal integer."
> 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.
That would then be different than the KeyType, Algorithm, and DigestType fields
that are expressed as xsd:nonNegativeInteger. If the WG wants to make this
inconsistent, it can, but I would generally be against that.
--Paul Hoffman
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
