[GNAP] [Technical Errata Reported] RFC9635 (8198)
RFC Errata System <rfc-editor@rfc-editor.org> Wed, 04 December 2024 17:30 UTC
Return-Path: <wwwrun@rfcpa.rfc-editor.org>
X-Original-To: txauth@ietf.org
Delivered-To: txauth@ietfa.amsl.com
Received: from rfcpa.rfc-editor.org (unknown [167.172.21.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3085AC151995; Wed, 4 Dec 2024 09:30:36 -0800 (PST)
Received: by rfcpa.rfc-editor.org (Postfix, from userid 461) id 8748E1BE96E; Wed, 4 Dec 2024 09:30:35 -0800 (PST)
To: ietf@justin.richer.org, fabien.imbault@acert.io, debcooley1@gmail.com, paul.wouters@aiven.io, yaronf.ietf@gmail.com, leifj@sunet.se
From: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20241204173035.8748E1BE96E@rfcpa.rfc-editor.org>
Date: Wed, 04 Dec 2024 09:30:35 -0800
Message-ID-Hash: TC7SPZRQWCXO2HUZB77JOEOG62KF5N2N
X-Message-ID-Hash: TC7SPZRQWCXO2HUZB77JOEOG62KF5N2N
X-MailFrom: wwwrun@rfcpa.rfc-editor.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: iana@erinshepherd.net, txauth@ietf.org, rfc-editor@rfc-editor.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [GNAP] [Technical Errata Reported] RFC9635 (8198)
List-Id: GNAP <txauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/1LapSLkEtwg3ekNkVK9xTNJlJaw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Owner: <mailto:txauth-owner@ietf.org>
List-Post: <mailto:txauth@ietf.org>
List-Subscribe: <mailto:txauth-join@ietf.org>
List-Unsubscribe: <mailto:txauth-leave@ietf.org>
The following errata report has been submitted for RFC9635, "Grant Negotiation and Authorization Protocol (GNAP)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8198 -------------------------------------- Type: Technical Reported by: Erin Shepherd <iana@erinshepherd.net> Section: 7.3.3. Original Text ------------- The signer presents the signed object in compact form [RFC7515] in the Detached-JWS header field. In the following non-normative example, the JOSE header contains the following parameters: { "alg": "RS256", "kid": "gnap-rsa", "uri": "https://server.example.com/gnap", "htm": "POST", "typ": "gnap-binding-jwsd", "created": 1618884475 } The request content is the following JSON object: NOTE: '\' line wrapping per RFC 8792 { "access_token": { "access": [ "dolphin-metadata" ] }, "interact": { "start": ["redirect"], "finish": { "method": "redirect", "uri": "https://client.foo/callback", "nonce": "VJLO6A4CAYLBXHTR0KRO" } }, "client": { "key": { "proof": "jwsd", "jwk": { "kid": "gnap-rsa", "kty": "RSA", "e": "AQAB", "alg": "RS256", "n": "hYOJ-XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf\ YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG\ YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR\ ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_\ 3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE\ N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ" } } "display": { "name": "My Client Display Name", "uri": "https://client.foo/" }, } } This is hashed to the following base64-encoded value: PGiVuOZUcN1tRtUS6tx2b4cBgw9mPgXG3IPB3wY7ctc This leads to the following full HTTP request message: NOTE: '\' line wrapping per RFC 8792 POST /gnap HTTP/1.1 Host: server.example.com Content-Type: application/json Content-Length: 983 Detached-JWS: eyJhbGciOiJSUzI1NiIsImNyZWF0ZWQiOjE2MTg4ODQ0NzUsImh0b\ SI6IlBPU1QiLCJraWQiOiJnbmFwLXJzYSIsInR5cCI6ImduYXAtYmluZGluZytqd3\ NkIiwidXJpIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vZ25hcCJ9.PGiVuO\ ZUcN1tRtUS6tx2b4cBgw9mPgXG3IPB3wY7ctc.fUq-SV-A1iFN2MwCRW_yolVtT2_\ TZA2h5YeXUoi5F2Q2iToC0Tc4drYFOSHIX68knd68RUA7yHqCVP-ZQEd6aL32H69e\ 9zuMiw6O_s4TBKB3vDOvwrhYtDH6fX2hP70cQoO-47OwbqP-ifkrvI3hVgMX9TfjV\ eKNwnhoNnw3vbu7SNKeqJEbbwZfpESaGepS52xNBlDNMYBQQXxM9OqKJaXffzLFEl\ -Xe0UnfolVtBraz3aPrPy1C6a4uT7wLda3PaTOVtgysxzii3oJWpuz0WP5kRujzDF\ wX_EOzW0jsjCSkL-PXaKSpZgEjNjKDMg9irSxUISt1C1T6q3SzRgfuQ { "access_token": { "access": [ "dolphin-metadata" ] }, "interact": { "start": ["redirect"], "finish": { "method": "redirect", "uri": "https://client.foo/callback", "nonce": "VJLO6A4CAYLBXHTR0KRO" } }, "client": { "key": { "proof": "jwsd", "jwk": { "kid": "gnap-rsa", "kty": "RSA", "e": "AQAB", "alg": "RS256", "n": "hYOJ-XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf\ YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG\ YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR\ ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_\ 3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE\ N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ" } } "display": { "name": "My Client Display Name", "uri": "https://client.foo/" }, } } When the verifier receives the Detached-JWS header, it MUST parse and validate the JWS object. The signature MUST be validated against the expected key of the signer. If the HTTP message request contains content, the verifier MUST calculate the hash of the content just as the signer does, with no normalization or transformation of the request. All required fields MUST be present, and their values MUST be valid. All fields MUST match the corresponding portions of the HTTP message. For example, the htm field of the JWS header has to be the same as the HTTP verb used in the request. Note that this proofing method depends on a specific cryptographic algorithm, SHA-256, in two ways: 1) the ath hash algorithm is hardcoded and 2) the payload of the detached/attached signature is computed using a hardcoded hash. A future version of this document may address crypto-agility for both these uses by replacing ath with a new header that upgrades the algorithm and possibly defining a new JWS header that indicates the HTTP content's hash method. 7.3.3.1. Key Rotation Using Detached JWS When rotating a key using detached JWS, the message, which includes the new public key value or reference, is first signed with the old key as described above using a JWS object with typ header value "gnap-binding-rotation-jwsd". The value of the JWS object is then taken as the payload of a new JWS object, to be signed by the new key using the parameters above. The value of the new JWS object is sent in the Detached-JWS header. Corrected Text -------------- N/A Notes ----- This section standardises the use of the Detached-JWS HTTP header. This header was not registered in the IANA Considerations section and is not a registered HTTP header. I am unsure what the best way to correct this ommission is. Instructions: ------------- This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -------------------------------------- RFC9635 (draft-ietf-gnap-core-protocol-19) -------------------------------------- Title : Grant Negotiation and Authorization Protocol (GNAP) Publication Date : October 2024 Author(s) : J. Richer, Ed., F. Imbault Category : PROPOSED STANDARD Source : Grant Negotiation and Authorization Protocol Stream : IETF Verifying Party : IESG
- [GNAP] [Technical Errata Reported] RFC9635 (8198) RFC Errata System
- [GNAP] Re: [Technical Errata Reported] RFC9635 (8… Yaron Sheffer
- [GNAP] Re: [Technical Errata Reported] RFC9635 (8… Justin Richer
- [GNAP] Re: [Technical Errata Reported] RFC9635 (8… Deb Cooley