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 <[email protected]> wrote: > On 8/4/16, 10:16, "DNSOP on behalf of Paul Hoffman" < > [email protected] on behalf of [email protected]> 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 <[email protected]> > To: Terry Manderson <[email protected]> > Cc: "[email protected]" <[email protected]>, "[email protected]" < > [email protected]>, Wes Hardaker <[email protected]>, " > [email protected]" <[email protected]>, " > [email protected]" < > [email protected]>, Spencer Dawkins at > IETF <[email protected]>, The IESG <[email protected]> > 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 <[email protected]> writes: > > > Hi Spencer, > > > > On 14/07/2016, 12:57 PM, "Spencer Dawkins at IETF" > > <[email protected]> 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 > [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
