New Non-WG Mailing List: Lurk -- Limited Use of Remote Keys
IETF Secretariat <ietf-secretariat@ietf.org> Sat, 16 January 2016 00:54 UTC
Return-Path: <ietf-secretariat@ietf.org>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E38E1B34A0; Fri, 15 Jan 2016 16:54:44 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat <ietf-secretariat@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
Subject: New Non-WG Mailing List: Lurk -- Limited Use of Remote Keys
X-Test-IDTracker: no
X-IETF-IDTracker: 6.12.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160116005444.17735.40712.idtracker@ietfa.amsl.com>
Date: Fri, 15 Jan 2016 16:54:44 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf-announce/trXdJuSOdPLO8XPa4sKFrFf8Icc>
Cc: <>, stephen.farrell@cs.tcd.iedaniel.migault, lurk@ietf.org
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Jan 2016 00:54:44 -0000
A new IETF non-working group email list has been created. List address: lurk@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=lurk To subscribe: https://www.ietf.org/mailman/listinfo/lurk Purpose: Communication protocols like IPsec, SSH or TLS provide means to authenticate the remote peer. Authentication is based the proof of ownership of a private key. Currently most trust models assume the private key is associated and owned by the peer. In addition, the remote peer is both responsible of the hosted content and for the network delivery. Although these assumptions were largely true in the past, today, the deployment of service on the current Internet largely relies on multiple distributed instances of the service. Similarly, the delivery of popular content often splits the roles of providing the content and delivering the content. In such architectures, the application, - like a web browser - expects to authenticate a content provider while authenticating the node delivering the content. In this case, the confusion mostly results from using a secure transport layer to authenticate application layer content. There may be a BoF at IETF95 to discuss this topic. For additional information, please contact the list administrators.
- New Non-WG Mailing List: Lurk -- Limited Use of R… IETF Secretariat