Registrars/IANA/Registries/Resellers ==> Parents or Parental Agents
Olafur On Mon, Nov 7, 2016 at 7:22 AM, Ondřej Surý <ondrej.s...@nic.cz> 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:ondrej.s...@nic.cz https://nic.cz/ > -------------------------------------------- > > ----- Original Message ----- > > From: "George Michaelson" <g...@algebras.org> > > To: "Dan York" <y...@isoc.org> > > Cc: "dnsop" <dnsop@ietf.org> > > 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 <y...@isoc.org> 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: <internet-dra...@ietf.org> > >> 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 <ondrej.s...@nic.cz>, Olafur Gudmundsson > >> <olafur+i...@cloudflare.com>, Dan York <y...@isoc.org>, " y...@isoc.org > " > >> <y...@isoc.org>, Paul Wouters <pwout...@redhat.com> > >> > >> > >> 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 > >> y...@isoc.org +1-802-735-1624 > >> Jabber: y...@jabber.isoc.org > >> Skype: danyork http://twitter.com/danyork > >> > >> http://www.internetsociety.org/ > >> > >> > >> > >> > >> > >> _______________________________________________ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop > >> > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
