Add PKCS#7 certificate-chain validation

Add support for PKCS#7/CMS SignedData signatures as an alternative to
direct key-based verification. This enables a chain-of-trust model
similar to UEFI Secure Boot and is Authenticode-compatible.

This adds a new optional 'format' property in the signature node, which
can be used to select 'direct' (default, existing behavior) or 'pkcs7',
as well as an integer 'generation' for revocation

For pkcs7 format, the certificate chain is embedded in the SignedData
structure. Validation must include verification of the certificate chain
verification up to trusted root, checking of the validity period and
generation-based revocation.

Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>

Author: sjg20

source/chapter2-source-file-format.rst

@@ -148,7 +148,6 @@ Mandatory nodes
     Contains a set of available configuration nodes and
     defines a default configuration.
 
-
 '/images' node
 --------------
 
@@ -645,13 +644,24 @@ not* be specified in a configuration node.
 Configuration-signature nodes
 -----------------------------
 
-::
+Direct format (default)::
 
     o signature-1
         |- algo = "algorithm name"
         |- key-name-hint = "key name"
         |- sign-images = "path1", "path2";
-        |- value = [hash or checksum value]
+        |- value = [signature value]
+        |- hashed-strings = <0 len>
+
+PKCS#7 format::
+
+    o signature-1
+        |- algo = "algorithm name"
+        |- format = "pkcs7"
+        |- compatible = "vendor,product-signing"
+        |- generation = <1>
+        |- sign-images = "path1", "path2";
+        |- value = [PKCS#7 SignedData]
         |- hashed-strings = <0 len>
 
 
@@ -661,11 +671,40 @@ Mandatory properties
 algo
     See `FIT Algorithm`_.
 
+Optional properties
+~~~~~~~~~~~~~~~~~~~
+
+format
+    Signature format. Supported values:
+
+    =========== ==============================================================
+    Format      Meaning
+    =========== ==============================================================
+    direct      Direct signature verification (default). The public key is
+                stored in the bootloader.
+    pkcs7       PKCS#7/CMS SignedData structure (Authenticode-compatible).
+                The certificate chain is embedded in the ``value`` property.
+    =========== ==============================================================
+
+compatible
+    Identifies the signing authority for generation-based revocation.
+    The bootloader maintains a minimum acceptable generation per compatible
+    string, allowing different signing authorities to manage revocation
+    independently.
+    See :ref:`certificate_revocation`.
+
+generation
+    Integer generation number for revocation purposes.
+    The bootloader maintains a minimum acceptable generation per ``compatible``
+    value; signatures with a generation below this minimum are rejected.
+    See :ref:`certificate_revocation`.
+
 key-name-hint
-    Name of key to use for signing. The keys will normally be in
-    a single directory (parameter -k to mkimage). For a given key <name>, its
-    private key is stored in <name>.key and the certificate is stored in
-    <name>.crt.
+    Hint for the bootloader indicating which key to use for verification.
+    The keys will normally be in a single directory (parameter -k to mkimage).
+    For a given key <name>, its private key is stored in <name>.key and the
+    certificate is stored in <name>.crt.
+    This is optional; the bootloader may locate the key through other means.
 
 The following properties are added as part of signing, and are mandatory:
 

source/chapter3-usage.rst

@@ -252,4 +252,103 @@ For more information on FIT security, see
 The mechanism is also widely covered in conference talks, some of which are
 listed at `elinux.org <https://elinux.org/Boot_Loaders#U-Boot>`_.
 
+.. _certificate_chain_validation:
+
+Certificate chain validation
+----------------------------
+
+FIT supports certificate chain validation as an alternative to direct public
+key verification.
+This enables a chain-of-trust model similar to Authenticode with UEFI Secure
+Boot.
+
+When the signature's ``format`` property is ``pkcs7``, the ``value`` property
+contains a PKCS#7/CMS SignedData structure (as used by Authenticode).
+The certificate chain is embedded within the SignedData.
+
+Validation proceeds as follows:
+
+#. Parse the PKCS#7 SignedData structure from the ``value`` property
+#. Extract the signing certificate and any intermediate certificates
+#. Verify the signature using the signing certificate's public key
+#. Walk the certificate chain, verifying each certificate's signature against
+   its issuer's public key
+#. Verify the root certificate is trusted by checking its hash against the
+   bootloader's trust store
+#. Verify each certificate's validity period (NotBefore/NotAfter) against
+   the current time, if a reliable time source is available
+#. Verify each certificate includes the Code Signing Extended Key Usage (EKU)
+   extension (OID ``1.3.6.1.5.5.7.3.3``)
+#. Check the signature's ``generation`` property against the bootloader's
+   minimum acceptable generation (see :ref:`certificate_revocation`)
+
+If any step fails, the signature must be rejected.
+
+This format enables compatibility with existing Authenticode tooling and
+workflows.
+
+Trust anchors
+~~~~~~~~~~~~~
+
+The bootloader stores trusted root CA certificate hashes in the same secure
+storage used for direct public keys (e.g., UEFI secure variables or U-Boot's
+control FDT). A root certificate is trusted if its SHA-256 hash matches one in
+the trust store.
+
+Extended Key Usage
+~~~~~~~~~~~~~~~~~~
+
+Certificates used for FIT signing must include the Code Signing EKU extension
+(OID ``1.3.6.1.5.5.7.3.3``, id-kp-codeSigning).
+This is the same OID used by Authenticode and UEFI Secure Boot.
+It prevents certificates issued for other purposes (e.g., TLS, email) from
+being misused to sign firmware images.
+
+Intermediate CA certificates in the chain should include the
+``anyExtendedKeyUsage`` OID or the Code Signing OID.
+
+.. _certificate_revocation:
+
+Certificate revocation
+----------------------
+
+FIT uses generation-based revocation for simplicity.
+
+The signature node includes:
+
+- ``compatible``: identifies the signing authority (e.g.,
+  ``"vendor,product-signing"``)
+- ``generation``: integer generation number
+
+The bootloader maintains a minimum acceptable generation per ``compatible``
+value in secure storage.
+This allows different signing authorities to manage revocation independently;
+one vendor can revoke old signatures without affecting another vendor's
+signatures.
+
+During validation, the bootloader:
+
+#. Looks up the minimum generation for the signature's ``compatible`` value
+#. Rejects the signature if its ``generation`` is less than the stored minimum
+
+To revoke, the system administrator increments the minimum generation for a
+specific ``compatible`` value in the bootloader's secure storage;
+all signatures with that ``compatible`` and lower generation numbers become
+invalid.
+
+This approach has several advantages:
+
+- Simple to implement (integer comparison per signing authority)
+- No need to track individual revoked certificate serial numbers
+- No network access required (unlike OCSP)
+- Deterministic and fast
+- Multiple signing authorities can coexist
+
+To revoke and re-issue:
+
+#. Issue new signatures with a higher generation number
+#. Update the FIT with new signatures
+#. Increment the bootloader's minimum generation for that ``compatible`` value
+#. All older signatures from that authority are now rejected
+
 .. sectionauthor:: Simon Glass <sjg@chromium.org>