[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

[Michael StJohns <[e-mail]>]

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 <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]