On Wed, Feb 18, 2026 at 03:47:36PM +0100, Esko Dijk wrote:
> 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.
Thanks. If the IDevID is included, it seems to me as if the idevid-issuer
field is kinda duplicate ?
> 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).
Ok, then there is the issue potentially i mentioned below.
> 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.
Right. So for what i am worried about below, it would be sufficient
for the registrar to find a way to include the IDevID Signer SubjectName
somehow into the PVR.
> > 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?
Yes.
> 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).
Sure. At i fear the cost of troubleshooting, operational breakdown.
> 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?
Yes, i am not sure if/what Cisco products would explicitly support BRSKI.
But the MASA URI is optional. Without it, the Registrar "simply" has
to determine from the the PVR what the fitting MASA is through configuration.
Which arguably it would somehow want/need to do even with the MASA URI,
because depending on the way the MASA works, the Registrar may need
authorization to receive the vouchers. And even if not needed, the MASA
may only want to reach out to MASAs it expects to use.
In any case, the Registrar would really want to see the IDevID in the
PVR with the Signer SubjectName to determine whats the supposed MASA
for the pledge is. Of course, it could try to do this from idevid issuer,
but that too then requires to know all possible signing keys by the
registrar. Wich works badly with outsourced MASA and/or subCA.
> > 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.
I don't think we did design BRSKI or voucher under the expectation
that IDevID MUST include AKI.
> 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.
I thought the goal was as much as possible to allow adding BRSKI
without having to overhaul the IDevID infrastructure of devices,
but allow for BRSKI to operate for as many existing IDevIDs as possible.
> 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.
I think the same notion as from above holds true: If there is a way to
"easily" make cBRSKI work for existing IdevID, then it should help to
improve adoption of cBRSSKI. After all, BRSKI/cBRSKI are "just"
part of simple software enhancements to devices, whereas IDevID format
would impact more of the manufacturing process. So additional IDevID
requirements beyond what's already current practice are highly undesirable.
> 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.
Firstly, i am still contending we can make BRSKI perfectly work without
AKI as long as the MASA gets the necessary information from the IDevID,
such as Signer SubjectName.
Secondly, if we do not have AKI in the PVR and your argument holds true,
how then would the Registrar be able to put it into RVR - unless you
assume it's taken from the PVR embedded IDevID ?
Btw: Would be lovely once we agree on the options to have an example
PVR/RVR including all the relevant pieces of this.
rfc5280 recommends a way to generate the AKI, and thats also exactly
what i was suggesting to put into the voucher yang model explanation.
Aka: It would be the SHA-1 of the signing key taken from the certificate
chain attached to the IDevID when pledge is authenticating with the
Registrar.
And it can be anything else whenever thee pledge DOES provide the AKI,
then it's up to the pledge to decide. Aka: for AR compliant IDevID.
Thats just my thoughts..
> 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.
Sure. See above.
> 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".
If present. Yes. Else create the AKI from the signing key of the
IDevID according to the rfc5280 SHA1 rule.
> Currently, if that AKI is not there, then the cert is
> formally not an IDevID cert, and BRSKI is not supposed to execute further.
This is where we disagree.
> 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.
It's not about deployed devices IMHO. It's about allowind a much
broader base of easily BRSKI addressable devices.
> > 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.
This again raises the cost of adopting cBRKI IMHO.
And as said, i think the necessary field is "only" the
IDevID Signer SubjectName. I would hope for the benefits
it brings, we should allow to support carrying it. Then
any implementation can decide what to do: Enhance
manufacturing processes andbackend datbase process to make
it work with preferred "compliant" IDevID, or carry the additional
bytes and avoid the overhead.
> > 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.
Yes, of course. And as i said, i am not sure, how/where to best store
it in the voucher. But see above re. what you say there...
> 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.
Good idea.
> > 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.)
Not sure why you think it wold require changes to 8995. But even if so,
8366bis could claim such an update.
> > 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.
Wait... so you claim 8366 did intend to include the whole ASN.1 encoded
AuthorityKeyIdentifier structure into idevid-issuer as an OCTET STRING ???
That could solve my issue, but i fear not in a nice way, because the
way i understand it, authorityCertIssuer, authorityCertSerialNumber
would have to be the name of the rootCA nd the serialnumber of the
subCA as signed by the rootCA. So that's troubleshooting information,
but somewhat convoluted.
> 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.
I was referring to that authorityCertIssuer, authorityCertSerialNumber
info, facetiously: You would go back to the list of
certificates signed by the rootCA, look for the authorityCertSerialNumber
and then you see that the subCA is the one from the new FarOutMiddleOfNowhere
manufacturing plant, where somehow the database update failed to transmit
the keys to the MASA.
Having a SubjectName of the subCA available that includes a name element
like FarOutMiddleOfNowhere would of course make troubleshooting a lot faster.
> > 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.
See, for something like embedded devices i fear that the risk of
a vendor to quickly change manufacturers i maybe even higher than for
larger devices. High elvel, the way i imagine it, the instructions for
every new OEM manufacturer is:
a) Set up a signing CA onsite
b) for every device you build for us:
b.1) put a new IDevID into this PROM location
b.2) put your signing certificte into into this other PROM location
E.g.: imagine the worklow required to make cBRSKI work with terms/details
like this so we can compare how complex/simple it would be...
> 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
>
> >
> > 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!
> > >
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
