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

[Deb Cooley <[e-mail]>]

I'll look at this (I'm a tiny bit buried at the moment, so give me a couple
of days).

Deb

On Fri, Dec 6, 2024 at 9:13 PM Justin Richer <[e-mail]> wrote:

> 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]>
>
>
>
> 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
>
>
>