Subject: Re: [jose] Proposed resolution of header criticality issue

From: "Manger, James H" <[email-masked]>
Date: Tue, 12 Mar 2013 23:18:07 +1100

Nah, "crt" sounds too much like a certificate. *.crt is a common file extension for certs.

How about "!" ?

--
James Manger

----- Reply message -----
From: "Vladimir Dzhuvinov / NimbusDS" <[email-masked]>
Date: Tue, Mar 12, 2013 5:45 pm
Subject: [jose] Proposed resolution of header criticality issue
To: "[email-masked]" <[email-masked]>

How about "crt" instead of "crit", to fit the three-letter convention
for naming fields?

Vladimir

--
Vladimir Dzhuvinov : www.NimbusDS.com<http://www.NimbusDS.com> : [email-masked]

-------- Original Message --------
Subject: [jose] Proposed resolution of header criticality issue
From: Karen O'Donoghue <[email-masked]>
Date: Tue, March 12, 2013 12:31 am
To: [email-masked]

 Folks,

 A side meeting was held Sunday with a number of jose working group
participants to try to resolve the open issue related to header
criticality. The following are the proposed resolutions from the
meeting. Point 5 of the proposed resolution below is actually
independent of the other 4 points, and could be considered separately.
This will all be discussed in Wednesday's meeting.

 In addition to the text below, there was some agreement to replace the
"understand" text with something a bit more explicit like "must
process". However, that text has not been rolled into the summary text
below yet.

 Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin
Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts
(and my apologies if I missed someone).

 Regards,
 Karen

 1:  Change the language “Additional members MAY be present in the
JWK.  If present, they MUST be understood by implementations using
them.” to “Additional members MAY be present in the JWK.  If not
understood by implementations encountering them, they MUST be
ignored.”  (And make the same change for JWK Set as well.)

 2:  Characterize all existing JWS and JWE header fields as either must
be understood or may be ignored.  “alg”, “enc”, and “zip”
must be understood.  “kid”, “x5u”, “x5c”, “x5t”,
“jwk”, “jku”, “typ”, and “cty” can be ignored because
while not using them may result in the inability to process some
signatures or encrypted content, this will not result in a security
violation – just degraded functionality.  Other fields such as
“epk”, “apu”, “apv”, “epu”, and “epv” must be
understood and used when “alg” or “enc” values requiring them
are used, and otherwise they may be ignored.

 3.  Define a new header field that lists which additional fields not
defined in the base specifications must be understood and acted upon
when present.  For instance, an expiration-time extension field could be
marked as must-be-understood-and-acted-upon.  One possible name for this
would be “crit” (critical).  An example use, along with a
hypothetical “exp” (expiration-time) field is:

   {"alg":"ES256",
    "crit":["exp"],
    "exp”:1363284000
   }

 4.  All additional header fields not defined in the base specifications
and not contained in the “crit” list MUST be ignored if not
understood.

 5.  Define a new header field “asd” (application-specific data)
whose value is a JSON structure whose contents are opaque to and ignored
by JWS and JWE implementations but for which its contents MUST be
provided to applications using JWS or JWE, provided that the
signature/MAC validation or decryption operation succeeds.  The intended
use of this field is to have a standard place to provide
application-specific metadata about the payload or plaintext.

 _______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 13 Mar 2013 13:08:48 +1100

As we define the "crit" field we don't need to use field names as the critical strings.

Implementations will have a list of critical strings they understand (based on the specs that define those critical strings) and will confirm that all the "crit" values are in their list. This will be a distinct step from the other code that uses specific fields.

For instance, if we defined a simple KDF initially then later specified support for the NIST 800-56A Concat KDF it would be better to define 1 critical string "nist800-56A", instead of listing "PartyUInfo", "PartyVInfo", "SuppPubInfo", and "SuppPriveInfo" fields names in the "crit" field -- any of which might be absent from a particular JOSE message if they had some default value.

Another example: if a group insists on a strong signature verification policy (eg MUST use OCSP, MUST hard-fail if OCSP is unavailable, MUST check Certificate Transparency, and MUST log results for 7 years) there is no new header field to add to a JWS, but it could define the critical string "StrongSig1".

--
James Manger

 -------- Original Message --------

> when present.  For instance, an expiration-time extension field could
> be marked as must-be-understood-and-acted-upon.  One possible name for
> this would be “crit” (critical).  An example use, along with a

---

From: Richard Barnes <[email-masked]>
Date: Wed, 13 Mar 2013 16:12:55 -0400

I don't really think that there's much benefit to the additional complexity
here.  You don't need it for the 800-56A case, because that's in the
current document, and will thus get real requirements language in the spec.
 If you do want to group extension fields in this way, you can just group
them into an object under a single extension field.  For example:

{
    "alg": "foo",
    "new-thing": {
        "part1": 42,
        "part2": "six"
    },
    "crit": ["new-thing"]
}

On Tue, Mar 12, 2013 at 10:08 PM, Manger, James H <
[email-masked]> wrote:

> Implementations will have a list of critical strings they understand
> (based on the specs that define those critical strings) and will confirm
> that all the "crit" values are in their list. This will be a distinct step
> from the other code that uses specific fields.
>
> For instance, if we defined a simple KDF initially then later specified
> support for the NIST 800-56A Concat KDF it would be better to define 1
> critical string "nist800-56A", instead of listing "PartyUInfo",
> "PartyVInfo", "SuppPubInfo", and "SuppPriveInfo" fields names in the "crit"
> field -- any of which might be absent from a particular JOSE message if
> they had some default value.
>
> Another example: if a group insists on a strong signature verification
> policy (eg MUST use OCSP, MUST hard-fail if OCSP is unavailable, MUST check
> Certificate Transparency, and MUST log results for 7 years) there is no new
> header field to add to a JWS, but it could define the critical string
> "StrongSig1".
>
>
> --
> James Manger
>

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 14 Mar 2013 09:46:06 +1100

I am trying to simplify the “crit” field, not complicate it.

The Concat KDF paragraph was only intended as a vaguely realistic example of how a critical string could be used. My email was NOT a request to change how JOSE currently uses Concat KDF.

When an implementation sees an unknown string in “crit” is has to stop. The rule can and should be that simple.

I don’t want some implementations also checking that a header field with an unknown critical string’s name is present before they reject a JOSE message. I don’t want some implementations listing field names from the “base specs”, such as “alg”, as critical strings. Linking critical strings to field names can only add ill-defined non-interoperable corner cases.

--
James Manger

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, 14 March 2013 7:13 AM
To: Manger, James H
Cc: [email-masked]
Subject: Re: [jose] "crit" strings don't have to be field names

I don't really think that there's much benefit to the additional complexity here.  You don't need it for the 800-56A case, because that's in the current document, and will thus get real requirements language in the spec.  If you do want to group extension fields in this way, you can just group them into an object under a single extension field.  For example:

{
    "alg": "foo",
    "new-thing": {
        "part1": 42,
        "part2": "six"
    },
    "crit": ["new-thing"]
}

On Tue, Mar 12, 2013 at 10:08 PM, Manger, James H <[email-masked]<mailto:[email-masked]>> wrote:
As we define the "crit" field we don't need to use field names as the critical strings.

--
James Manger

 -------- Original Message --------
> From: Karen O'Donoghue <[email-masked]<mailto:[email-masked]>>
> To: [email-masked]<mailto:[email-masked]>

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 14 Mar 2013 16:31:13 +1100

I was just listening to some of the IETF 86 JOSE session.
One issue was what would "crit":["asd"] mean? (where “asd” is a top-level bucket for app-specific data that a JOSE library can ignore)
The more general issue is whether only top-level fields can be marked critical?

I hope we don’t try to answer that. Tightly coupling our choice of JSON structure (ie what is at the top level) to what can be critical is unnecessary.

For instance, a good change to the JOSE structure would be top-level objects (eg named “o” and “r”) to group fields about the originator and recipient respectively (eg it would make it clear whose key a “kid” value referred to; you could even identify each party’s key by including two “kid” fields, {...,"o":{"kid":"mykey1"},"r":{"kid":"yourkey3"}}).
It would be annoying if adding such structure had unintended impacts on what could or couldn’t be marked critical.

So let’s define “crit” as a list of critical strings, without mentioning field names, to avoid a bunch of unnecessary hassles.

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Thursday, 14 March 2013 9:46 AM
To: Richard Barnes
Cc: [email-masked]
Subject: Re: [jose] "crit" strings don't have to be field names

--
James Manger

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, 14 March 2013 7:13 AM
To: Manger, James H
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] "crit" strings don't have to be field names

{
    "alg": "foo",
    "new-thing": {
        "part1": 42,
        "part2": "six"
    },
    "crit": ["new-thing"]
}

--
James Manger