> On Jan 15, 2020, at 10:25 AM, Brian Dickson <brian.peter.dick...@gmail.com> > wrote: > > However, there is a Heisenberg problem, which is that any other digest type > needs to be excluded from the ZONEMD calculation (and vice versa). > > So, from the future-proofing standpoint, I think one of the two methods needs > to be picked (I think RRTYPE is fine), and a range of types needs to be > reserved for future zone digests. > > I'd suggest small range (i.e. more than 1, maybe 4), and include the > reservation in this document with IANA instructions to that effect. > > The exclusion of that reserved future-use digest range should be baked into > the ZONEMD calculation itself, so future digests don't require an update to > ZONEMD, and don't result in incompatible deployed digest implementations. > (In other words, future-proof ZONEMD itself.) >
Brian, That could work, but I'm not sure it's required. You're saying that N types could be defined now (ZONEMD1, ZONEMD2, ...) and that the inclusion/exclusion rules say to just exclude any of these ZONMEDn types when calculating the digests. [Note that in the current draft ZONMED excludes only part of itself -- the digest value. It includes the other fields such as serial. In other words the exclusion is RR-format-aware. For the not-yet-defined types you'd probably have to say to exclude the whole RDATA.] But I think it could be made to work if you define the order of digest calculation. The newest digest type would always be calculated first. For example ZONEMD3 would be defined to digest the whole zone except for ZONEMD2 and ZONEMD1 (and their signatures). ZONEMD2 would include ZONEMD3 in its digest, but not ZONEMD1. And ZONEMD1 would include all the later types because it didn't know about them when it was written. I think that would work, but sounds kinda complicated. Lastly, another, simpler option would be to say that only one digest RR type is allowed in the zone at a time. Including both ZONEMD1 and ZONEMD2 is an error and cannot be verified. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
