Re: [Ace] Terms to avoid
"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> Fri, 13 December 2013 12:14 UTC
Return-Path: <Hannes.Tschofenig@gmx.net>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCB01A1F7D for <ace@ietfa.amsl.com>; Fri, 13 Dec 2013 04:14:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.177
X-Spam-Level:
X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 e5CsUAXqElZW for <ace@ietfa.amsl.com>; Fri, 13 Dec 2013 04:14:50 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 370161A1F5E for <ace@ietf.org>; Fri, 13 Dec 2013 04:14:50 -0800 (PST)
Received: from 3capp-gmx-bs24.server.lan ([172.19.170.76]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LbfGf-1V6n960Q15-00lEb3 for <ace@ietf.org>; Fri, 13 Dec 2013 13:14:43 +0100
Received: from [217.140.96.21] by 3capp-gmx-bs24.server.lan with HTTP; Fri Dec 13 13:14:43 CET 2013
MIME-Version: 1.0
Message-ID: <trinity-9d582751-d593-4ef3-a062-e03bdf2a63de-1386936882917@3capp-gmx-bs24>
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: sarikaya@ieee.org
Content-Type: text/html; charset="UTF-8"
Date: Fri, 13 Dec 2013 13:14:43 +0100
Importance: normal
Sensitivity: Normal
In-Reply-To: <CAC8QAcfbYjBrWO8pitHUYr=oq9WD6vkkjJ69vfiK+1oTjW7Uig@mail.gmail.com>
References: <trinity-8553dce2-e064-4ed4-8774-fe3a04fc2bb7-1386874286879@3capp-gmx-bs21> <B9A7B5DA-ED8E-4507-8424-FC093C029D19@tzi.org>, <CAC8QAcfbYjBrWO8pitHUYr=oq9WD6vkkjJ69vfiK+1oTjW7Uig@mail.gmail.com>
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K0:mnz5SbTIKDFzLxCt8Bo2EYqCsv6+/q/gWUd4bHbaS2Q Bxk4skTw3t4rayD4gHlKPUDcy3lth08LDEX77cZTeDBHXqjA31 cINUOToiEdkWdC1tjZVewStBNGZQONMAho8vzo7LyfqAHzHNgo qTiDdqgSR27E1YpfkUJOiVQkj+dSjF/N/iAuc0OnBNvUtQ6Fhv A3BdQGFsP1JN/jxo2bx7dT44IPtXCDX4osUZxOUE1fyjPM5ori RUmS+a1/65gnL+BDFDADPWLvkkLki0U4sgaXaIIfI8VIaWr/jS gv6TmI=
Cc: Carsten Bormann <cabo@tzi.org>, ace@ietf.org
Subject: Re: [Ace] Terms to avoid
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2013 12:14:53 -0000
More specifically, it relates to achieving the transition from a sparse or minimal, pre-operational set of authenticated authorizations to a set that can be used operationally."
Von: "Behcet Sarikaya" <sarikaya2012@gmail.com>
An: "Carsten Bormann" <cabo@tzi.org>
Cc: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>, ace@ietf.org
Betreff: Re: [Ace] Terms to avoid
On 12 Dec 2013, at 19:51, Hannes Tschofenig <Hannes.Tschofenig@gmx.net" target="_parent" rel="nofollow">Hannes.Tschofenig@gmx.net> wrote:I completely agree about the term “Trust”. This is neither an objective nor a method.
> Could you guys do me a favor and avoid two terms in your drafts:
>
> 1) Bootstrapping
> 2) Trust
When people talk about “trust” they usually either talk about the ability to authenticate something and/or an authorization relationship, but it is rarely fully fleshed out what specifically is meant.
(Some, but not all, of the uses of the term “certificate” are of the same kind.)
Device B doesn’t “trust” device A, but device A is authorized to perform certain, well-defined operations on or relevant for device B, and that authorization (as well as the origin of the operation and/or communication channels) can be authenticated in the course of performing the operation.
I don’t agree about not using bootstrapping. Bootstrapping is not a method, it is an objective, which can be pinpointed pretty precisely in the lifecycle of a device.
More specifically, it relates to achieving the transition from a sparse or minimal, pre-operational set of authenticated authorizations to a set that can be used operationally.
(Key establishment is usually part of what needs to be done there, but the keys just serve to authenticate the authorizations, so I’m not even sure they are very important for defining bootstrapping.)
I’m sorry for this dense terminology attack, but I agree that we need to work on some of the terminology now to generate a credible charter.
Grüße, Carsten
_______________________________________________
Ace mailing list
Ace@ietf.org" target="_parent" rel="nofollow">Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/ace
- [Ace] Terms to avoid Hannes Tschofenig
- Re: [Ace] Terms to avoid Behcet Sarikaya
- Re: [Ace] Terms to avoid Akyol, Bora A
- Re: [Ace] Terms to avoid Carsten Bormann
- Re: [Ace] Terms to avoid Behcet Sarikaya
- Re: [Ace] Terms to avoid Likepeng
- Re: [Ace] Terms to avoid Ludwig Seitz
- Re: [Ace] Terms to avoid Carsten Bormann
- Re: [Ace] Terms to avoid Hannes Tschofenig
- Re: [Ace] Terms to avoid Stefanie Gerdes
- Re: [Ace] Terms to avoid Carsten Bormann
- Re: [Ace] Terms to avoid Hannes Tschofenig
- Re: [Ace] Terms to avoid Göran Selander
- Re: [Ace] Terms to avoid Michael Richardson
- Re: [Ace] Terms to avoid Likepeng
- Re: [Ace] Terms to avoid Ludwig Seitz
- Re: [Ace] Terms to avoid Carsten Bormann
- Re: [Ace] Terms to avoid Hannes Tschofenig
- Re: [Ace] Terms to avoid Likepeng
- Re: [Ace] Terms to avoid Carsten Bormann
- Re: [Ace] Terms to avoid Ludwig Seitz
- Re: [Ace] Terms to avoid Likepeng