Hi Brian,
Thanks for the feedback. It looks like the draft is struggling between
the viewpoints of "cBRSKI is a new protocol based on BRSKI" vs "cBRSKI
equals BRSKI and is a variant on it".
cBRSKI is an extension of BRSKI (without impacting existing
implementations), however the document also does provide some normative
updates to BRSKI/8995 which might impact existing implementations in
case they weren't doing these things right.
The namings "BRSKI-EST" and "BRSKI-MASA" are used to divide all protocol
interactions into 2 groups. This way of dividing would conceptually hold
for cBRSKI, but also for existing BRSKI (8995).
An alternate way to summarize this very shortly would be like this:
cBRSKI = cBRSKI-EST + cBRSKI-MASA
BRSKI = BRSKI-EST + BRSKI-MASA
This is probably confusing as well, because it uses another definition
for these terms. The key thing I think is that "BRSKI-EST" as used now
in the draft is a way to say "The Pledge-to-Registrar interactions of
any BRSKI type protocol (including 8995 and cBRSKI and possible others)".
Under this definition, you don't need to say cBRSKI-EST because it would
already fall under "BRSKI-EST".
Let me know if there are concerete ideas to make this all more clear.
I'll think about it also!
Maybe we should call it "Pledge-to-Registrar Scope" or
"Pledge-to-Registrar Leg" or so instead of BRSKI-EST.
regards
Esko
On 6/8/26 22:48, Brian E Carpenter wrote:
Esko,
In answer to your question about how the updates are presented, I
think that, with the presence of section 5 "Updates to RFC 8995 and
RFC 9148", the current approach is fine.
However, can I suggest that section 4 "Overview of Protocol" should
contain a couple of sentences explaining the general relationships to
RFC 8995 and 2148. It's a bit confusing that you say "Similar to BRSKI
[RFC8995]..." and "using the EST-coaps [RFC9148] protocol..." without
stating that you do in fact *use* those protocols, with the changes
summarised in section 5.
Also, if I understand correctly, you are actually *extending* RFC 8995
and 2148, that is, existing implementations will still work as
expected. "Extend" is not in the RFC metadata vocabulary,
unfortunately, but you could state it explicitly in the text of
sections 4 and 5.
Finally, I am a bit confused about the relationship between the terms
"cBRSKI", "BRSKI-EST" and "BRSKI-MASA". Is it true that cBRSKI =
BRSKI-EST + BRSKI-MASA or is it more complicated?
Regards/Ngā mihi
Brian Carpenter
On 08-Jun-26 21:53, Esko Dijk wrote:
Dear ACE WG, (cc: ANIMA)
below the info of the latest draft of cBRSKI. It now provides a
clearer description of what elements from RFC 9148 are updated.
Any comments are of course welcome. FYI we had some prior discussion
in the BRSKI design team on how such updates should be written down:
1) as currently done (free-form text, not literally quoting RFC 9148
text)
2) quote exact RFC 9148 text and use OLD/NEW to indicate the change
3) provide NEW text for particular RFC 9148 sections, replacing what
was there before.
The discussion wasn't fully settled yet but until now no major
pushback was observed for our method 1).
One element to consider is whether these updates are also useful for,
or may interfere with, other post-9148 drafts such as
draft-ietf-ace-coap-est-oscore ?
best regards,
Esko
-------- Forwarded Message --------
Subject: [Anima] I-D Action:
draft-ietf-anima-constrained-voucher-31.txt
Date: Mon, 08 Jun 2026 02:42:55 -0700
From: [email protected]
Reply-To: [email protected]
To: [email protected]
CC: [email protected]
Internet-Draft draft-ietf-anima-constrained-voucher-31.txt is now
available.
It is a work item of the Autonomic Networking Integrated Model and
Approach
(ANIMA) WG of the IETF.
Title: Constrained Bootstrapping Remote Secure Key Infrastructure
(cBRSKI)
Authors: Michael Richardson
Peter van der Stok
Panos Kampanakis
Esko Dijk
Name: draft-ietf-anima-constrained-voucher-31.txt
Pages: 96
Dates: 2026-06-08
Abstract:
This document defines the Constrained Bootstrapping Remote Secure Key
Infrastructure (cBRSKI) protocol, which provides a solution for
secure zero-touch onboarding of resource-constrained (IoT) devices
into the network of a domain owner. This protocol is designed for
constrained networks, which may have limited data throughput or may
experience frequent packet loss. cBRSKI is a variant of the BRSKI
protocol, which uses an artifact signed by the device manufacturer
called the "voucher" which enables a new device and the owner's
network to mutually authenticate. While the BRSKI voucher data is
encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The
BRSKI voucher data definition is extended with new data types that
allow for smaller voucher sizes. The Enrollment over Secure
Transport (EST) protocol, used in BRSKI, is replaced with EST-over-
CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP
(CoAPS). This document Updates RFC 8995 and RFC 9148.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-31.html
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-constrained-voucher-31
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
