diff --git a/book/source/06-certifications.md b/book/source/06-certifications.md
index 4e0c7b1..6c61f7b 100644
--- a/book/source/06-certifications.md
+++ b/book/source/06-certifications.md
@@ -56,10 +56,12 @@ Data signatures are always calculated using a **S**igning key.
 
 Certifications are separated into *self-certifications* and *third-party certifications*.
 A certification made by a key over components of the same certificate is referred to as a *self-certification*.
-:::{note}
-The **C**certify Others key flag is not required in order to issue self-certifications.
+
+```{note}
+The **C**ertify Others key flag is not required in order to issue self-certifications.
 It is only necessary to issue valid third-party certifications.
-:::
+```
+
 A typical use-case for a self-certification is to attach a User ID, such as a name and email address to a certificate.
 This is done by calculating the signature over the User ID and the public primary key.
 The resulting User ID certification (typically type 0x13, potentially type 0x10-0x12) can then be inserted into the certificate, right after the User ID packet.
@@ -309,9 +311,11 @@ There are some subpackets that are expected to be included in any type of signat
 * **Signature Creation Time**: Every OpenPGP signature MUST contain a Signature Creation Time subpacket (2) containing the timestamp at which the signature was made. This packet MUST be present in the hashed area of the signature and SHOULD be marked as critical.
 
 * **Issuer Fingerprint**: In order to be able to verify a signature, the verifier needs to know, which (sub-)key was used to issue the signature in the first place. Therefore, every OpenPGP v6 signature SHOULD contain an Issuer Fingerprint subpacket (33) containing the 32 byte fingerprint of the particular component key that was used to create the signature.
-:::{note}
+
+```{note}
 The issuer key might be a subkey.
-:::
+```
+
 Since the issuer fingerprint subpacket is self-authenticating, it can either be included as a hashed or unhashed subpacket, but the authors of this book recommend to place it in the hashed area of the signature.
 
 ### Potential conflicts and duplication
@@ -325,7 +329,7 @@ In some cases, duplicate packets with conflicting content even make sense, e.g.
 In this case, either the v3 or v4 key could be used to validate the v4 signature, but since the key ID calculation scheme was changed between v3 and v4, these identifiers would differ.
 Therefore, the signature could contain two isuer key ID subpackets with conflicting, but correct values.
 
-```{admonition}
+```{admonition} TODO
 :class: warning
 
 - Key Flags