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.
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 ?
[ 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 ?? ]
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...
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...).
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.
So that text may need to be adjusted if we want to accept reality and
write against it.
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. 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
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
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:
"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).
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).
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.
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.
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]
