GENAD review comments by mcr · Pull Request #143 · anima-wg/voucher

mcr · 2026-08-05T00:06:42Z

close #142 close #141

…lose #142

…-safe recommendations

EskoDijk · 2026-08-05T21:30:27Z

 For Vouchers stored/transferred via methods like a USB storage device (USB key), the Voucher format is usually signaled by a filename extension.

-In the constrained versions of the voucher and voucher-request (as used by {{cBRSKI}}), the attributes `pinned-domain-pubk` (`proximity-registrar-pubk` for requests) and `pinned-domain-pubk-sha256` (`proximity-registrar-pubk-sha256` for requests) are involved in the process of pinning a raw public key.
+As explained in {{RFC8995, Section 2.5}}, the Pledge is a creation of the manufacturer, and thus manufacturer (in the form of the Manufacturer Authorized Signing Authority (MASA)) has knowledge of the capabilities of the Pledge.


Suggested change

As explained in {{RFC8995, Section 2.5}}, the Pledge is a creation of the manufacturer, and thus manufacturer (in the form of the Manufacturer Authorized Signing Authority (MASA)) has knowledge of the capabilities of the Pledge.

As explained in {{RFC8995, Section 2.5}}, the Pledge is a creation of the manufacturer, and thus the manufacturer (in the form of the Manufacturer Authorized Signing Authority (MASA)) has knowledge of the capabilities of the Pledge.

EskoDijk · 2026-08-05T21:32:04Z


-In the constrained versions of the voucher and voucher-request (as used by {{cBRSKI}}), the attributes `pinned-domain-pubk` (`proximity-registrar-pubk` for requests) and `pinned-domain-pubk-sha256` (`proximity-registrar-pubk-sha256` for requests) are involved in the process of pinning a raw public key.
+As explained in {{RFC8995, Section 2.5}}, the Pledge is a creation of the manufacturer, and thus manufacturer (in the form of the Manufacturer Authorized Signing Authority (MASA)) has knowledge of the capabilities of the Pledge.
+Specifically, the manufacturer knows what signature algoritms the Pledge is doing to use, and can verify, thus there is no need (or opportunity) to negotiate the algorithm  or signature (CMS, JWS, COSE) scheme.


Suggested change

Specifically, the manufacturer knows what signature algoritms the Pledge is doing to use, and can verify, thus there is no need (or opportunity) to negotiate the algorithm or signature (CMS, JWS, COSE) scheme.

Specifically, the manufacturer knows what signature algoritm the Pledge is going to use, and can verify this, thus there is no need (or opportunity) to negotiate the algorithm or signature (CMS, JWS, COSE) scheme.

EskoDijk · 2026-08-05T21:33:00Z

+As explained in {{RFC8995, Section 2.5}}, the Pledge is a creation of the manufacturer, and thus manufacturer (in the form of the Manufacturer Authorized Signing Authority (MASA)) has knowledge of the capabilities of the Pledge.
+Specifically, the manufacturer knows what signature algoritms the Pledge is doing to use, and can verify, thus there is no need (or opportunity) to negotiate the algorithm  or signature (CMS, JWS, COSE) scheme.
+Nor is there any need for a mandatory to implement (MTI) scheme, as again, by (literal) construction, the manufacturer knows what has been implemented.
+In constrained situations, the Pledge is expected to only have code space for a single algorithm and signature scheme


Suggested change

In constrained situations, the Pledge is expected to only have code space for a single algorithm and signature scheme

In constrained-device situations, the Pledge is expected to only have code space for a single algorithm and signature scheme.

EskoDijk · 2026-08-05T21:34:32Z

+A manufacturer may transition devices among different algorithms, transitioning to quantum-safe ones as they become standardized, according to their own schedule.
+
+The only device for which this approach is a challenge is for the Domain Registrar.
+That device must deal with all variants which are still relevant to the operation of the specific network.


Since we talked about algorithms and not variants, we should try to use that word to refer to it:

Suggested change

That device must deal with all variants which are still relevant to the operation of the specific network.

That device must deal with all algorithms which are still relevant to the operation of the specific network.

EskoDijk · 2026-08-05T21:38:40Z

+The onboarding (bootstrap) process is a short-duration process, and it will often be the case that once onboarded, the device will be upgraded to newer firmware, with support for better/smaller/safer algorithms.
+Both {{RFC8995}} and {{SZTP}} provide mechanisms by which new (stronger) operational identities can be provisioned.
+
+When designing Pledge devices, manufacturers choose algorithms and signature formats that they need to support in their MASA.


I'm no expert on that vs which grammar, and it can be changed back of course, however some form of hyphen or ";" character is needed to ensure that we say what we want to say (I think). First, an algorithm/format for the Pledge is chosen - device design.
Then after that, it's ensured that the MASA also supports that particular algo/format. The old sentence suggested kind of the reverse, or only a focus on the MASA, which wasn't intended I think.

Suggested change

When designing Pledge devices, manufacturers choose algorithms and signature formats that they need to support in their MASA.

When designing Pledge devices, manufacturers choose algorithms and signature formats - which they also need to support in their MASA.

EskoDijk · 2026-08-05T21:49:53Z

+
+While non-constrained devices could have code space for multiple algorithms or signature schemes, it makes little sense to use anything but the strongest of the algorithms present.
+
+Constrained devices are able to dispense with much code involved in ASN.1/PKIX processing of the voucher and voucher-request.  This is explained in {{cBRSKI}}.


This statement seems (to me) only loosely related to what comes next. So this is saying that because we drop CMS in cBRSKI, we can get rid of CMS code (which is ASN.1 based)?

Or does this solely refer to replacing any pinned domains or "proximity registrar identity" by a shorter version? In the latter case, most of the related code (ASN.1) that handles these functions may still be needed; we don't have a way in cBRSKI to get rid of cert-chaining checks alltogether.
For example, when connecting to an EST server, that server may identify itself with a chain of certs that the IoT device needs to verify against its domain CA trust anchor.

Rather, we could just say here that cBRSKI needs shorter/smaller vouchers, and voucher requests - i.e. smaller data sizes. This alone would be motivation for all these new attributes.

EskoDijk · 2026-08-05T21:52:36Z

+While non-constrained devices could have code space for multiple algorithms or signature schemes, it makes little sense to use anything but the strongest of the algorithms present.
+
+Constrained devices are able to dispense with much code involved in ASN.1/PKIX processing of the voucher and voucher-request.  This is explained in {{cBRSKI}}.
+The attributes `pinned-domain-pubk` (`proximity-registrar-pubk` for requests) and `pinned-domain-pubk-sha256` (`proximity-registrar-pubk-sha256` for requests) are involved in the process of pinning a raw public key for such devices.


looks ok to me but I just realized/found that we define "pinning" in section 1, but not in section 2 where a reader might expect it also. (Just FYI - might be handy to have it in the terminology section 2 also, since "pinning" did give rise to some confusion/objections before for readers with certain backgrounds, like perhaps PKIX background)

EskoDijk · 2026-08-05T21:53:34Z

 The public keys are to be encoded according to {{!RFC7250, Section 3}} for RSA and EcDSA keys, noting that {{!RFC8032}} extends this to include an OID for EdDSA.
 The old (1024-bit) DSA algorithm is not supported.

+In order to partially alleviate how many variations a Registrar implementation need deal with, some RECOMMENDATIONS are as follows:


this looks like normative language in all-caps, but it isn't (confusing). Official term is "RECOMMENDED" or "SHOULD".

EskoDijk · 2026-08-05T21:54:55Z

+The decision as to when to transition to quantum-safe algorithms is a manufacturer
+decision.
+
+Choices outside of these RECOMMENDATIONS likely will result in Pledge devices being unable to onboard on some networks.


see above comment on 'RECOMMENDATIONS'

EskoDijk · 2026-08-05T21:55:22Z

+decision.
+
+Choices outside of these RECOMMENDATIONS likely will result in Pledge devices being unable to onboard on some networks.
+In such a situation, an automated, zero-touch solution may be impossible, but


Suggested change

In such a situation, an automated, zero-touch solution may be impossible, but

In such a situation, an automated, zero-touch onboarding solution may be impossible, but

EskoDijk · 2026-08-05T22:00:17Z


-For vendor proprietary extensions, the string SHOULD be made unique by putting the extension name in the form a fully-qualified domain name (FQDN) {{?RFC3696}}, such as "fuubar.example.com"
+For vendor proprietary extensions, (including ISE submissions), the resulting string still needs to be unique.
+This can be done by putting the extension name in the form a fully-qualified domain name (FQDN) {{?RFC3696}}, such as "fuubar.example.com"


This leads to a highly confusing end result: a just-below paragraph says that the name is always the YANG module name!! Which isn't the case here.

EskoDijk · 2026-08-05T22:01:16Z

 * There are no choices in the extension names (which is always the YANG module name), or SID value (which is from another IANA process).

-* For non-standards track extensions, the Designated Expert should review whatever document is provided, if any.
+* For non-standards track extensions, the Designated Expert should review the provided document is provided for clarity of purpose.


Suggested change

* For non-standards track extensions, the Designated Expert should review the provided document is provided for clarity of purpose.

* For non-standards track extensions, the Designated Expert should review the provided document for clarity of purpose.

EskoDijk

Provided some comments/feedback; updates would be needed I believe.

mcr added 3 commits August 4, 2026 19:07

review: rework some text, fix some grammar, and remove BCP14 words, c…

ada220e

…lose #142

feat: rename ZERO-TOUCH to SZTP in citations

e4e902f

feat: clarify why a MTI is not useful or meaningful, add some quantum…

8978c09

…-safe recommendations

mcr requested review from QiufangMa, pritikin and toerless as code owners August 5, 2026 00:06

mcr requested a review from EskoDijk August 5, 2026 00:08

EskoDijk reviewed Aug 5, 2026

View reviewed changes

EskoDijk requested changes Aug 5, 2026

View reviewed changes

Navigation Menu

Uh oh!

GENAD review comments - #143

GENAD review comments#143
mcr wants to merge 3 commits into
mainfrom
ad-view-comments

mcr commented Aug 5, 2026

Uh oh!

EskoDijk Aug 5, 2026

Uh oh!

EskoDijk Aug 5, 2026

Uh oh!

EskoDijk Aug 5, 2026

Uh oh!

EskoDijk Aug 5, 2026

Uh oh!

EskoDijk Aug 5, 2026

Uh oh!

EskoDijk Aug 5, 2026

Uh oh!

EskoDijk Aug 5, 2026

Uh oh!

EskoDijk Aug 5, 2026

Uh oh!

EskoDijk Aug 5, 2026

Uh oh!

EskoDijk Aug 5, 2026

Uh oh!

EskoDijk Aug 5, 2026

Uh oh!

EskoDijk Aug 5, 2026

Uh oh!

EskoDijk left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	As explained in {{RFC8995, Section 2.5}}, the Pledge is a creation of the manufacturer, and thus manufacturer (in the form of the Manufacturer Authorized Signing Authority (MASA)) has knowledge of the capabilities of the Pledge.
	As explained in {{RFC8995, Section 2.5}}, the Pledge is a creation of the manufacturer, and thus the manufacturer (in the form of the Manufacturer Authorized Signing Authority (MASA)) has knowledge of the capabilities of the Pledge.

	Specifically, the manufacturer knows what signature algoritms the Pledge is doing to use, and can verify, thus there is no need (or opportunity) to negotiate the algorithm or signature (CMS, JWS, COSE) scheme.
	Specifically, the manufacturer knows what signature algoritm the Pledge is going to use, and can verify this, thus there is no need (or opportunity) to negotiate the algorithm or signature (CMS, JWS, COSE) scheme.

	In constrained situations, the Pledge is expected to only have code space for a single algorithm and signature scheme
	In constrained-device situations, the Pledge is expected to only have code space for a single algorithm and signature scheme.

	That device must deal with all variants which are still relevant to the operation of the specific network.
	That device must deal with all algorithms which are still relevant to the operation of the specific network.

	When designing Pledge devices, manufacturers choose algorithms and signature formats that they need to support in their MASA.
	When designing Pledge devices, manufacturers choose algorithms and signature formats - which they also need to support in their MASA.


		While non-constrained devices could have code space for multiple algorithms or signature schemes, it makes little sense to use anything but the strongest of the algorithms present.

		Constrained devices are able to dispense with much code involved in ASN.1/PKIX processing of the voucher and voucher-request. This is explained in {{cBRSKI}}.

	In such a situation, an automated, zero-touch solution may be impossible, but
	In such a situation, an automated, zero-touch onboarding solution may be impossible, but

	* For non-standards track extensions, the Designated Expert should review the provided document is provided for clarity of purpose.
	* For non-standards track extensions, the Designated Expert should review the provided document for clarity of purpose.

Uh oh!

Conversation

mcr commented Aug 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

EskoDijk left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants