Hi Toerless,
On 2/18/26 00:52, Toerless Eckert wrote:
Process: As long as IETF review is not over, we still have the opportunity to
ask for a fix as individual contributors to IETF. If we're faster, we my be
able to stuff it in before Mahesh gets to it ;-). Or else we find a way
to do it during IESG review. Just need creative explanation. Don't worry
about process. Let's focus on creating the best technology explanation that
we can find.
Ok - I'm planning to submit my PR soon!
1. Outsourced MASA
"However, there are situations where the one to one relationship may
be broken. This occurs whenever a manufacturer has a common MASA,
but different products (on different assembly lines) are produced
with identical serial numbers."
How about an outsourced MASA supprting multiple manufacturers ? How would
the MASA know from which issuer the IDevID and hence the serial number is ?
This is a useful use case I think, and it's very similar to the case
already described by the quote from cBRSKI Section 8.4. So effectively
there are multiple "product lines" of Pledges all being registered to
the same MASA, where each "line" has its own unique CA signing/issueing
the IDevIDs, and serial numbers MAY overlap. It doesn't really matter if
the different CAs were originally from the same company but different
subdivisions; or from different small companies using the same MASA service.
In both cases the MASA receives the RVR and then it first looks into the
idevid-issuer field to see which "line" CA issued the Pledge's IDevID.
Then, it looks at the serial-number to find the correct Pledge in the
databases. Other checks as specified are done also (e.g. the below
Section 5.5.5 reference.)
[ After all, if i am not mistaken, the MASA will never see the IDevID, or
do we have an extension in the voucher to encapsulate it into the RVR and
that extension is mandatory ?? ]
For regular BRSKI (RFC 8995), the Registrar includes the complete signed
PVR in the "prior-signed-voucher-request" field of the RVR. This signed
PVR in turn includes an X509 cert chain the Pledge used to sign. So the
MASA does see the IDevID in this case, extracted from the RVR and its
embedded PVR. See Section 5.5.5 of RFC 8995. Even though the MASA "MAY"
verify that the "prior-signed-voucher-request" is present, given that
the Registrar doesn't know if MASA will do that or not, it's still a
"MUST" for the Registrar to include the "prior-signed-voucher-request"
field. So this way, the "product line" CA is identified and also the
IDevID is identified. Note that the MASA can also use the
"idevid-issuer" field for this as the first quick way of identifying the
"product line" before diving deeper into the embedded PVR and validating
that.
For cBRSKI, the signed PVR is COSE and very compact and typically
doesn't include any X509 certificates or chains. In this case the MASA
relies on these data items: 1) serial-number from RVR; 2) idevid-issuer
from RVR; 3) serial-number from PVR-embedded-in-RVR / cross-checked
against (1).
The assumption I made for cBRSKI is that the MASA can validate the
complete IDevID cert chain by fetching the one unique IDevID EE cert
based on the (idevid-issuer , serial-number) pair; and also fetching any
sub-CAs from the database as needed.
This requires storing all the IDevID EE certs of any devices ever
produced that have a MASA URI pointing to this particular MASA. For
those cases where this storing requirement is unwanted or unrealistic,
cBRSKI does allow sending Pledge's signing certs in the PVR using the
x5bag / x5chain elements as per the last paragraph of 9.2.2 of cBRSKI.
However this is discouraged due to the enormous size impact on the PVR.
Typically COSE relies on a signing structure that doesn't include the
signing key, signing certificate, or signing cert chain, to make it as
compact as possible. The "signing entity" is assumed to be known at the
verifier side either indirectly (through context / other fields in the
data) or by a small reference ID which is the "key identifier" (KID).
This puts the burden on the MASA database to store the full information
i.e. the IDevID including its public key.
The outsourced MASA definitely needs to be explained if it's a case where
we need to worry about this issuer issuer. Having to solely trust a manufacturer
MASA has always been a source of criticism ("what happens if manufacturer
goes bancrupt" - "planned obsolescence"). So one or more third-party MASA
are an important option of the voucher story. More so for small embedded
devices potentially from smaller companies than for large unconstrained
devices...
Agree, an important case. We could mention this in the 8366bis
clarifying text?
2. "Analysis of the situation shows that the pledge never needs to include
the idevid-issuer in it's PVR, because the pledge's IDevID certificate is
available to the Registrar, and the Authority Key Identifier is contained
within that IDevID certificate."
https://raw.githubusercontent.com/anima-wg/brski-discovery/refs/heads/main/certs/cisco-sudi1/sudi.pem
decode appended below. Example Cisco IDevID. No Authority Key Identifier
(AKI).
My buddy chatgpt says that AKI is optional for end-entity certs in X509,
but the way i read rfc5280 4.2.1.1 it is mandatory there. So the
question is if we want to ignore reality or alwo work for what is mandated
in rfc5280. (And that question will be even harder if we are looking at
the Huawei cert example...).
See the IEEE 802.1AR spec that defines the IDevID and LDevID (both
commonly called DevIDs). I used version 2009. It's mandatory in the
IDevID by design:
7.2.5 authorityKeyIdentifier
To optimize building the correct credential chain, the non-critical
Authority Key Identifier extension *shall be*
populated with a unique value as recommended by RFC 5280 and *shall be
included* in all DevID certificates
ChatGPT also says that the AKI does not need to be present because whoever
receives the certificate can look up the supposed signer key from the
IDevID Issuer SubjectName, "O=Cisco, CN=ACT2 SUDI CA" in this example.
And save the space in the cert.
IEEE 802.1AR is also designed to save space, but in another way: it
keeps the issuer and subject fields with name and company and country
etc jointly to a minimum and instead relies on AKI/SKI combination to do
a more exact match of EE cert to CA cert. Note the SKI is only used in a
CA cert then (see 1AR spec).
So the 802.1AR spec implies / intends that you can use SKI/AKI for
certificate chain building and do easier exact matching instead of
trying to match multiple Subject Name fields to multiple Issuer Name fields.
By the way, the example Cisco cert does not include a MASA URI
(1.3.6.1.5.5.7.1.32) field. Without this field, the cert is not really
suitable for BRSKI I think? So it's a non-BRSKI IDevID?
So that text may need to be adjusted if we want to accept reality and
write against it.
We have to be careful here. Formally we don't need to design for devices
that deviate from the requirements like 802.1AR poses. If we do allow an
exception here, it would be an update of BRSKI I think, and it may
impact text in other places as well.
Accepting current usage without AKI would need to be specifically
mentioned and would need a good reason e.g. if there's already
significant deployment of BRSKI with such certificates.
For cBRSKI we could still require that AKI MUST be present, because as
explained earlier above, it relies more on the idevid-issuer +
serial-number combo to retrieve database information and it cannot fall
back to introspecting the CMS signing structure of the embedded PVR like
the BRSKI protocol can support for the MASA.
3. subCA
I am mostly worried about subCA - and beside the outsourced MASA,
they may be the biggest reason for idevid-issuer:
CAs that assign IDevIDs will already today be most likely subCA.
SImply because its way too dangerous to exhaust an actual root CA
by a lot of assignments, or make its private key subject to destruction
by having it physcally online all the time and reachable over
network connections that need to be scured. Real rootCA are
all stored offline in a vault.
So, in the simple case, the assigning CA will be announced to
customers running registrars to use as "root CA". But in a vendor
or even manufacturer with multiple production lines, there could
be a separate assigning CA in each manufacturing plant, and given
how often they may need to change, it could be considered to be
too much effort trying to tell customers all about them.
In this case, the devices themselves would need to store their
assigning CA cert together with the IDevID as thir cert chain -
which it then also signals via TLS.
So far so good. But now the question is what the poor registrar
does for it's RVR. It could of course "JUST" generate the AKI
from the PVR signing key using the public key from the subCA
as it was signalled in TLS and applying the SHA-1 hash
from rfc5280, 4.2.1.2 (1). But if that's what we think should
happen - then we should write it down somewhere.
Not sure I understand the case described above regarding sub-CAs. One
thing the Registrar cannot do is "generate" the AKI. Because there are
various methods to generate SKI/AKI and in advance the Registrar doesn't
know which was used by the manufacturer. The only real requirement is
that the AKI of the EE (IDevID) cert matches exactly to the SKI of the
CA that created/signed the IDevID. Where "CA" may be a sub-CA or a root
CA. See 802.1AR.
What the Registrar needs to do is take the AKI from the EE (End Entity)
cert, also called "leaf cert" sometimes, and include that as the
"idevid-issuer". Currently, if that AKI is not there, then the cert is
formally not an IDevID cert, and BRSKI is not supposed to execute further.
Still, I'm ok to debate about a possible exception to this based on the
fact that we (may?) have deployed devices that omit the AKI.
In this text
would be fine with me. And putting it into rfc8366bis would also
be better than any individual protocol rfc.
But: I don't think that would really be sufficient. When a
MASA receives such a voucher, it would have to have all those
subCA certificates already stored before it could match it
up from just the KeyIdentifier field of the AKI. And especially
Yes, this is exactly the assumption for cBRSKI: the entire cert chain is
already in the database(s) somewhere. That makes the compact PVR possible.
For regular BRSKI, as stated earlier, the MASA can inspect the CMS
signing structure of the embedded PVR in the RVR and get all the certs
from there to build the chain to the root CA. In this case it only needs
to store the root CA(s) for all product lines in its database.
when we have the case of an outsourced MASA or the above
described subCA that could pop up and change with any
individual manufacturing plant - then it is very likely
that something goes wrong. And just the AKI is not going to
help figure out from which manufacturer which particular
subCA was used to sign the IdevID. And hence to disambiguate
the serial number (which obviously is badly formatted by
only being an actual number instead of structured, but thats
again down to accepting reality...).
So, i would really like to say that the AKI SHOULD also include
the rfc5280 4.2.1.1 GeneralNames field and encode the assigning
cvertificates SubjectName in it. Because that would provide
This would be another identifier included in the RVR, not an AKI! AKI is
a very specific thing different from the authority name. So we should
call it differently.
Having the authority name alone would still not allow the MASA to
proceed with the onboarding, if it misses some intermediate certs
(sub-CAs) needed to build the chain. It would help debugging/diagnosing
at the MASA side I agree.
However for BRSKI this info is already in the embedded PVR CMS, while
for cBRSKI it could be a worthwhile addition: if defined as a new
separate field from the current "idevid-issuer". It would be like a
"idevid-issuer-name" or so.
sufficient diagnostics and troubleshooting in the MASA to
figure out, what certificate was assumed to be used for signing
the IDevID.
4. Encoding underspecification:
Which brings us to this text in rfc8366bis:
leaf idevid-issuer {
type binary;
description
"The Authority Key Identifier OCTET STRING (as defined in
Section 4.2.1.1 of RFC 5280) from the pledge's IDevID
certificate.
rfc5280 4.2.1.1:
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
KeyIdentifier ::= OCTET STRING
So, i think that the rfc8366bis text is not really 100% correct,
if i correctly interpret it, then it probably should read:
Agree, this part was what the cBRSKI text in 8.4 tried to clarify and fix.
"The keyIdentifier OCTET STRING element of the AuthorityKeyIdentifier
(as defined in Section 4.2.1.1 of RFC 5280) from the pledge's
IDevID certificate, or if not present there, then created
by the voucher generator from the IDevID signing certificate
according to the rules in rfc5280, Section 4.2.1.2(1).
(This part up for discussion: would require a change in BRSKI as stated
earlier.)
Now, just refining that text does of course not solve the wish i
stated in the last point: I think for troubleshooting on desirable
MASA, we really need the IDevID issuer's name known at the MASA,
or else whenever the MASA fails to find a cert matching the
keyIdentifier/idevid-issuer SHA-1 value, there is no troubleshooting
possible - and BRSKI will simply not be deployed in highly
desirable setups with outsourced MASA or subCA (unless i am
overlooking some already existing option to figure out the issue).
(see above - the embedded PVR's CMS signing solves this and for cBRSKI
we assume MASA stores all the chains)
Now, we couldn't change encoding of idevid-issuer to be the whole
AuthorityKeyIdentifier because that would be non-backward
compatible with rfc8366. Even worse, the authorityCertIssuer/CertSerialNumer
are kinda stupid too. They are not very useful for troubleshooting because
you would have to go to the vault with the rootCA, and look through all
the serialnumbers it has signed - to find the cert of the subCA.
We tried to clarify what RFC 8366 meant:
Concerning the Authority Key Identifier, [RFC8366bis] specifies that the
entire object i.e. the extnValue OCTET STRING is to be included:
comprising the AuthorityKeyIdentifier, SEQUENCE, Choice as well as the
OCTET STRING that is the keyIdentifier.
So because we intend it as clarification, there's no change. And if
there's no change, there's no backward-compatibility problem. There was
some confusion between implementations, some draft / prototypes used
only the "keyIdentifier" part; and this led to the updated text here.
Not sure if this was ever used in production use.
I don't think there's ever a need to "go to the vault" because the root
CA cert and sub-CA certs are all public in principle. Public keys
included are sufficient to build the chains and verify who signed what.
In any case: we can leave solving this issue to another rfc
after rfc8366bis, but if we are going to put a section about the
idevid-issuer into rfc8366bis, then i would like to highlight
this lack of troubleshooting solely via idevid-issuer as an open
issue when using multi-manufacturer MASA or even more so, subCA
using IDevIDs.
Such a warning would need to go into cBRSKI then, I believe? That
protocol assumes the MASA stores all IDevID certs and all sub-CAs and
root CA, and some partial loss of data (e.g. lost IDevID EE certs) makes
it impossible to perform chain validation, because the public keys of
the IDevID EE certs are also lost! The MASA can't reconstruct those lost
public keys in any way.
In BRSKI with CMS, this loss is not catastrophic: the public key can be
extracted from the CMS of the PVR (embedded in the RVR).
Cheers
Toerless
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 25264045 (0x1817fad)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=Cisco, CN=ACT2 SUDI CA
Validity
Not Before: Apr 28 10:55:55 2017 GMT
Not After : Apr 28 10:55:55 2027 GMT
Subject: serialNumber=PID:C9500-16X SN:FCW2117A56M, O=Cisco, OU=ACT-2
Lite SUDI, CN=C9500-16X
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b1:e9:e6:ac:dc:9b:5b:48:0b:ae:ee:18:dd:46:
a4:6e:56:c5:8e:61:ef:23:02:1d:12:ba:36:1d:93:
de:c2:bb:ff:4b:4d:78:b4:f3:80:b9:74:9f:15:d2:
61:49:10:06:c2:10:78:8e:2e:f5:3f:84:7d:02:aa:
10:7e:ba:72:6e:ad:df:24:46:89:0a:66:a4:91:d3:
f9:54:19:8f:2e:6f:90:74:9c:06:73:b1:86:89:4b:
97:af:af:d1:3d:38:f3:75:f5:53:27:4b:af:12:2f:
e1:a2:59:d3:ad:8b:87:8a:ed:09:4f:7b:ec:5e:2d:
5b:2a:49:75:1c:91:5e:1a:ca:4c:09:26:51:45:ca:
00:c4:86:7c:19:11:6d:f9:8e:5f:dd:08:15:ed:bd:
42:7b:8c:cb:4b:12:6a:4e:a8:84:0d:43:51:ba:87:
86:c1:bf:98:b5:03:ad:7a:9e:77:86:7c:15:a1:4e:
9b:8c:d6:90:5e:3a:bd:a6:07:09:74:cc:a1:87:ec:
d1:b5:a4:51:12:97:ac:e0:1e:c8:65:a1:52:30:67:
94:6c:6b:df:54:4e:91:fb:8d:26:20:cf:93:db:a7:
e7:65:ad:a4:e1:b4:2f:ad:c9:bf:d5:56:de:ff:a1:
72:e2:b9:e2:1c:05:f0:cc:60:82:80:81:df:20:93:
2b:4b
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Alternative Name:
othername: 1.3.6.1.4.1.9.21.2.3:<unsupported>
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
3c:4e:ec:ab:38:02:54:9b:f1:69:c4:ab:43:8c:a2:af:b7:b6:
25:c7:2c:36:15:74:95:20:1f:4c:39:16:c5:28:13:5d:df:cb:
19:fc:eb:bb:1a:88:95:4c:62:b4:fb:fb:fc:13:b1:ec:71:74:
32:72:48:60:09:1f:99:8f:77:03:cf:98:47:cb:1f:0f:7f:0f:
af:e5:fd:de:85:b1:cd:4c:fc:b7:81:ab:e4:36:6b:a2:fa:a1:
97:75:ac:92:61:78:d4:32:08:df:e3:38:26:2e:33:47:4a:f4:
9c:83:8c:b7:5a:f6:34:9a:dc:02:fb:52:c3:9c:af:d6:9c:88:
14:3f:0a:36:7a:f1:b5:77:c7:c2:f3:03:23:c3:b3:ef:aa:cb:
a7:c7:80:1e:0e:a4:ff:2f:38:9b:50:76:76:06:0d:90:2d:3a:
e9:f8:26:5c:f7:3f:25:e3:48:9c:bd:5d:6a:16:7e:51:be:da:
71:97:83:d3:c2:8a:0f:25:d6:9a:4f:8c:38:35:a6:b6:7a:d2:
5b:7e:b1:c1:04:27:3a:99:9a:81:c6:9f:f9:5e:94:e1:f8:b3:
e9:89:4d:50:31:6e:00:6e:75:c0:37:d1:7a:5d:78:7a:8e:0f:
43:9d:90:6f:09:91:73:d8:71:44:39:8a:7e:11:eb:38:30:5c:
49:ea:33:36
On Mon, Feb 16, 2026 at 07:01:33PM +0100, Esko Dijk wrote:
Hi all,
Draft-8366bis has now been submitted to IESG I see; I was just wondering if
the WG can still make changes to it?
In particular, we have this text in cBRSKI:
https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher#section-8.4
This explains idevid-issuer usage more clearly than 8366/8995 did and
8366bis does. Given that we do have an 8366bis now, the best place for this
text would be in 8366bis. It's definitely not cBRSKI-specific.
If that's okay, I can make a PR to include it in Sections 5 and 6. Any
opinions ?
Esko
PS: due to travel I can't join the ANIMA design team call tomorrow,
unfortunately!
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
