Skip to main content

BRSKI with Pledge in Responder Mode (BRSKI-PRM)
draft-ietf-anima-brski-prm-23

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-brski-prm@ietf.org, ietf@kovatsch.net, mjethanandani@gmail.com, rfc-editor@rfc-editor.org, tte@cs.fau.de
Subject: Protocol Action: 'BRSKI with Pledge in Responder Mode (BRSKI-PRM)' to Proposed Standard (draft-ietf-anima-brski-prm-17.txt)

The IESG has approved the following document:
- 'BRSKI with Pledge in Responder Mode (BRSKI-PRM)'
  (draft-ietf-anima-brski-prm-17.txt) as Proposed Standard

This document is the product of the Autonomic Networking Integrated Model and
Approach Working Group.

The IESG contact persons are Warren Kumari and Mahesh Jethanandani.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/


Ballot Text

Technical Summary

   This document defines enhancements to Bootstrapping a Remote Secure
   Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in
   domains featuring no or only limited connectivity between a pledge
   and the domain registrar.  It specifically changes the interaction
   model from a pledge-initiated mode, as used in BRSKI, to a pledge-
   responding mode, where the pledge is in server role.  For this, BRSKI
   with Pledge in Responder Mode (BRSKI-PRM) introduces new endpoints
   for the Domain Registrar and pledge, and a new component, the
   Registrar-Agent, which facilitates the communication between pledge
   and registrar during the bootstrapping phase.  To establish the trust
   relation between pledge and registrar, BRSKI-PRM relies on object
   security rather than transport security.  The approach defined here
   is agnostic to the enrollment protocol that connects the domain
   registrar to the Key Infrastructure (e.g., domain CA).

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

From the shepherd writeup:

There is broad agreement among the active WG participants, in particular the
design team. There are others being silent, but no opponents.

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

There is an open-source implementation by the Munich University of Applied
Sciences. The code is available at https://github.com/hm-edu/open-brski under
MIT license (the repo may move for organizational reasons, but a forwarder
was requested).

- Rust for MASA, Registrar, and Pledge; Dart for Registrar-Agent

There are two company inner source implementations of BRSKI-PRM by Siemens,
developed by different persons and cross-tested for correctness and
interoperability.

- Java for MASA, Registrar, and (unconstrained) Pledge
- C for Pledge

A DNSDIR, YANG Doctors review, IOTDIR and IANA review has been done
and the document was updated to address those reviews.

Personnel

   The Document Shepherd for this document is Matthias Kovatsch. The
   Responsible Area Director is Mahesh Jethanandani.

RFC Editor Note