Add adoption guidance section (#62)

Co-authored-by: Daniel Huigens <d.huigens@protonmail.com>

Author: panva

index.html

@@ -110,6 +110,16 @@
         "href": "https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-certificates/",
         "publisher": "IETF"
       },
+      "draft-ietf-hpke-pq": {
+        "title": "Post-Quantum Hybrid Key Encapsulation Mechanisms for HPKE",
+        "href": "https://datatracker.ietf.org/doc/draft-ietf-hpke-pq/",
+        "publisher": "IETF"
+      },
+      "draft-ietf-hpke-hpke": {
+        "title": "Hybrid Public Key Encryption",
+        "href": "https://datatracker.ietf.org/doc/draft-ietf-hpke-hpke/",
+        "publisher": "IETF"
+      },
     },
   };
   </script>
@@ -7543,6 +7553,90 @@ <h3>JSON Web Key Operations</h3>
     </section>
   </section>
 
+  <section id="adoption-guidance" class="informative">
+    <h2>Adoption Guidance</h2>
+    <p>
+      This specification defines many algorithms and operations. To provide
+      guidance to implementers and to accelerate the post-quantum transition
+      of the Web platform, this section recommends which algorithms and
+      operations to prioritize for implementation.
+    </p>
+    <p>
+      The <a href="#dfn-SubtleCrypto-method-supports">`SubtleCrypto.supports`</a>
+      method simplifies the expedited adoption of every other algorithm and
+      operation in this specification by enabling feature detection, graceful
+      fallback, and progressive enhancement.
+    </p>
+    <p>
+      The <a href="#dfn-SubtleCrypto-method-getPublicKey">`SubtleCrypto.getPublicKey`</a>
+      method is important for practical use of asymmetric algorithms defined
+      in this specification and [[webcrypto]]. It simplifies key management
+      by enabling applications to only store the private key without the
+      corresponding public key, and without having to verify that the private
+      and public key do indeed correspond. Furthermore, it allows library
+      authors to accept non-extractable private keys as input to protocols
+      that commit the public key value to their outputs.
+    </p>
+    <p>
+      In terms of algorithms, the following are considered the highest
+      priority for the post-quantum transition and for enabling modern
+      cryptographic protocols on the Web, in order of priority:
+    </p>
+    <ol>
+      <li>
+        <a href="#ml-kem">ML-KEM</a> is the primary post-quantum key
+        encapsulation mechanism standardized by NIST [[FIPS-203]].
+        Combined with traditional key agreement, it enables hybrid
+        post-quantum/traditional (PQ/T) key establishment as used in
+        protocols like [[draft-ietf-hpke-hpke]] and its PQ and PQ/T
+        algorithms [[draft-ietf-hpke-pq]].
+      </li>
+      <li>
+        <a href="#ml-dsa">ML-DSA</a> is the primary post-quantum digital
+        signature algorithm standardized by NIST [[FIPS-204]].
+      </li>
+      <li>
+        <a href="#chacha20-poly1305">ChaCha20-Poly1305</a> is a widely
+        deployed AEAD cipher [[RFC8439]] used across many protocols
+        (TLS, SSH, WireGuard, HPKE).
+      </li>
+      <li>
+        <a href="#sha3">SHA-3</a> and <a href="#cshake">cSHAKE</a>
+        (specifically SHA3-256 and cSHAKE256) are used in many post-quantum
+        constructions including ML-KEM key derivation and hybrid KEM
+        combiners. Notably, cSHAKE256 invoked without any customization
+        parameters produces output identical to SHAKE256, making a single
+        implementation sufficient for both customized (cSHAKE256) and
+        non-customized (SHAKE256) use cases.
+        However, if an implementation of cSHAKE is not available, an
+        implementation of SHAKE may still prove useful, when making sure
+        to throw a {{NotSupportedError}} (and return `false` from
+        <a href="#dfn-SubtleCrypto-method-supports">`SubtleCrypto.supports`</a>)
+        when the {{CShakeParams/customization}} parameter is present and
+        non-empty.
+      </li>
+      <li>
+        <a href="#argon2">Argon2</a> is a memory-hard password-based
+        key derivation function [[RFC9106]], providing improved resistance
+        against brute force attacks in highly parallelized environments
+        (such as GPUs and FPGAs).
+      </li>
+    </ol>
+    <p>
+      <a href="#slh-dsa">SLH-DSA</a> is a stateless hash-based digital
+      signature algorithm standardized by NIST [[FIPS-204]]. It has
+      seen less adoption than ML-DSA so far, but may become useful to
+      implement if an alternative to ML-DSA becomes needed.
+    </p>
+    <p>
+      Beyond these, <a href="#aes-ocb">AES-OCB</a>,
+      <a href="#turboshake">TurboSHAKE</a>,
+      <a href="#kangarootwelve">KangarooTwelve</a>, and
+      <a href="#kmac">KMAC</a> are all valuable additions but are not as
+      immediately critical for the post-quantum transition.
+    </p>
+  </section>
+
   <section>
     <h2>Usage Example</h2>
     <p>