Hoi, > > On Fri, 2024-11-01 at 13:05 +0100, Johannes Schneider via > lists.openembedded.org wrote: > > Add handling of ca-chains which can consist of more than one > > certificate in a .pem file, which need to be split off, processed and > > stored separately in the softhsm - as the tool-chain > > signing.bbclass::signing_import_cert* -> softhsm -> 'extract-cert' > > only supports one-per-file, due to using/expecting "plain" x509 > > in-/output. > > > > The added signing_import_cert_chain_from_pem function takes a <role> > > basename, and iterates through the input .pem file, creating numbered > > <role>_1, _2, ... roles as needed. > > Why do you want to import certificates without corresponding private > keys into the singing mechanism? > > They can't be used for signing, so don't really fit the role concept as > I intended it. This mismatch then leads to workarounds such as the _N > suffix and the problem below. >
During a (yocto) build, there can be places where the key is used to sign something, and other places where the corresponding certificate is inserted/used to verify the former - so there are two different "consumers" of one role; e.g. the kernel fitimage is signed with A.key, and at bootloader build time A.cert is inserted into the bootloader so that it can later verify what it is supposed to load. Now the bootloader<>kernel uscase is simple, because there is no verification of the certificate; e.g. there is no need to provide the complete chain. But other usecases sign $something during buildtime, and at runtime this artifact would then be verified against a certificate, which in turn would need to be verified against it's CA-chain. By keeping the leaf (key+cert) plus all links (just the cert) up the certificate chain, the softhsm can be used as "single source of keymaterial". Otherwise there could be a rift between taking the keys from the softhsm during buildtime, but takeing the certificate (-chains) from $elsewhere. > > > Afterwards the certificates can be used or extracted one-by-one from > > the softhsm, using the numbered roles; the only precondition - or > > limitation - is that the PKI structure has to be known beforhand; > > e.g. how many certificates are between leaf and root. > > The point of the signing.bbclass is to abstract over different HSMs and > allow flexible key selection at the .conf level. > > With this approach, any recipe using this set of generated > (certificate-only) roles now needs to know how long the chain is and > the PKIs with different layouts are no longer possible. > That is the one caveat - the layout has to be the same and known beforehand; should we add more logic=complexity into the class to detect and handle this (... i guess: no ;-)? > > Could you describe you use-case in detail? I think we should try to > find a design which avoids using roles for certificate chains, while > also allowing different PKI layouts between SoftHSM and actual HSMs. > We have a build setup that, depending on a build-configuration switch, uses either development-keymaterial, or production-keymaterial. So the (soft)HSM encapsuled by the signing.bbclass and it's roles becomes the common interface through which all keymaterial is requested for artifact-signing purposes, or certificate (chains) are gathered to populate e.g. the rootfs with, for use during system runtime. The intended usecase of the signing.bbclass is certainly to swith around the actual underlying HSMs (e.g. have a softhsm with devkeys, but a "real" HSM for the production usecase) - but due to limitations with our CI infrastructure... we only have a secured channel to fetch the productive keymaterial, but still need/intend to use the softhsm to "secure" the keymaterial on the CI during build-time. > > Signed-off-by: Johannes Schneider <[email protected]> > > --- > > meta-oe/classes/signing.bbclass | 30 ++++++++++++++++++++++++++++++ > > 1 file changed, 30 insertions(+) > > > > diff --git a/meta-oe/classes/signing.bbclass > > b/meta-oe/classes/signing.bbclass > > index 3e662ff73..8af7bbf8e 100644 > > --- a/meta-oe/classes/signing.bbclass > > +++ b/meta-oe/classes/signing.bbclass > > @@ -134,6 +134,36 @@ signing_import_cert_from_der() { > > signing_pkcs11_tool --type cert --write-object "${der}" --label > > "${role}" > > } > > > > +# signing_import_cert_chain_from_pem <role> <pem> > > +# > > + > > +# Import a certificate *chain* from a PEM file to a role. > > +# (e.g. multiple ones concatenated in one file) > > +# > > +# Due to limitations in the toolchain: > > +# signing class -> softhsm -> 'extract-cert' > > +# the input certificate is split into a sequentially numbered list of > > roles, > > +# starting at <role>_1 > > +# > > +# (The limitations are the conversion step from x509 to a plain .der, and > > +# extract-cert expecting a x509 and then producing only plain .der again) > > +signing_import_cert_chain_from_pem() { > > + local role="${1}" > > + local pem="${2}" > > + local i=1 > > + > > + cat "${pem}" | \ > > + while openssl x509 -inform pem -outform der -out > > ${B}/temp_${i}.der; do > > + signing_import_define_role "${role}_${i}" > > Calling signing_import_define_role() from an import function breaks the > separation and ordering we currently use (first > signing_import_define_role(), then import certs/keys) and is surprising > compared to the existing signing_import_define_role() > That is true... got any advice/ideas on how to handle this? This way the PKI layout = the certificate chain lenght, has not to be known at the time of the import, but only when using the roles. A separate signing_import_define_N_roles(N) to have them prepared "blindly" ahead of time? > > Regards > Jan > > > + signing_pkcs11_tool --type cert \ > > + --write-object ${B}/temp_${i}.der \ > > + --label "${role}_${i}" > > + rm ${B}/temp_${i}.der > > + echo "imported ${pem} under role: ${role}_${i}" > > + i=$(awk "BEGIN {print $i+1}") > > + done > > +} > > + > > # signing_import_cert_from_pem <role> <pem> > > # > > # Import a certificate from PEM file to a role. To be used > > > gruß Johannes
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#114083): https://lists.openembedded.org/g/openembedded-devel/message/114083 Mute This Topic: https://lists.openembedded.org/mt/109331453/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
