On Mar 5, 2013, at 5:25 AM, Antoin Verschuren <[email protected]> wrote:
>
>> So, to clarify, can the operator of a child zone who prefers to use
>> an algorithm 14 DNSKEY send you that key, confident that you will
>> accept it? What about algorithm 253?
>
> No.
> If the child prefers to use an experimental algorithm as a SEP for it's
> own experiment, he can happily enter that into his DNSKEY RRset. And he
> can generate or accept DSes for all the children under that zone that
> want to experiment with that algorithm in that tree. The chain of
> trust for that experiment starts at that subtree.
>
> But we don't accept that algorithm for the delegation in our chain of
> trust that starts at the root until that algorithm is widely deployed in
> the validating resolvers we serve. That's our local policy.
> We do DNSSEC because we want all end users be able to validate the
> delegations we make.
So for clarity if a .NL domain tries to set a DS set like this you will reject
it?
DS 12345 8 3 ……
But will you accept
DS 12345 8 2 …..
DS 12345 8 3 …..
?
i.e. the child has both SHA256 and the other algorithms
Second question:
DO you accept
DS 12345 14 2 ……
(ECDSA p384)
In all he cases above the validator can see when it gets the DS record if it
supports the
algorithms in question it can treat the zone as validatable or unsigned.
This is the same in my mind if a web site is only published in Dutch then it
limits its potential
readership to Dutch readers, if I sign my zone with ECDSA I limit my validators
to only the latest and
greatest validators)
>
….
>
> But our major motivation for "sending DNSKEY" is the secure DNS operator
> change I mentioned. This has not been implemented yet by these
> registries, so there's no real world experience with most of the
> registries that now only accept DS. Sending a key format for a DNS
> operator change, and a DS format for a delegation request makes matters
> complex for the child operators. That's why we accept key format for all.
But in this case you NEED the ZSK not the KSK
Olafur
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
