Thanks for reviewing! > Your PR goes from x5bag -> x5chain in many places, and I'm not sure I > understand why. A few places still say x5bag: I'm not sure which to pick.
It's basically changed to use x5chain to carry a certificate chain in order. Just trying to use the container as intended: x5chain is for chains (ordered), x5bag for "anything else" (including unordered chains). Previously we used x5bag to carry a chain, which should have been x5chain I believe, with ordering, so to avoid needless variation between implementations - where some implementations may order certificates and others not. > Should all instances of x5bag go away? Not all: we still use x5bag in some "SHOULD NOT contain" requirements. There it's helpful to mention both x5chain and x5bag, since 1) we've previously used x5bag ourselves and 2) otherwise there's an easy escape route from the requirement by changing x5chain to x5bag. We do have one positive use of x5bag in this sentence: A situation where the Pledge MAY use the "x5bag" or "x5chain" structure is for communication of certificate chains to the MASA. This is treading onto manufacturer-specific usage: normally this isn't needed, nor desired (size), but there could be reasons why a Pledge would need to include a certificate for MASA consumption. It can then use any COSE defined extensions/mechanisms in principle and the manufacturer could decide to use "x5bag" if the Pledge is for code/memory reasons or so not ordering the certificates. > I also wondered if there is any value in the self-signed RPK mechanism. > The Registrar can't really trust anything in the unprotected header, but I > guess if it hasn't got the RPK via some other way, then at minimum this lets > it verify the signature. The voucher arrived via HTTPS anyway. > So I do not object to including this instruction. The text was written with "live" (nonced) voucher creation in mind. There's a TLS protected session between Registrar and MASA, so the certificate / chain in the unprotected COSE "x5chain" container is protected by TLS (integrity). In the case that Vouchers are distributed non-live, they could go via unsecured data channels such as email or USB drives. We should maybe look at this case in more detail: in some specific cases, the Registrar can validate that the unprotected "x5chain" container hasn't been tampered with: 1. if the x5chain contains a single self-signed certificate. The Registrar can use the public key of the cert to directly check the cert itself, and check that the same public key also did sign the Voucher. 2. if the x5chain contains, or chains with, a known trust anchor of the vendor/MASA that the Registrar has stored. Esko -----Original Message----- From: Michael Richardson <[email protected]> Sent: dinsdag 25 februari 2025 20:24 To: Esko Dijk <[email protected]>; [email protected] Subject: Re: [Anima] cBRSKI: new proposal for carrying signing certificate chains in RVR/Voucher Esko Dijk <[email protected]> wrote: > For cBRSKI I've created a new PR: > https://github.com/anima-wg/constrained-voucher/pull/325 I reviewed. > 1. We want the equivalent of certificate chains as carried in CMS > signing envelope on the unconstrained network path 2. We don't want > these lengthy certificate chains carried on the constrained network > path (by default), to save bytes/time. 3. We'd like MASA to be able > to sign a voucher with an arbitrary certificate chain, or self-signed > CA, or a raw public/private keypair. 4. Registrar should be able to > easily retrieve MASA's signing method/chain, whatever it was. Right, and remove the extra stuff, and you've done a good job there. > As a solution the "x5chain" attribute from RFC 9360 is now used to > carry a certificate / chain that was used for signing. And a Registrar Your PR goes from x5bag -> x5chain in many places, and I'm not sure I understand why. A few places still say x5bag: I'm not sure which to pick. Should all instances of x5bag go away? I also wondered if there is any value in the self-signed RPK mechanism. The Registrar can't really trust anything in the unprotected header, but I guess if it hasn't got the RPK via some other way, then at minimum this lets it verify the signature. The voucher arrived via HTTPS anyway. So I do not object to including this instruction. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
