Re: [jose] Whether implementations must understand all JOSE header fields

["Jim Schaad" <[e-mail]>]

This does not include my recommended approach which is to punt the issue of
required headers to the application rather than JOSE.

 

Jim

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Mike
Jones
Sent: Friday, December 14, 2012 10:17 AM
To: [e-mail]
Subject: [jose] Whether implementations must understand all JOSE header
fields

 

Currently the JOSE specs contain the following language declaring that all
header (and some other) fields must be understood:  "Implementations MUST
understand the entire contents of the header; otherwise, the . MUST be
rejected."  There's currently an open issue about whether all header fields
should be required to be understood by implementations using them or whether
to relax this requirement in some circumstances.  We would like the working
group to consider the following potential resolutions to the issue.

 

1.  Maintain the current requirement that all header fields must be
understood by implementations using them.

 

PRO:  This is a simple rule designed to result in secure implementations.
Representations of existing JWS & JWE objects are unchanged.

CON:  Extensibility is limited to cases where all participating parties
understand new fields that are introduced.

 

2A.  Take an alternative approach where, by default, all fields must be
understood, but where an explicit list of fields can be designated as "may
be ignored if not understood".  For instance, an "ign" (may be ignored)
member could be defined whose value is an array listing the member names
that may be safely ignored if not understood.  An example using this field
in a JWS header is:

 

    {"alg":"ES256",

     "ign":["notes"],

     "notes":"This signature need not be checked when the moon is full"

    }

 

(Obviously, the "ign" field MUST NOT contain the value "ign".)

 

PRO:  This would enable adding non-critical header fields without breaking
implementations.  It would maintain the current semantics, while allowing
explicit exceptions to be made in cases where the fields are not
security-critical and the structure has a meaningful interpretation without
them.  Representations of existing JWS & JWE objects are unchanged.

CON:  Requires coordination of field names and may-be-ignored list, adding
some implementation complexity.

 

2B.  Take an alternative approach where instead of one header object, there
would be two header objects.  Implementations would be required to
understand all fields in the first header object.  Implementations would be
allowed to ignore fields in the second header object if not understood.  An
example of this approach, adding the second header object after the first in
a JWS, would be:

 

    eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9

    .

 
eyJub3RlcyI6IlRoaXMgc2lnbmF0dXJlIG5lZWQgbm90IGJlIGNoZWNrZWQgd2hlbiB0aGUgbW9v
biBpcyBmdWxsIn0

    .

 
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9p
c19yb290Ijp0cnVlfQ

    .

    dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

 

The first, third, and fourth fields are from the example JWS in the current
spec. The new second field is the base64url encoded representation of the
string '{"notes":"This signature need not be checked when the moon is
full"}'.

 

PRO:  May-be-ignored fields are easily distinguishable from
must-be-understood fields.

CON:  Implementations must consult/merge two sets of headers to understand
the meaning/structure of the object, adding some implementation complexity.
Existing JWS & JWE object representations would become invalid.

 

After a discussion period, we believe that it would be useful for the chairs
to make two formal consensus calls of the following kind:

 

FIRST POLL:  Should all header fields be critical for implementations to
understand?

YES - All header fields must continue to be understood by implementations or
the input must be rejected.

NO - A means of listing that specific header fields may be safely ignored
should be defined.

 

SECOND POLL:  Should the result of the first poll be "NO", which syntax
would you prefer for designating the header fields that may be ignored if
not understood?

A - Define a header field that explicitly lists the fields that may be
safely ignored if not understood.

B - Introduce a second header, where implementations must understand all
fields in the first but they may ignore not-understood fields in the second.

 

                                                Thanks for considering these
questions,

                                                Richard Barnes, John
Bradley, Mike Jones