Hi Warren,
Thanks for your suggestion, it is something that we may considering including in the script section relating to key generation.
Anyway, the current software that is used to generate keys (kskgen) ensure the use of a unique random label of the newly generated key.
https://github.com/iana-org/dnssec-keytools/blob/master/ kskgen/kskgen.c
Thanks,
--
Andres Pavez
Cryptographic Key Manager
On 2/14/18, 12:41, "ksk-rollover on behalf of Warren Kumari" <ksk-rollover-bounces@icann.org on behalf of warren@kumari.net> wrote:
Apologies if this isn't the right place to propose this - the
ksk-ceremony list didn't feel right...
I think that it would be a useful addition to the script to ensure
that, when a new KSK is generated, it does not have the same Key ID as
any previous KSKs. It is *does* have the same Key ID, it should be
discarded and a new one generated.
Rational: If we end up with multiple keys with the same Key ID it
becomes very tricky to run things like RFC8145, KSK Sentinel, etc.
Also, when doing troubleshooting / diagnostics, the key ID is an easy
thing to use to differentiate keys.
This has long been source of low level concern for me, and I've been
assured that if there were collisions during the ceremony, the right
thing would likely happen -- but I think that this is worth explicitly
noting what happens.
I *did* look at the scripts, and didn't see a note on this; 'pologies
if it is already covered and I missed it.
W
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
_______________________________________________
ksk-rollover mailing list
ksk-rollover@icann.org
https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________
ksk-rollover mailing list
ksk-rollover@icann.org
https://mm.icann.org/mailman/listinfo/ksk-rollover