Add RFC 8126 to normative references

RFC 8126 (IANA Considerations guidelines) was used inline
but missing from the normative references list.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

draft-nennemann-wimse-execution-context-00.md

@@ -28,6 +28,7 @@ normative:
   RFC7517:
   RFC7519:
   RFC7518:
+  RFC8126:
   RFC9562:
   RFC9110:
   I-D.ietf-wimse-arch:
@@ -573,9 +574,12 @@ parent reference in the ECT store.
 ### Extensions {#extension-claims}
 
 ext:
-: OPTIONAL.  Object.  An extension object for domain-specific
-  claims not defined by this specification.  Implementations
-  that do not understand extension claims MUST ignore them.
+: OPTIONAL.  Object.  An extension object for claims beyond the
+  core registered claims.  This specification defines several
+  extension keys for policy evaluation ({{policy-claims}}) and
+  operational metadata; deployments MAY also include
+  domain-specific keys.  Implementations MUST ignore extension
+  keys they do not recognize.
 
 To avoid key collisions between different domains, extension
 key names SHOULD use reverse domain notation (e.g.,
@@ -1543,7 +1547,7 @@ require separate JWT Claims registration.
 
 This document establishes the "ECT Policy Decision Values"
 registry under the "JSON Web Token (JWT)" group.  Registration
-policy is Specification Required per {{!RFC8126}}.
+policy is Specification Required per {{RFC8126}}.
 
 The initial contents of the registry are:
 
@@ -1671,7 +1675,7 @@ registered as a SCITT Signed Statement on a Transparency Service.
 This enables auditors to verify both the individual execution
 steps (via ECT DAG validation) and the end-to-end supply chain
 integrity (via SCITT Receipts) using the "wid" as the shared
-correlation point.  The "ext" claim in ECTs ({{exec-claims}})
+correlation point.  The "ext" claim in ECTs ({{extension-claims}})
 can carry SCITT-specific metadata such as Transparency Service
 identifiers or Receipt references for tighter integration.