[DNSOP] Re: [Ext] Re: Working Group Last Call for draft-ietf-dnsop-rfc7958bis

[Paul Hoffman <[e-mail]>]

Thanks for the comments. Some are addressed in the revised draft coming out shortly. I have noted below only the ones that are not.

--Paul Hoffman


> On Jul 1, 2024, at 11:08, Peter Thomassen <[e-mail]> wrote:
> Section 2.2
> -----------
> 
> OLD
>   The Zone element in the TrustAnchor element states to which DNS zone
>   this container applies.  The root zone is indicated by a single
>   period (.) character without any quotation marks.
> 
> This is underspecified w.r.t. to format, for labels containing dots.
> 
> But, the whole document is about the root (it's even in the title), and I wonder why the Zone element is there in the first place.
> 
> Instead of fixing the Zone element format, why not just drop the whole Zone element?

The zone element is there in case someone other than the root operator wants to use the format. Dropping it might cause some current users of the format to fail, so we are leaving it in.

> OLD
>   The id attribute in the KeyDigest element is an opaque string that
>   identifies the hash.
> 
> Is the id attribute expected to be unique within the XML file?
> 
> If so, does this also apply if the same digest is re-published with an added validUntil attribute, or even published twice with different validity ranges?
> 
> Also, if two digests (of different hash type) are published for the same key, do those KeyDigests share an id?
> 
> This aspect uncovers a structural issue, because the public key is not really an attribute of the key digest; rather, they are in a 1:n relationship.
> 
> I am wondering if it would be better to move the PublicKey element out of the KeyDigest element, by allowing any number of them to be direct children of TrustAnchor, with the relevant key identified by its keytag and/or validFrom attribute. This would require the schema to be updated as follows:
> 
> start = element TrustAnchor {
>    attribute id { xsd:string },
>    attribute source { xsd:string },
>    element Zone { xsd:string },
> 
>    keydigest+
>    publickey*
> }
> 
> keydigest = element KeyDigest ...
> 
> publickey = element PublicKey {
>    attribute id { xsd:string },
>    attribute keytag { xsd:nonNegativeInteger { maxInclusive = "65535" } },  // or validFrom
>    xsd:base64Binary
> }
> 
> The uniqueness concern is simplest addressed by adding "uniquely within the XML file" or something.
> 
> Howeve, it's surprising then that two digests that relate to the same key have different IDs, and I think the structural change would be cleaner. (This would then require no two keys to be published for the root with the same keytag and/or validFrom).


The spec says it is "an opaque string". Your proposal is to extend that and make it unique. This could cause a serious problem in the future if IANA does not change the id string for some reason. We are leaving it as just opaque.

> Section 2.5
> -----------
> 
> For the still-valid key, even if it's just an example example, I suggest not to use any signing and digest algorithm that are no longer fully recommended by RFC 8624. (This applies to both algorithm 5 and digest type 1.)

Using type 1 means that the example will not wrap around in the text version of the eventual RFC (it will be fine in the HTML version). If people feel strongly about this, we can indeed update this later.

> Section 3.2
> -----------
> 
> Like John, I'm not sure about the CMS mechanism, but I don't feel strongly. Perhaps some more about bootstrapping that trust could be said, or declared out of scope? At least a link to something that talks about that CA would be useful.
> 
> OLD
>   If a system
>   retrieving the trust anchors trusts the CA that IANA uses for the
>   "data.iana.org" web server, HTTPS SHOULD be used instead of HTTP in
>   order to have assurance of data origin.
> 
> Does this really mean that if I don't trust the CA, then I should be using HTTP?

Yes.

> How does that make things any better?

It does not, but the text doesn't indicate that it makes anything better.