docs: Apply updates from code review

Add some nitpicks from AdityaHPatwardhan.

Co-authored-by: Aditya Patwardhan <[email protected]>

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

@@ -610,7 +610,7 @@ Secure Boot Best Practices
  --------------
 
  * Keys are processed in a linear order, i.e., key #0, key #1, key #2.
- * After revoking a key, all remaining unrevoked keys can be used to sign applications. I.e, if key #1 gets revoked, both keys #0 and key #2 can still be used to sign firmwares.
+ * When a key is revoked, all remaining unrevoked keys can still be used to sign applications. For instance, if key #1 is revoked, keys such as key #0 and key #2 will remain valid for signing the application.
  * Applications should be signed with only one key at a time, to minimize the exposure of unused private keys.
  * The bootloader can be signed with multiple keys from the factory.
 
@@ -637,8 +637,8 @@ Secure Boot Best Practices
 
  .. note::
 
- It can be necessary to revoke a key that isn't currently being used. For example: if the running application is still signed with key #0, but key #1 becomes compromised, you should revoke this key using this approach.
- The new OTA update should still be signed with key #0, but the API `esp_ota_revoke_secure_boot_public_key(SECURE_BOOT_PUBLIC_KEY_INDEX_[N])` can be used to revoke the key #N. Afterwards all remaining unrevoked keys can be used to sign future applications.
+ It may be necessary to revoke a key that isn't currently being used.
+ For example, if the active application is signed with key #0, but key #1 becomes compromised, you should revoke key #1 by using the above approach. The new OTA update should continue to be signed with key #0, and the API `esp_ota_revoke_secure_boot_public_key(SECURE_BOOT_PUBLIC_KEY_INDEX_[N])` can be used to revoke the key #N (N would be 1 in this case). After revoking, all remaining unrevoked keys can still be used to sign future applications.
 
 
  .. _secure-boot-v2-aggressive-key-revocation: