auto-ingest: ietf-elements backfill — 233 new elements (2026-07-12)

Author: ietf-corpus-bot

corpus/elements/rfc-9729__design-rationale-authentication-checks-can-introduce-timing-side-channels-an.yaml

@@ -0,0 +1,11 @@
+document: rfc-9729
+kind: design-rationale
+summary: 'Authentication checks can introduce timing side-channels: an attacker can compare response timing for known-nonexistent resources versus potentially authenticated resources. Servers should slightly delay responses to some nonexistent resources to mask authentication verification time, but must avoid making the delay itself reveal that this mechanism is in use.'
+section: "6.4"
+topics:
+    - http
+    - security
+    - privacy
+    - measurement
+extracted_by: claude-sonnet-4-6
+extracted_at: "2026-07-12"

corpus/elements/rfc-9729__design-rationale-existing-signature-based-http-authentication-schemes-e-g.yaml

@@ -0,0 +1,11 @@
+document: rfc-9729
+kind: design-rationale
+summary: Existing signature-based HTTP authentication schemes (e.g., HOBA) require the server to send a fresh nonce/challenge to the client, which reveals that authentication is expected. The Concealed scheme instead derives freshness from a TLS keying material exporter, allowing the server to never issue a challenge and thus remain non-probeable.
+section: "1"
+topics:
+    - http
+    - tls
+    - security
+    - privacy
+extracted_by: claude-sonnet-4-6
+extracted_at: "2026-07-12"

corpus/elements/rfc-9729__design-rationale-the-a-parameter-public-key-included-in-the.yaml

@@ -0,0 +1,10 @@
+document: rfc-9729
+kind: design-rationale
+summary: The 'a' parameter (public key included in the Authorization header) avoids key confusion issues identified in the 'Seems Legit' paper, where an attacker could trick a server into accepting a signature computed for a different key. The 'v' parameter similarly guards against signature schemes where certain keys can produce signatures valid for multiple inputs.
+section: "4.2"
+topics:
+    - http
+    - crypto
+    - security
+extracted_by: claude-sonnet-4-6
+extracted_at: "2026-07-12"

corpus/elements/rfc-9729__design-rationale-the-static-prefix-64-x-0x20-context-string.yaml

@@ -0,0 +1,11 @@
+document: rfc-9729
+kind: design-rationale
+summary: The static prefix (64 x 0x20 + context string + zero separator) prepended before signing mirrors the TLS 1.3 CertificateVerify construction. Its purpose is to mitigate issues that could arise if authentication keys were accidentally reused across protocols, even though such reuse is explicitly forbidden.
+section: "3.3"
+topics:
+    - http
+    - tls
+    - crypto
+    - security
+extracted_by: claude-sonnet-4-6
+extracted_at: "2026-07-12"

corpus/elements/rfc-9729__interoperability-note-the-concealed-authentication-scheme-is-only-defined-for.yaml

@@ -0,0 +1,10 @@
+document: rfc-9729
+kind: interoperability-note
+summary: The Concealed authentication scheme is only defined for HTTP over TLS, including HTTP/2 over TLS and HTTP/3 (where QUIC uses TLS for key exchange). It is not defined for cleartext HTTP.
+section: "7"
+topics:
+    - http
+    - tls
+    - quic
+extracted_by: claude-sonnet-4-6
+extracted_at: "2026-07-12"

corpus/elements/rfc-9729__normative-requirement-byte-sequence-authentication-parameter-values-must-not-include.yaml

@@ -0,0 +1,9 @@
+document: rfc-9729
+kind: normative-requirement
+summary: Byte-sequence authentication parameter values MUST NOT include any characters other than ASCII letters, digits, dash, and underscore (base64url without padding). The integer parameter value MUST NOT include any characters other than digits and MUST NOT start with a zero unless the full value is '0'.
+section: "4"
+rfc2119_level: MUST NOT
+topics:
+    - http
+extracted_by: claude-sonnet-4-6
+extracted_at: "2026-07-12"

corpus/elements/rfc-9729__normative-requirement-clients-must-not-use-the-concealed-http-authentication.yaml

@@ -0,0 +1,11 @@
+document: rfc-9729
+kind: normative-requirement
+summary: Clients MUST NOT use the Concealed HTTP authentication scheme on connections that do not use TLS >= 1.3, or TLS 1.2 without the extended master secret extension (RFC 7627). If a server receives such a request, it MUST treat the authentication as not present.
+section: "7"
+rfc2119_level: MUST NOT
+topics:
+    - http
+    - tls
+    - security
+extracted_by: claude-sonnet-4-6
+extracted_at: "2026-07-12"

corpus/elements/rfc-9729__normative-requirement-for-rsassa-pss-algorithms-ber-encodings-of-the.yaml

@@ -0,0 +1,11 @@
+document: rfc-9729
+kind: normative-requirement
+summary: For RSASSA-PSS algorithms, BER encodings of the public key that are not also DER MUST be rejected.
+section: 3.1.1
+rfc2119_level: MUST
+topics:
+    - http
+    - crypto
+    - pkix
+extracted_by: claude-sonnet-4-6
+extracted_at: "2026-07-12"

corpus/elements/rfc-9729__normative-requirement-http-servers-that-parse-the-concealed-auth-export.yaml

@@ -0,0 +1,10 @@
+document: rfc-9729
+kind: normative-requirement
+summary: HTTP servers that parse the Concealed-Auth-Export header field MUST ignore it unless they have already established that they trust the sender. Frontends that send Concealed-Auth-Export MUST ensure they do not forward any Concealed-Auth-Export header field received from the client.
+section: "6.2"
+rfc2119_level: MUST
+topics:
+    - http
+    - security
+extracted_by: claude-sonnet-4-6
+extracted_at: "2026-07-12"

corpus/elements/rfc-9729__normative-requirement-if-any-of-the-backend-s-five-validation.yaml

@@ -0,0 +1,10 @@
+document: rfc-9729
+kind: normative-requirement
+summary: If any of the backend's five validation checks fail (parameter parsing, key ID lookup, public key match, verification field match, or cryptographic signature), the backend MUST treat the request as if the Authorization (or Proxy-Authorization) header field was missing.
+section: "6.3"
+rfc2119_level: MUST
+topics:
+    - http
+    - security
+extracted_by: claude-sonnet-4-6
+extracted_at: "2026-07-12"