[GNAP] Re: [Technical Errata Reported] RFC9635 (8198)

[Justin Richer <[e-mail]>]

It's defined in the document in a stable way but the registration wasn't requested, I don't think we need another document just to make the request. Perhaps the AD can chime in on the required process.
________________________________
From: Yaron Sheffer <[e-mail]>
Sent: Friday, December 6, 2024 9:55 AM
To: RFC Errata System <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [GNAP] Re: [Technical Errata Reported] RFC9635 (8198)


I believe this errata should be marked Verified.



But we also have to deal with the unregistered header field. Normally I would say, let’s submit an IANA registration request [1] and be done with it. But registering a new header field is somewhat painful, see [2], and seems to require a stable reference. So, do we need a -bis document? Or maybe a short AD-sponsored draft for this one purpose?



Thanks,

                Yaron



[1] https://www.iana.org/form/protocol-assignment

[2] https://httpwg.org/specs/rfc7231.html#considerations.for.new.header.fields



On 04/12/2024, 19:30, "RFC Errata System" <[e-mail]> wrote:

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 <[e-mail]<mailto:[e-mail]>>



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"<https://server.example.com/gnap%22>,

       "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"<https://client.foo/callback%22>,

               "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/"<https://client.foo/%22>

         },

       }

   }



   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"<https://client.foo/callback%22>,

               "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/"<https://client.foo/%22>

         },

       }

   }



   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