[Anima] FW: New Version Notification for draft-fries-anima-brski-async-enroll-00.txt

"Fries, Steffen" <steffen.fries@siemens.com> Mon, 11 March 2019 10:02 UTC

Return-Path: <steffen.fries@siemens.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512C4130DE6 for <anima@ietfa.amsl.com>; Mon, 11 Mar 2019 03:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 8qj-eIu4lxMO for <anima@ietfa.amsl.com>; Mon, 11 Mar 2019 03:02:14 -0700 (PDT)
Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (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 458E51277E7 for <anima@ietf.org>; Mon, 11 Mar 2019 03:02:14 -0700 (PDT)
Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id x2BA2Abw020316 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <anima@ietf.org>; Mon, 11 Mar 2019 11:02:11 +0100
Received: from DEFTHW99ERMMSX.ww902.siemens.net (defthw99ermmsx.ww902.siemens.net [139.22.70.142]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id x2BA2ACS029000 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <anima@ietf.org>; Mon, 11 Mar 2019 11:02:10 +0100
Received: from DENBGAT9ERPMSX.ww902.siemens.net (139.22.70.194) by DEFTHW99ERMMSX.ww902.siemens.net (139.22.70.142) with Microsoft SMTP Server (TLS) id 14.3.435.0; Mon, 11 Mar 2019 11:02:10 +0100
Received: from DENBGAT9EJ5MSX.ww902.siemens.net ([169.254.12.162]) by DENBGAT9ERPMSX.ww902.siemens.net ([139.22.70.194]) with mapi id 14.03.0435.000; Mon, 11 Mar 2019 11:02:09 +0100
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: "anima@ietf.org" <anima@ietf.org>
Thread-Topic: New Version Notification for draft-fries-anima-brski-async-enroll-00.txt
Thread-Index: AQHU1/AYt0i/05EWqUG/gaEVHFZLQqYGMhlA
Date: Mon, 11 Mar 2019 10:02:08 +0000
Message-ID: <E6C9F0E527F94F4692731382340B33781540B186@DENBGAT9EJ5MSX.ww902.siemens.net>
References: <155229792091.16909.155158627247126928.idtracker@ietfa.amsl.com>
In-Reply-To: <155229792091.16909.155158627247126928.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [139.22.70.32]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/we6q6WSGY5lmX1ak8nTUobrPcBA>
Subject: [Anima] FW: New Version Notification for draft-fries-anima-brski-async-enroll-00.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2019 10:02:18 -0000

Hello,

Just as an information, we submitted the initial draft for discussion regarding the asynchronous enrollment. It discusses a solution in which the Domain registrar has no nor temporary limited connectivity to a backend for interaction with a PKI (and potentially the MASA).
I asked for a slot in the agenda to discuss the draft during the next IETF meeting.

Best regards
Steffen


-----Original Message-----
From: internet-drafts@ietf.org <internet-drafts@ietf.org> 
Sent: Montag, 11. März 2019 10:52
To: Eliot Lear <lear@cisco.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>; Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Subject: New Version Notification for draft-fries-anima-brski-async-enroll-00.txt


A new version of I-D, draft-fries-anima-brski-async-enroll-00.txt
has been successfully submitted by Steffen Fries and posted to the IETF repository.

Name:		draft-fries-anima-brski-async-enroll
Revision:	00
Title:		Support of asynchronous Enrollment in BRSKI
Document date:	2019-03-11
Group:		Individual Submission
Pages:		18
URL:            https://www.ietf.org/internet-drafts/draft-fries-anima-brski-async-enroll-00.txt
Status:         https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/
Htmlized:       https://tools.ietf.org/html/draft-fries-anima-brski-async-enroll-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-fries-anima-brski-async-enroll


Abstract:
   This document discusses the enhancement of automated bootstrapping of
   a remote secure key infrastructure (BRSKI) to operate in domains
   featuring no or only timely limited connectivity to backend services
   offering enrollment functionality like a Public Key Infrastructure
   (PKI).  In the context of deploying new devices the design of BRSKI
   allows for online (synchronous object exchange) and offline
   interactions (asynchronous object exchange) with a manufacturer's
   authorization service.  It utilizes a self-contained voucher to
   transport the domain credentials as a signed object to establish an
   initial trust between the pledge and the deployment domain.  The
   currently supported enrollment protocol for request and distribution
   of deployment domain specific device certificates provides only
   limited support for asynchronous PKI interactions.  This memo
   motivates support of self-contained objects also for certificate
   management by using an abstract notation to allow off-site operation
   of PKI services, with only limited connectivity to the pledge
   deployment domain.  This addresses specifically scenarios, in which
   the deployment domain of a pledge does not perform the final
   authorization of a certification request and rather delegates this
   decision to an operator backend.  The goal is to enable the usage of
   existing and potentially new PKI protocols supporting self-
   containment for certificate management.

                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat