fix(pcapng): TLSKeyLabel has drifted from RFC 9850's IANA registry -- RSA spurious, ECH_SECRET and ECH_CONFIG missing #882

Describe the bug

TLSKeyLabel (pcapkit/protocols/misc/pcapng.py:273) has drifted from its registry in both directions. Its 9 members match the Mozilla NSS key-log wiki page that pcapkit/vendor/pcapng/secrets_type.py:26 cites in a comment — but the pcapng spec no longer points there. draft-ietf-opsawg-pcapng-06 (2026-09-19) §4.7 references what is now RFC 9850, "The SSLKEYLOGFILE Format for TLS", whose §4.2 creates an IANA registry, "TLS SSLKEYLOGFILE Labels", administered by Specification Required.

Against that registry:

• we carry RSA, which has no row in it (an NSS-only label the NSS page itself records as removed in NSS 3.34);
• we are missing ECH_SECRET and ECH_CONFIG, both registered by RFC 9850.

Reproduction

$ curl -s https://www.rfc-editor.org/rfc/rfc9850.txt | grep -c 'ECH_SECRET\|ECH_CONFIG'
$ python -c "from pcapkit.protocols.misc.pcapng import TLSKeyLabel as T; print('RSA' in T.__members__, 'ECH_SECRET' in T.__members__)"
True False

TLSKeyLabel('ECH_SECRET') therefore raises ValueError on a pcapng Decryption Secrets Block that RFC 9850 makes legitimate. The lookup is TLSKeyLabel(label.upper()) at pcapkit/protocols/schema/misc/pcapng.py:2108, and that class has no _missing_, so it is a hard raise rather than a degraded parse.

Expected behavior

The member set tracks RFC 9850's registry: ECH_SECRET and ECH_CONFIG present, and RSA either dropped or explicitly documented as an NSS-historical label kept for reading old key logs. The docstring should cite RFC 9850 rather than nothing, and vendor/pcapng/secrets_type.py:26's # NSS Key Log Format comment should be repointed.

System information

• Python 3.14.7, CPython, pcapkit from a checkout at 6102bf43f.

Additional context

Found while verifying whether this enum is open or closed for #877 — the answer turned out to be open, which also means it is not a helper enum under that issue's criteria but an IANA-registered table, so it is a candidate for vendor-crawler generation rather than for #877's immutability ruling. RFC 9850's registry is Specification Required, so it will keep moving. WireGuardKeyLabel was checked at the same time and is genuinely closed (draft-ietf-opsawg-pcapng-06 §4.7, "The key type is one of …", 4/4 exact match) — no change needed there.