Merge branch 'fix/sb_digest_revocation_workflow_v6.1' into 'release/v6.1'

change(bootloader): honor SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS during first boot (v6.1)

See merge request espressif/esp-idf!49712

docs/en/security/flash-encryption.rst

@@ -621,7 +621,7 @@ To use a host generated key and program it into the eFuses of the device, take t
 
 .. only:: SOC_KEY_MANAGER_SUPPORTED
 
-  To use a host generated key and deploy it into the device's Key Manager of the device, take the following steps:
+  To use a host generated key and deploy it into the device's Key Manager, take the following steps:
 
   1. Ensure that you have an {IDF_TARGET_NAME} device with default flash encryption eFuse settings as shown in :ref:`flash-encryption-efuse`.
 
@@ -1224,11 +1224,11 @@ Manually Encrypting Files
 
 .. only:: SOC_KEY_MANAGER_SUPPORTED
 
-  Manually encrypting or decrypting files require the flash encryption key to be deployed in the Key Manager or pre-burned in eFuses (see :ref:`pregenerated-flash-encryption-key`) and a copy to be kept on the host. If the flash encryption is configured in development mode, then it is not necessary to keep a copy of the key or follow these steps. The simpler :ref:`encrypt-partitions` steps can be used.
+  Manually encrypting or decrypting files requires the flash encryption key to be deployed in the Key Manager or pre-burned in eFuses (see :ref:`pregenerated-flash-encryption-key`) and a copy to be kept on the host. If the flash encryption is configured in development mode, then it is not necessary to keep a copy of the key or follow these steps. The simpler :ref:`encrypt-partitions` steps can be used.
 
 .. only:: not SOC_KEY_MANAGER_SUPPORTED
 
-  Manually encrypting or decrypting files require the flash encryption key to be pre-burned in eFuse (see :ref:`pregenerated-flash-encryption-key`) and a copy to be kept on the host. If the flash encryption is configured in development mode, then it is not necessary to keep a copy of the key or follow these steps. The simpler :ref:`encrypt-partitions` steps can be used.
+  Manually encrypting or decrypting files requires the flash encryption key to be pre-burned in eFuse (see :ref:`pregenerated-flash-encryption-key`) and a copy to be kept on the host. If the flash encryption is configured in development mode, then it is not necessary to keep a copy of the key or follow these steps. The simpler :ref:`encrypt-partitions` steps can be used.
 
 The key file should be a single raw binary file (example: ``key.bin``).
 

docs/en/security/secure-boot-v2.rst

@@ -741,9 +741,7 @@ Secure Boot Best Practices
 
     .. note::
 
-        Note that enabling the config :ref:`CONFIG_SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS` only makes sure that the **app** does not revoke the unused digest slots.
-        But if you plan to enable secure boot during the fist boot up, the bootloader will intentionally revoke the unused digest slots while enabling secure boot, even if the above config is enabled. Because keeping the unused key slots unrevoked would be a security hazard.
-        In case for any development workflow if you need to avoid this revocation, you should :ref:`enable-secure-boot-v2-externally`, rather than enabling it during the boot up, so that the bootloader would not need to enable secure boot, and thus you could avoid its revocation strategy.
+        Enabling the config :ref:`CONFIG_SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS` keeps the unused digest slots un-revoked in both cases: at runtime in the **app**, and in the **bootloader** when secure boot is enabled during the first boot up. Note that leaving unused key slots un-revoked could pose a security risk, unless the debug and download interfaces are completely disabled and remote interfaces are fully audited for security risks.
 
     Conservative Approach
     ~~~~~~~~~~~~~~~~~~~~~~

docs/en/security/security.rst

@@ -311,7 +311,7 @@ Please see more information to enable this feature in the :ref:`anti-rollback` g
 Encrypted Firmware Distribution
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Encrypted firmware distribution during over-the-air updates ensures that the application stays encrypted **in transit** from the server to the the device. This can act as an additional layer of protection on top of the TLS communication during OTA updates and protect the identity of the application.
+Encrypted firmware distribution during over-the-air updates ensures that the application stays encrypted **in transit** from the server to the device. This can act as an additional layer of protection on top of the TLS communication during OTA updates and protect the identity of the application.
 
 Please see working example for this documented in :ref:`ota_updates_pre-encrypted-firmware` section.
 

docs/en/security/tee/tee.rst

@@ -76,7 +76,7 @@ ESP-TEE divides the memory into separate regions for the TEE and REE, allocating
 Internal Memory (SRAM)
 ^^^^^^^^^^^^^^^^^^^^^^
 
-Internal memory is allocated to the the TEE based on the Kconfig options that are available under the :ref:`Memory Configuration <esp-tee-trusted-execution-environment--enable-the-esp-tee-framework-memory-configuration>` section in the :ref:`esp-tee-trusted-execution-environment-` menu. All remaining memory is allocated to the REE.
+Internal memory is allocated to the TEE based on the Kconfig options that are available under the :ref:`Memory Configuration <esp-tee-trusted-execution-environment--enable-the-esp-tee-framework-memory-configuration>` section in the :ref:`esp-tee-trusted-execution-environment-` menu. All remaining memory is allocated to the REE.
 
 .. warning::