Re: [DNSOP] Definitions of basic DNSSEC terms

"Paul Hoffman" <paul.hoffman@vpnc.org> Thu, 11 August 2016 00:54 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF0312D808 for <dnsop@ietfa.amsl.com>; Wed, 10 Aug 2016 17:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWWzfApfqZtT for <dnsop@ietfa.amsl.com>; Wed, 10 Aug 2016 17:54:13 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412AA12D114 for <dnsop@ietf.org>; Wed, 10 Aug 2016 17:54:12 -0700 (PDT)
Received: from [10.32.60.150] (50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u7B0s5NZ007096 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Aug 2016 17:54:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193] claimed to be [10.32.60.150]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Tony Finch <dot@dotat.at>
Date: Wed, 10 Aug 2016 17:54:05 -0700
Message-ID: <F7C7044C-D980-405B-A509-5749107219E9@vpnc.org>
In-Reply-To: <alpine.DEB.2.11.1608091204220.14870@grey.csi.cam.ac.uk>
References: <29ED2792-2055-45DC-9715-1D576D96DC23@vpnc.org> <C85EB98D-91A1-4857-BAE2-F12905F64800@icann.org> <alpine.DEB.2.11.1608091204220.14870@grey.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hbMvT0yc6oDb19mjiI_FQs6t794>
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] Definitions of basic DNSSEC terms
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Aug 2016 00:54:14 -0000


On 9 Aug 2016, at 4:05, Tony Finch 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?
>
> RFC 4949 - Internet Security Glossary

I looked there, but the terms don't fit well for DNSSEC. If there are 
bits below that we can pick out, great, but it seems like a stretch.

--Paul Hoffman

    $ validate
       1. (I) Establish the soundness or correctness of a construct.
       Example: certificate validation. (See: validate vs. verify.)

       2. (I) To officially approve something, sometimes in relation to 
a
       standard. Example: NIST validates cryptographic modules for
       conformance with [FP140].

    $ authenticate
       (I) Verify (i.e., establish the truth of) an attribute value
       claimed by or for a system entity or system resource. (See:
       authentication, validate vs. verify, "relationship between data
       integrity service and authentication services" under "data
       integrity service".)

       Deprecated Usage: In general English usage, this term is used 
with
       the meaning "to prove genuine" (e.g., an art expert authenticates
       a Michelangelo painting); but IDOCs should restrict usage as
       follows:
       -  IDOCs SHOULD NOT use this term to refer to proving or checking
          that data has not been changed, destroyed, or lost in an
          unauthorized or accidental manner. Instead, use "verify".
       -  IDOCs SHOULD NOT use this term to refer to proving the truth 
or
          accuracy of a fact or value such as a digital signature.
          Instead, use "verify".
       -  IDOCs SHOULD NOT use this term to refer to establishing the
          soundness or correctness of a construct, such as a digital
          certificate. Instead, use "validate".

    $ authentication
       (I) The process of verifying a claim that a system entity or
       system resource has a certain attribute value. (See: attribute,
       authenticate, authentication exchange, authentication 
information,
       credential, data origin authentication, peer entity
       authentication, "relationship between data integrity service and
       authentication services" under "data integrity service", simple
       authentication, strong authentication, verification, X.509.)

    $ verification
       1. (I) /authentication/ The process of examining information to
       establish the truth of a claimed fact or value. (See: validate 
vs.
       verify, verify. Compare: authentication.)

       2. (N) /COMPUSEC/ The process of comparing two levels of system
       specification for proper correspondence, such as comparing a
       security model with a top-level specification, a top-level
       specification with source code, or source code with object code.
       [NCS04]

    $ verify
       (I) To test or prove the truth or accuracy of a fact or value.
       (See: validate vs. verify, verification. Compare: authenticate.)