Registrars/IANA/Registries/Resellers ==> Parents or Parental Agents
Olafur On Mon, Nov 7, 2016 at 7:22 AM, Ondřej Surý <[email protected]> wrote: > And you can replace "registrars" with "IANA" and your > whole paragraph would still be correct. This is another > area that hinders deployment of "new" (ehm, ehm) algorithms. > > Cheers, > -- > Ondřej Surý -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:[email protected] https://nic.cz/ > -------------------------------------------- > > ----- Original Message ----- > > From: "George Michaelson" <[email protected]> > > To: "Dan York" <[email protected]> > > Cc: "dnsop" <[email protected]> > > Sent: Monday, 31 October, 2016 05:22:43 > > Subject: Re: [DNSOP] FYI - Added note about ECDSA resolver issue in > Sweden - Fwd: New Version Notification for > > draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt > > > It is only my personal opinion, but I believe registrars are incorrect > > in performing crypto alg checks on proffered DS, and this is an > > entirely unwarranted, and incorrect understanding of their role. It > > conflates one public good (checking) with another public good > > (registry of data into the DNS) and assumes one out-ranks the other: > > It doesn't, and the inability to track crypto alg change, makes the > > checking wrong. Its the lesser of two evils to stop checking, and > > permit unknown algorithms through. > > > > I think this needs to be flagged up. Either they should be told to > > stop, or the requirements for algorithm agility which their role > > places on them should be made explicit. > > > > -George > > > > On Mon, Oct 31, 2016 at 1:49 PM, Dan York <[email protected]> wrote: > >> FYI, I submitted a new version of this draft that added some text in the > >> section about "Resolvers" that mentions the case Mikael Abrahamsson > brought > >> to us about how they had to disable DNSSEC validation in the CPE they > >> deployed to their customers because the resolver software was not > following > >> RFC 4035 and was not ignoring signatures with unknown algorithms. > >> > >> Comments are of course welcome. > >> > >> For those who are interested in writing I-D's with markdown, I also > >> transitioned the source of this version of the document to the flavor of > >> markdown that works with Miek Gieben's 'mmark' processor. Paul Jones > nicely > >> packaged mmark and xml2rfc into a Docker container that works extremely > >> well. This document and other links can be found in my Github repo at: > >> https://github.com/danyork/draft-deploying-dnssec-crypto-algs > >> > >> Dan > >> > >> Begin forwarded message: > >> > >> From: <[email protected]> > >> Subject: New Version Notification for > >> draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt > >> Date: October 30, 2016 at 11:37:13 PM EDT > >> To: Ondrej Sury <[email protected]>, Olafur Gudmundsson > >> <[email protected]>, Dan York <[email protected]>, " [email protected] > " > >> <[email protected]>, Paul Wouters <[email protected]> > >> > >> > >> A new version of I-D, draft-york-dnsop-deploying- > dnssec-crypto-algs-02.txt > >> has been successfully submitted by Dan York and posted to the > >> IETF repository. > >> > >> Name: draft-york-dnsop-deploying-dnssec-crypto-algs > >> Revision: 02 > >> Title: Observations on Deploying New DNSSEC Cryptographic Algorithms > >> Document date: 2016-10-31 > >> Group: Individual Submission > >> Pages: 9 > >> URL: > >> https://www.ietf.org/internet-drafts/draft-york-dnsop- > deploying-dnssec-crypto-algs-02.txt > >> Status: > >> https://datatracker.ietf.org/doc/draft-york-dnsop- > deploying-dnssec-crypto-algs/ > >> Htmlized: > >> https://tools.ietf.org/html/draft-york-dnsop-deploying- > dnssec-crypto-algs-02 > >> Diff: > >> https://www.ietf.org/rfcdiff?url2=draft-york-dnsop- > deploying-dnssec-crypto-algs-02 > >> > >> Abstract: > >> As new cryptographic algorithms are developed for use in DNSSEC > >> signing and validation, this document captures the steps needed for > >> new algorithms to be deployed and enter general usage. The intent is > >> to ensure a common understanding of the typical deployment process > >> and potentially identify opportunities for improvement of operations. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> The IETF Secretariat > >> > >> > >> -- > >> Dan York > >> Senior Content Strategist, Internet Society > >> [email protected] +1-802-735-1624 > >> Jabber: [email protected] > >> Skype: danyork http://twitter.com/danyork > >> > >> http://www.internetsociety.org/ > >> > >> > >> > >> > >> > >> _______________________________________________ > >> DNSOP mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/dnsop > >> > > > > _______________________________________________ > > DNSOP mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
