must be mass hallucination. My memory concurs with Ed on the history. If you MUST define authentication, validation, and verification, I would place them under, "local policy"
/W On Tue, Aug 9, 2016 at 3:55 AM, Edward Lewis <edward.le...@icann.org> wrote: > On 8/4/16, 10:16, "DNSOP on behalf of Paul Hoffman" < > dnsop-boun...@ietf.org on behalf of paul.hoff...@vpnc.org> wrote: > > Greetings again. There are six terms that are commonly used when we > talk > about DNSSEC: > - validation and validate > - authentication and authenticate > - verification and verify > Are they defined in any RFCs that we can use for the terminology-bis > document? As far as I can see (but I could be blinded), they are not > defined in RFC 403[3-5]. > > Suggestions? > > Writing based on possibly undocumented (read: oral) history, those terms > fell under the category of "local policy" in the earlier DNSSEC documents > (such as "Domain Name System Security Extensions" [RFC 2535]). > > When the first proof-of-concept DNSSEC validator was written there was a > definite and deterministic set of tests implemented but there was no > intention to codify that into an IETF document for a number of reasons. At > the time the documents had a goal of defining what was needed for > interoperability, as opposed to be prescriptive. And it wasn't clear that > local matters of what an instantiation would trust would necessarily be > significant to what another instantiation would choose. > > There once was a long thread on whether an authoritative server should > perform cryptographic checking of all loaded signature before adding in the > AD bit. Ultimately it was decided to not require that (because, for one, > load time was too long for large zones). Authenticated Data meant "the > server is happy with the data" and not that any level of computation > (signature checking) had been done. The result of this is in "Redefinition > of DNS Authenticated Data (AD) bit". > > > > > ---------- Forwarded message ---------- > From: Wes Hardaker <wjh...@hardakers.net> > To: Terry Manderson <terry.mander...@icann.org> > Cc: "tjw.i...@gmail.com" <tjw.i...@gmail.com>, "dnsop-cha...@ietf.org" < > dnsop-cha...@ietf.org>, Wes Hardaker <wjh...@hardakers.net>, " > dnsop@ietf.org" <dnsop@ietf.org>, " > draft-ietf-dnsop-dnssec-roadblock-avoida...@ietf.org" < > draft-ietf-dnsop-dnssec-roadblock-avoida...@ietf.org>, Spencer Dawkins at > IETF <spencerdawkins.i...@gmail.com>, The IESG <i...@ietf.org> > Date: Wed, 3 Aug 2016 15:53:08 -0700 > Subject: Re: [DNSOP] Terry Manderson's Discuss on > draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT) > Terry Manderson <terry.mander...@icann.org> writes: > > > Hi Spencer, > > > > On 14/07/2016, 12:57 PM, "Spencer Dawkins at IETF" > > <spencerdawkins.i...@gmail.com> wrote: > >> > >>Terry, I like where you're headed, but just to ask the obvious question, > >>are you thinking the draft would, or would not, also contain something > >>like "at the time this document was approved, a domain used for this test > >>was $someactualworkingdomain.com <http://someactualworkingdomain.com>"? > > > > Sorry I didn't make it obvious, yes I would like to see text like this, > > and I think it makes an easy path for the less adventurous in addition to > > supplying more in depth guidance. > > How does this text work to be dropped into the end of the > "Implementation experiences" section (1.3): > > <section title="Test Zone Implementation"> > <t>In this document, the "test.example.com" domain is > used to refer to DNS records which contain test records > that have known DNSSEC properties associated with them. > For example, the "badsign-a.test.example.com" domain is > used below to refer to a DNS A record where the > signatures published for it are invalid (i.e., they are > "bad signatures" that should cause a validation > failure).</t> > > <t>At the time of this publication, the > "test.dnssec-tools.org" domain implements all of these > test records. Thus, it may be possible to replace > "test.example.com" in this document with > "test.dnssec-tools.org" when performing real-world > tests.</t> > </section> > > And then everywhere that test.dnssec-tools.org exists in the document, > I'll replace it with "test.example.com". > -- > Wes Hardaker > Parsons > > _______________________________________________ > 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
