On Thursday, July 21, 2011 9:36 AM Antoin Verschuren wrote: > On 21-07-11 14:15, Stephan Lagerholm wrote: > > > > I suggested to use another flag for the DNSKEY a few months ago here. > The > > reaction from the list was that it was too complicated because the > key-id > > would change during the lifetime of the DNSKEY. > > Why would you look at the key-id ? I wouldn't, but the feedback was that we shouldn't mess with the flag field of the DNSKEY, RFC5011 did that and it created a lot of confusion for operators because the key-id changes.
> If as a parent I get a notify, I (securely) look up the DNSKEY set, > select the keys with a SEP bit and hash them to DS. What does the key- > id do in that ? Nothing, but the SEP = DS doesn't work. Some zones (.NU) doesn't even have the SEP bit. > If the key-id changes during the DNSKEY lifetime, doesn't it mean the > DS at the parent should change too ? > Or do you mean there's a point in time you set the flag, and that > causes the key-id to change ? Yes, sure. But then I see that as a key change, > and you have to signal the parent anyway. The idea was to have an embryonic flag. For example, if the embryonic flag was in position 10 in the flag field (512): The child operator would publish a key with flag 769 (257 + 512) signaling the intention to soon add a DNSKEY with flag field 257. The parent would pick up the DNSKEY and create a DS but without including the embryonic flag in the DS calculation. The after the child sees the DS at the parent, it would remove the embryonic flag from the DNSKEY. During the lifetime of the key it would have different flag fields and different key-ids. 769 -> 257 -> 385 (if RFC5011 rollovers are used, the revoked bit could perhaps also be extended mean that the DS should be removed from the parent) /S
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
