[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