We've discussed this exact idea in 2022/2023 - it is captured in the issue
https://github.com/anima-wg/constrained-voucher/issues/239 .
This was marked as future update for cBRSKI, because it would require extending
the base BRSKI protocol and its resources.
With that resource available, in cBRSKI the Pledge could perform a DTLS
handshake while sending only 1 certificate to the Registrar: its IDevID EE
certificate.
(This reduces the size of the entire onboarding exchange quite a bit.)
All the rest in the chain can then be fetched by the Registrar by doing a /crts
request to MASA, using the MASA URI provided.
The extreme reduction case I mention does have a slight security/privacy
disadvantage: the Registrar can't evaluate the cert chain as a whole prior to
deciding whether to contact the MASA URI, or not.
I.e. the MASA/vendor can potentially harvest more sensitive data about what its
customers are trying to do.
There's also less extreme scenarios possible of course e.g. where only the root
CA is elided in the handshake.
> That would keep the size of the subordinate certificates out of the BRSKI-EST.
Just to note on this: In cBRSKI, this size is only included once in the
handshake traffic. Certificates are not present in the signed PVR - only a
signature is there.
Esko
-----Original Message-----
From: Michael Richardson <mcr+i...@sandelman.ca>
Sent: woensdag 15 januari 2025 19:35
To: Esko Dijk <esko.d...@iotconsultancy.nl>; anima@ietf.org
Subject: Re: [Anima] Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements on
signing the PVR
Esko Dijk <esko.d...@iotconsultancy.nl> wrote:
> We have some discussion (to be continued) whether the Registrar can be
> expected to be preloaded with all CAs in the chains, or a subset of
> only the highest sub-CAs, or only the root CA ? The more the Registrar
> already knows, the less the Pledge has to send in its PVR, given that
> the MASA would know all its own CAs for sure.
I wonder if we should mandate that the MASA be willing to answer a /crts
request (on the BRSKI-MASA protocol) which the complete list of all CAs and
subordinate CAs.
That would keep the size of the subordinate certificates out of the BRSKI-EST.
That's important today for cBRSKI, but later on, in a quantum-safe world, it
might also matter to (fat)BRSKI.
You convinced me on Tuesday that I should ask for adoption of the operational
considerations documents already. But the above proposal goes beyond
operation *considerations*, right?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
