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

From: Mike Jones <[email-masked]>
Date: Tue, 12 Mar 2013 13:03:11 +0000

I kind of like the “!” suggestion.  James is right - I didn’t choose the name “crt” becase it means “certificate” to too many people.

Cheers,
-- Mike

From: Manger, James H
Sent: ‎March‎ ‎12‎, ‎2013 ‎5‎:‎18‎ ‎AM
To: [email-masked], [email-masked]
Subject: Re: [jose] Proposed resolution of header criticality issue

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
_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Brian Campbell <[email-masked]>
Date: Tue, 12 Mar 2013 09:07:34 -0400

"!" is the nicest color for this particular bike-shed that has been
proposed thus far.

On Tue, Mar 12, 2013 at 9:03 AM, Mike Jones <[email-masked]>wrote:

>  I kind of like the “!” suggestion.  James is right - I didn’t choose the
> name “crt” becase it means “certificate” to too many people.
>
> Cheers,
> -- Mike
>
>  *From:* Manger, James H
> *Sent:* March 12, 2013 5:18 AM
> *To:* [email-masked], [email-masked]
>
> *Subject:* Re: [jose] Proposed resolution of header criticality issue
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 09:15:44 -0400

Actually, "!" is really developer-hostile.  For example, in JS, suppose you
do the following:

var json = '{"foo":1, "!":2}';
var x = JSON.parse(json);

Then I can access the field in question using one syntax (x["!"]), but not
the simpler one (x.foo).

I would much rather have something that makes it easy to write code instead
of something that minimizes octets.

On Tue, Mar 12, 2013 at 9:07 AM, Brian Campbell
<[email-masked]>wrote:

>>  I kind of like the “!” suggestion.  James is right - I didn’t choose
>> the name “crt” becase it means “certificate” to too many people.
>>
>> Cheers,
>> -- Mike
>>
>>  *From:* Manger, James H

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 12 Mar 2013 13:26:09 +0000

I agree with Richard on the nice-ness test of the property identifier, which "crit" passes.

However, I also just want this bikeshed to be painted.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.