Hi all,
I've reviewed draft-ietf-anima-rfc8366bis-14 as part of the WGLC; with
issues/questions listed below and some editorial updates proposed in a PR.
(See: https://github.com/anima-wg/voucher/pull/85)
My conclusion is that updates to the document are needed before it can
proceed. After the issues are addressed, the document could proceed I
think or maybe a second WGLC can be made.
best regards,
Esko
*** Throughout the document:
* I've replaced "imprint" by "onboarding" in the PR where it's about the
onboarding process and getting the domain's credentials/configuration.
* "Imprint" is solely defined for the process in the factory i.e.
putting the IDevID into the device. According to our terminology
section. Keeping these terms clear and separate helps understanding what
is what.
*** Section 1
"(in constrained variations)"
-> in the PR I've replaced this by "in constrained use cases".
Although "variations" may refer to variations of the BRSKI protocol but
this protocol or any other protocol is not introduced yet at this point
in time, so it's best to stay general.
*** Section 4
"or reliance on Pledge behavior such as secure root of trust of
measurement."
-> unclear what this is: secure root of trust of measurement? What
measurement; can a measurement even have a root of trust?
Table 1: it has 3 columns, corresponding to the 3 properties listed
above it - Assertion, Authentication, Anti-Replay.
It would be nice to more clearly link these names to the column names.
Now, they differ substantially and it may not be immediately clear that
these are mapped 1:1.
Nonceless Audit Voucher:
: An Audit Voucher without a validity period statement.
This seems wrong. It has no nonce, but it does have a validity period
(date-time) statement. This is required, I think , for the nonceless
case? Implied by YANG 'choice'.
This case would just have a long validity period for the voucher.
*** Section 6.1
"To facilitate interoperability, Section 11.3 the media type
"application/voucher-cms+json" and the filename extension ".vcj" were
registered by [RFC8366]."
-> should we say here that the naming is in fact wrong, because the
media type can't be parsed as JSON which the "+json" semantices implies?
And that we nevertheless keep the naming as is?
"Within this document, the signer is assumed to be the MASA."
-> This looks wrong. This document now has Voucher Request in its scope,
which is signed by Pledge or by Registrar. So the assumption needs to
change or ideally just be removed.
*** Section 7.1
Why are the below items separate from the others, i.e. the ones that are
in the "voucher" element? The below ones are not within the "voucher"
element.
RFC 8366 had all the items inside it.
+-- (nonceless)?
| +--:(expires-on)
| | +-- expires-on? yang:date-and-time
| +--:(nonce)
| +-- nonce? binary
+-- est-domain? ietf:uri
+-- additional-configuration-url? ietf:uri
*** Section 7.3
Since the YANG module file is imported, not directly in the .md file, I
didn't make any changes to this in the PR. Instead some comments inline
here:
revision 2023-01-10 {
-> date seems to be incorrect: we recently extended the YANG model, in
2025 I think? Why would we use a 2023 revision label then?
reference
"RFC XXXX Voucher Profile for Bootstrapping Protocols";
-> the name of the RFC itself is not matching the present draft's name.
In the container voucher:
description
"A voucher assigns a pledge to an owner using
the (pinned-domain-cert) value.";
-> better would be "one of the (pinned-domain-*) values. This reflects
the choices we have there now.
choice pinning {
description
"One of these attributes is used by the pledge to
specify the registrar, and how the pledge would like
the registrar's identity to be pinned";
-> description could be more clear. The Pledge is not using this field
to signal anything. Better would be:
"One of these attributes is used by the MASA to pin the registrar
identity."
We don't need to say really how the MASA decides which attribute to use:
that's part of the BRSKI protocol.
The part about what the Pledge would like to have pinned may be of
course related to the "proximity-registrar-*" item, but we don't need to
mention that here - seems confusing otherwise.
Leaf pinned-domain-pubk:
The pinned-domain-pubk is the Raw Public Key of the Registrar.
-> This seems restrictive to RPK only, as the method by which a
Registrar identifies itself. It could also identify by X509 certificate.
And then the voucher pins the public key info of this certificate.
In this case the Pledge doesn't have to do chaining operations to
verify that it can trust its current Registrar, and it doesn't have to
understand items in the X509 certificate, as long as it can extract the
public key info part.
This makes the voucher small while the Registrar can still use its
regular certificate-based TLS/DTLS handshake. This feature is useful
for cBRSKI, even in cases where RPK is not used in the DTLS handshake
but regular X509 certificates.
Leaf pinned-domain-pubk-sha256:
Algorithm agility is provided by extensions to this
specification which can define a new leaf for another
hash type.";
-> can we extend the voucher easily with new leaf types? I thought we
now have the 'extensions' solution for that. Can a new
pinned-domain-pubk-foo leaf be added by this extensions solution?
Or do we need to spin another RFC for that? It seems to hint to the
latter i.e. updates to this RFC.
*** Section 7.4
Some items have 2 SIDs assigned: additional-configuration-url,
est-domain, expires-on.
*** Section 7.5
"In JSON serialization, these extensions require a unique name, and this
MUST be allocated by IANA. The name MUST be the same as the YANG module
name. "
-> this is unclear to me. If every extension has the same name, it's not
unique and not useful.
*** Section 8.1
Again like in 7.1, why are some items/leaves outside of the "voucher"
element?
*** Section 8.2
In the YANG, the name of RFC XXXX differs from the actual name - same
thing as in 7.3.
The boilerplate BCP text is included twice in the same field:
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
revision 2023-01-10 {
description
"Initial version";
reference
"RFC XXXX: Bootstrapping Remote Secure Key Infrastructure";
}
-> name of RFC XXXX, which points to the present draft, is incorrect.
Also "Initial version" can't be the case since we've defined the module
before in RFC 8995.
refine "voucher/created-on" {
mandatory false;
}
-> this part is not needed, the field wasn't mandatory in 'voucher' so
nothing changes.
refine "voucher/assertion" {
mandatory false;
description
"Any assertion included in registrar voucher
requests SHOULD be ignored by the MASA.";
}
-> the 'mandatory false' is not needed, it wasn't mandatory in 'voucher'.
In the leaf prior-signed-voucher-request:
If it is necessary to change a voucher, or re-sign and
forward a voucher that was previously provided along a
protocol path, then the previously signed voucher SHOULD
be included in this field.
-> change "voucher" to "voucher request" here. Otherwise, confusing,
since a prior voucher is never included in a PVR or RVR.
For example this
information could be useful to a MASA to determine
that both pledge and registrar agree on proximity
assertions.
-> This looks incorrect, the description for "assertion" basically says
a Pledge would not include any assertion in the PVR. And that the MASA
needs to ignore any value there. So it's not possible to see what the
Pledge thinks is the proximity assertion.
choice registrar-identity {
description
"One of these three attributes will be used to pin the \
registrar identity";
-> I think this wording needs to be updated, because "pinning" is
exclusively defined in this document as the MASA indicating in a voucher
which entity/domain to trust.
In a PVR, the Pledge will identify the Registrar it sees but this
is not "pinning" according to our own definitions. I prefer not to
stretch the meaning of "pinning", for clarity.
What about:
One of these attributes will be used by a Pledge to specify
the proximity to, and the identity of, a Registrar it is communicating with"
By including one of these fields the Pledge basically claims it sees a
Registrar in its (communication) proximity and at the same time it
conveys the Registrar identity in some way. (Note that the Pledge
doesn't include the "assertion" leaf - including one of the
"proximity-*" leafs alone is already a claim of proximity.)
Leaf proximity-registrar-cert:
This MUST be populated in a Pledge's voucher request
when a proximity assertion is requested."
-> We now have a choice, so the MUST is not on this leaf anymore. It's a
MUST for the "choice registrar-identity" element -> exactly one of these
choice leafs MUST be included when a Pledge wants to indicate proximity
to a Registrar.
There's no MUST include for any one of the 3 individually.
Also, I don't think the Pledge requests a proximity assertion from the
MASA here: it's just sending a claim that it is in proximity to the
particular Registrar. What the MASA does with that, is BRSKI protocol
concern?
E.g. the MASA could send another type of assertion also, possibly: if it
could not verify the proximity really due to a Registrar/RVR/PVR
identity mismatch it might create only a "logged" assertion.
Leaf proximity-registrar-pubk :
The proximity-registrar-pubk is the Raw Public Key of the
Registrar.
-> see previous comment about RPK use. It can also be not the RPK, but
just the public key info taken out of the X509 certificate. This
provides a saving in PVR size, while essentially conveying the same info.
If we say "public key" it may refer to an RPK or the public key from
the certificate, so seems more generally useful this way.
Leaf proximity-registrar-pubk-sha256: same comment on 'algorithm
agility' sentence as before for the leaf 'pinned-domain-pubk-sha256'.
Leaf agent-signed-data: I would personally make the text lines a bit
shorter to avoid the many line breaks here. E.g. do as the other
description items do.
** Section 8.3
The item 'expires-on' appears duplicated.
** Section 10.2
"Pursuant the recommendation made in Section 6.1 for the MASA to be
deployed as an online voucher signing service,"
-> I didn't see any such recommendation in 6.1. Is it elsewhere maybe?
** Section 10.4
In the below text, yang-data use is assumed. However the document now
doesn't use this anymore but rather SX:STRUCTURE, per Section 8.
So probably this disclaimer can be removed, or rewritten to apply to
SX:STRUCTURE instead?
The use of YANG to define data structures, via the 'yang-data'
statement, is relatively new and distinct from the traditional use of
YANG to define an API accessed by network management protocols such as
NETCONF [RFC6241] and RESTCONF [RFC8040]. For this reason, these
guidelines do not follow template described by Section 3.7 of [YANG-GUIDE].
** Section 11.1
The 'voucher-request' URI is missing here, originally from 8995.
I thought the idea would be to include also the relevant voucher-request
definitions from 8995 in here?
** Section 11.2
The 'voucher-request' module is missing here.
** Section 11.5
The policy "First Come First Served" per RFC 8126 has the following
property:
It is also important to understand that First Come First Served
really has no filtering. Essentially, any well-formed request is
accepted.
This is I think what we intend. However, in practice this implies that
IANA doesn't involve any expert to check anything.
So the Designated Experts part at the end of the section can't be
executed because the expert is not notified.
If you want an expert to be notified, Expert Review is needed with
instructions in this section.
Furthermore, a comment on the SHOULD be FQDN: it would also be good to
allow URNs here. For example one that owns this namespace could define:
urn:thread:yang:meshpar:1
and have a module SID taken from the PEN SID namespace. This format
could be more desirable than the FQDN, so we can allow both.
While the domain in the FQDN could still change hands, or the desired
short domain name is not under control of the requester, the URN
namespace provides a stable way to register these. It's firmly allocated
to a given organisation, presumably also over long time periods.
** Section 12.*
See the PR: proposed to have CBOR and the YANG-CBOR mapping process to
be normative, since this document now defines the voucher data encoding
in CBOR and JSON, both.
The signing for CBOR is defined elsewhere (cBRSKI) so that means the
COSE part can remain informative.
Some references were fixed/updated in the PR, such as RFC 5822 which was
never issued apparently.
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
