IETF Logo Mail Archive

Re: [Cfrg] Including "internal APIs" in CFRG security analysis

Carsten Bormann <cabo@tzi.org> Sun, 13 October 2019 19:40 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A02120024 for <cfrg@ietfa.amsl.com>; Sun, 13 Oct 2019 12:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 eRB4WOwcs27u for <cfrg@ietfa.amsl.com>; Sun, 13 Oct 2019 12:40:45 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4070C120013 for <cfrg@irtf.org>; Sun, 13 Oct 2019 12:40:45 -0700 (PDT)
Received: from client-0123.vpn.uni-bremen.de (client-0123.vpn.uni-bremen.de [134.102.107.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46rsVf6ybJzyZp; Sun, 13 Oct 2019 21:40:42 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <b71e7e79-82d7-af4f-a7c9-ff9ec0a51269@bu.edu>
Date: Sun, 13 Oct 2019 21:40:41 +0200
Cc: cfrg <cfrg@irtf.org>
X-Mao-Original-Outgoing-Id: 592688439.507143-4dd2a946cac9c0397ae1da6df745bd3a
Content-Transfer-Encoding: quoted-printable
Message-Id: <1EF23DAD-49AC-4D13-B037-F7E2F3BA2986@tzi.org>
References: <e9043999-6015-d010-b023-4cb784d4d7b9@bu.edu> <52084CD0-845A-41C0-B0ED-355A059A6037@tzi.org> <b71e7e79-82d7-af4f-a7c9-ff9ec0a51269@bu.edu>
To: "Canetti, Ran" <canetti@bu.edu>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/WOwXUvT3-4cnnTxjFmlzYUADFjE>
Subject: Re: [Cfrg] Including "internal APIs" in CFRG security analysis
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Oct 2019 19:40:48 -0000

On Oct 13, 2019, at 19:18, Canetti, Ran <canetti@bu.edu> wrote:
> 
> Not sure what a good term might be here. "security API" could have been good except that it's used already for something somewhat different.      Perhaps  "Semantic Interface"? 

Uri’s proposal “Abstract service interface” (ASI) works for me, at least for protocols that would enable the use of the 40-year-old protocol/service paradigm [1].  “Semantic interface” may be going into the area of semantics too much (RDF, anyone?), and this misses the aspect of abstraction (from the specific interface).

The next step for me would be to collect some considerations/examples for how a good ASI description looks like.

Grüße, Carsten

[1]: https://dl.acm.org/citation.cfm?id=2286038

v2.23.0 | Report a Bug | By Email