Re: [DNSOP] Definitions of basic DNSSEC terms

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.lewis@icann.org> wrote:

> On 8/4/16, 10:16, "DNSOP on behalf of Paul Hoffman" <
> dnsop-bounces@ietf.org on behalf of paul.hoffman@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 <wjhns1@hardakers.net>
> To: Terry Manderson <terry.manderson@icann.org>
> Cc: "tjw.ietf@gmail.com" <tjw.ietf@gmail.com>, "dnsop-chairs@ietf.org" <
> dnsop-chairs@ietf.org>, Wes Hardaker <wjhns1@hardakers.net>, "
> dnsop@ietf.org" <dnsop@ietf.org>, "
> draft-ietf-dnsop-dnssec-roadblock-avoidance@ietf.org" <
> draft-ietf-dnsop-dnssec-roadblock-avoidance@ietf.org>, Spencer Dawkins at
> IETF <spencerdawkins.ietf@gmail.com>, The IESG <iesg@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.manderson@icann.org> writes:
>
> > Hi Spencer,
> >
> > On 14/07/2016, 12:57 PM, "Spencer Dawkins at IETF"
> > <spencerdawkins.ietf@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
>
>