Subject: [jose] Header criticality -- hidden consensus?

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Feb 2013 18:11:59 -0500

We're 24 votes into the header criticality poll, so I thought I would go
ahead and take a look at how the results are shaping up.  My initial
tabulation is below.  The result on the FIRST POLL (the main one) is as
follows:

No: 10
Yes: 14

What I find striking, however, is that every single person that voted "Yes"
on the FIRST POLL also voted "Yes" on the SECOND POLL.  So nobody who
thinks that all headers should be critical thinks that a JOSE library
should actually be required to enforce this constraint.  And that means
that enforcing that all headers are supported cannot be a MUST according to
RFC 2119.

So I wonder if there's consensus to remove the following text from JWE and
JWS:
-----BEGIN-JWE-----
   4.   The resulting JWE Header MUST be validated to only include
        parameters and values whose syntax and semantics are both
        understood and supported.
-----END-JWE-----
-----BEGIN-JWS-----
   4.  The resulting JWS Header MUST be validated to only include
       parameters and values whose syntax and semantics are both
       understood and supported.
-----END-JWS-----

Otherewise, a JOSE library conforming to these specifications would be
REQUIRED (a synonym to MUST in 2119) to reject a JWE/JWS that contains an
unknown header, contradicting all those "Yes" votes on the SECOND POLL.

--Richard

-----BEGIN-Tabulation-----
1       2       3    Name:
N       -       -    Bradley
N       -       -    Ito
N       N       A    Yee
N       N       B    Barnes
N       N       B    Rescorla
N       N       C    Manger
N       N       C    Octman
N       Y       A    Fletcher
N       Y       A    Miller
N       Y       A    Sakimura
Y       Y       -    D'Agostino
Y       Y       A    Biering
Y       Y       A    Brault
Y       Y       A    Hedberg
Y       Y       A    Jay
Y       Y       A    Jones
Y       Y       A    Marais
Y       Y       A    Nadalin
Y       Y       A    Nara
Y       Y       A    Nennker
Y       Y       A    Solberg
Y       Y       B    Hardt
Y       Y       B    Medeiros
Y       Y       C    Matake
Y       Y       C    Mishra
-----END-Tabulation-----

---

From: Mike Jones <[email-masked]>
Date: Fri, 8 Feb 2013 23:19:58 +0000

I think you're missing the point of the second poll question.  It's there to clarify that the requirement to validate the headers is one placed on the system as a whole - not solely on particular pieces of an implementation.  Indeed, it's my understanding that IETF specs almost universally place requirements only on the protocol behaviors - not on how implementations must be factored.  In other words, it's normal for IETF specs to place constraints on the behavior of the system as a whole.  The text in the second poll question would just reinforce that this is so in this particular case.

Hope everyone has a good weekend!

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Friday, February 08, 2013 3:12 PM
To: [email-masked]
Subject: [jose] Header criticality -- hidden consensus?

We're 24 votes into the header criticality poll, so I thought I would go ahead and take a look at how the results are shaping up.  My initial tabulation is below.  The result on the FIRST POLL (the main one) is as follows:

No: 10
Yes: 14

What I find striking, however, is that every single person that voted "Yes" on the FIRST POLL also voted "Yes" on the SECOND POLL.  So nobody who thinks that all headers should be critical thinks that a JOSE library should actually be required to enforce this constraint.  And that means that enforcing that all headers are supported cannot be a MUST according to RFC 2119.

So I wonder if there's consensus to remove the following text from JWE and JWS:
-----END-JWS-----

Otherewise, a JOSE library conforming to these specifications would be REQUIRED (a synonym to MUST in 2119) to reject a JWE/JWS that contains an unknown header, contradicting all those "Yes" votes on the SECOND POLL.

--Richard

-----BEGIN-Tabulation-----
1       2       3    Name:
N       -       -    Bradley
N       -       -    Ito
N       N       A    Yee
N       N       B    Barnes
N       N       B    Rescorla
N       N       C    Manger
N       N       C    Octman
N       Y       A    Fletcher
N       Y       A    Miller
N       Y       A    Sakimura
Y       Y       -    D'Agostino
Y       Y       A    Biering
Y       Y       A    Brault
Y       Y       A    Hedberg
Y       Y       A    Jay
Y       Y       A    Jones
Y       Y       A    Marais
Y       Y       A    Nadalin
Y       Y       A    Nara
Y       Y       A    Nennker
Y       Y       A    Solberg
Y       Y       B    Hardt
Y       Y       B    Medeiros
Y       Y       C    Matake
Y       Y       C    Mishra
-----END-Tabulation-----

---

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Feb 2013 18:25:12 -0500

Allow me to quote RFC 2119, which defines the requirements terminology for
IETF documents:
"
1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.
"

By that definition, a system that implements JWE is absolutely required to
throw out an object that contains an unknown header.  That requirement
applies to any system that implements JWE -- JUST JWE, not some overall
system that uses JWE.  (And likewise JWS.)

So yes, the current language applies very specifically to a JOSE library,
not to a more general system.  If you want to do that, write a BCP on
"Guidelines for Usage of JOSE".

--Richard

On Fri, Feb 8, 2013 at 6:19 PM, Mike Jones <[email-masked]>wrote:

>  I think you’re missing the point of the second poll question.  It’s
> there to clarify that the requirement to validate the headers is one placed
> on the system as a whole – not solely on particular pieces of an
> implementation.  Indeed, it’s my understanding that IETF specs almost
> universally place requirements only on the protocol behaviors – not on how
> implementations must be factored.  In other words, it’s normal for IETF
> specs to place constraints on the behavior of the system as a whole.  The
> text in the second poll question would just reinforce that this is so in
> this particular case.****
>
> ** **
>
> Hope everyone has a good weekend!****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Friday, February 08, 2013 3:12 PM
> *To:* [email-masked]
> *Subject:* [jose] Header criticality -- hidden consensus?****
>
> ** **
>
> follows:****
> ** **
> No: 10****
> Yes: 14****
> ** **
> What I find striking, however, is that every single person that voted
> "Yes" on the FIRST POLL also voted "Yes" on the SECOND POLL.  So nobody who
> RFC 2119.****
> ** **
> JWS:****
> -----BEGIN-JWE-----****
>    4.   The resulting JWE Header MUST be validated to only include****
>
>         parameters and values whose syntax and semantics are both****
>
>         understood and supported.****
>
> -----END-JWE-----****
>
> -----BEGIN-JWS-----****
>
>    4.  The resulting JWS Header MUST be validated to only include****
>
>        parameters and values whose syntax and semantics are both****
>
>        understood and supported.****
>
> -----END-JWS-----****
>
> ** **
>
> unknown header, contradicting all those "Yes" votes on the SECOND POLL.***
> *
>
> ** **
>
> --Richard****
>
> ** **
>
> ** **
>
> ** **
>
> -----BEGIN-Tabulation-----****
>
> 1       2       3    Name:           ****
>
> N       -       -    Bradley         ****
>
> N       -       -    Ito             ****
>
> N       N       A    Yee             ****
>
> N       N       B    Barnes          ****
>
> N       N       B    Rescorla        ****
>
> N       N       C    Manger          ****
>
> N       N       C    Octman          ****
>
> N       Y       A    Fletcher        ****
>
> N       Y       A    Miller          ****
>
> N       Y       A    Sakimura        ****
>
> Y       Y       -    D'Agostino      ****
>
> Y       Y       A    Biering         ****
>
> Y       Y       A    Brault          ****
>
> Y       Y       A    Hedberg         ****
>
> Y       Y       A    Jay             ****
>
> Y       Y       A    Jones           ****
>
> Y       Y       A    Marais          ****
>
> Y       Y       A    Nadalin         ****
>
> Y       Y       A    Nara            ****
>
> Y       Y       A    Nennker         ****
>
> Y       Y       A    Solberg         ****
>
> Y       Y       B    Hardt           ****
>
> Y       Y       B    Medeiros        ****
>
> Y       Y       C    Matake          ****
>
> Y       Y       C    Mishra    ****
>
> -----END-Tabulation-----****
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 8 Feb 2013 23:33:43 +0000

I'm not going to spend a lot of time arguing semantics, but there are lots of ways to meet this requirement in a library and still allow extensions to be used by the system as a whole that are not understood by the library.

One would be to have the caller pass a list of header parameter values to the library informing it to allow the use of particular parameters not understood by the library.  For instance, the list ["notes", "vsf"] might be passed in, informing the library not to reject inputs using the "notes" and "vsf" header parameters, since they are understood by the caller.

A dual of this is to have the library return a list of header parameters present in the input that it did not understand to the caller, letting the caller decide whether the input needs to be rejected.

I don't see the word "library" anywhere in RFC 2199. :)

                                                                Cheers,
                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Friday, February 08, 2013 3:25 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] Header criticality -- hidden consensus?

Allow me to quote RFC 2119, which defines the requirements terminology for IETF documents:
"
1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.
"

By that definition, a system that implements JWE is absolutely required to throw out an object that contains an unknown header.  That requirement applies to any system that implements JWE -- JUST JWE, not some overall system that uses JWE.  (And likewise JWS.)

So yes, the current language applies very specifically to a JOSE library, not to a more general system.  If you want to do that, write a BCP on "Guidelines for Usage of JOSE".

--Richard

On Fri, Feb 8, 2013 at 6:19 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I think you're missing the point of the second poll question.  It's there to clarify that the requirement to validate the headers is one placed on the system as a whole - not solely on particular pieces of an implementation.  Indeed, it's my understanding that IETF specs almost universally place requirements only on the protocol behaviors - not on how implementations must be factored.  In other words, it's normal for IETF specs to place constraints on the behavior of the system as a whole.  The text in the second poll question would just reinforce that this is so in this particular case.

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Barnes
Sent: Friday, February 08, 2013 3:12 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] Header criticality -- hidden consensus?

No: 10
Yes: 14

-----END-JWS-----

--Richard

-----BEGIN-Tabulation-----
1       2       3    Name:
N       -       -    Bradley
N       -       -    Ito
N       N       A    Yee
N       N       B    Barnes
N       N       B    Rescorla
N       N       C    Manger
N       N       C    Octman
N       Y       A    Fletcher
N       Y       A    Miller
N       Y       A    Sakimura
Y       Y       -    D'Agostino
Y       Y       A    Biering
Y       Y       A    Brault
Y       Y       A    Hedberg
Y       Y       A    Jay
Y       Y       A    Jones
Y       Y       A    Marais
Y       Y       A    Nadalin
Y       Y       A    Nara
Y       Y       A    Nennker
Y       Y       A    Solberg
Y       Y       B    Hardt
Y       Y       B    Medeiros
Y       Y       C    Matake
Y       Y       C    Mishra
-----END-Tabulation-----

---

From: Brian Campbell <[email-masked]>
Date: Fri, 8 Feb 2013 16:34:41 -0700

FWIW, I didn't see my name on the tabulation but I did 'vote'
http://www.ietf.org/mail-archive/web/jose/current/msg01461.html

On Fri, Feb 8, 2013 at 4:11 PM, Richard Barnes <[email-masked]> wrote:

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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Feb 2013 18:46:38 -0500

Sorry about that!  But you're in the "No" camp anyway, so it doesn't really
change the outcome here.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 8 Feb 2013 16:48:17 -0700

Narrows the gap by 1...

On Fri, Feb 8, 2013 at 4:46 PM, Richard Barnes <[email-masked]> wrote:

> Sorry about that!  But you're in the "No" camp anyway, so it doesn't
> really change the outcome here.
>
>
> On Fri, Feb 8, 2013 at 6:34 PM, Brian Campbell <[email-masked]
> > wrote:
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Feb 2013 18:54:23 -0500

Suppose I write a JOSE library.  It can encrypt and decrypt JWEs, sign and
verify JWSs.  It does not check that every header in an object is
supported.  Should it be considered to implement the JWE and JWS specs or
not?

The answer to that question has to be "Yes" or "No".  No cheating :)

--Richard

On Fri, Feb 8, 2013 at 6:33 PM, Mike Jones <[email-masked]>wrote:

>  I’m not going to spend a lot of time arguing semantics, but there are
> lots of ways to meet this requirement in a library and still allow
> extensions to be used by the system as a whole that are not understood by
> the library.****
>
> ** **
>
> One would be to have the caller pass a list of header parameter values to
> the library informing it to allow the use of particular parameters not
> understood by the library.  For instance, the list [“notes”, “vsf”] might
> be passed in, informing the library not to reject inputs using the “notes”
> and “vsf” header parameters, since they are understood by the caller.****
>
> ** **
>
> A dual of this is to have the library return a list of header parameters
> present in the input that it did not understand to the caller, letting the
> caller decide whether the input needs to be rejected.****
>
> ** **
>
> I don’t see the word “library” anywhere in RFC 2199. J****
>
> ** **
>
>                                                                 Cheers,***
> *
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *Sent:* Friday, February 08, 2013 3:25 PM
> *To:* Mike Jones
> *Cc:* [email-masked]
> *Subject:* Re: [jose] Header criticality -- hidden consensus?****
>
> ** **
>
> IETF documents:****
> "****
> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the****
>
>    definition is an absolute requirement of the specification.****
>
> "****
>
> ** **
>
> system that uses JWE.  (And likewise JWS.)****
>
> ** **
>
> "Guidelines for Usage of JOSE".****
>
> ** **
>
> --Richard****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Fri, Feb 8, 2013 at 6:19 PM, Mike Jones <[email-masked]>
> wrote:****
>
> I think you’re missing the point of the second poll question.  It’s there
> to clarify that the requirement to validate the headers is one placed on
> the system as a whole – not solely on particular pieces of an
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****

---

From: Mike Jones <[email-masked]>
Date: Sat, 9 Feb 2013 00:04:40 +0000

It implements part of them.  That's the truth. :)

From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, February 08, 2013 3:54 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] Header criticality -- hidden consensus?

Suppose I write a JOSE library.  It can encrypt and decrypt JWEs, sign and verify JWSs.  It does not check that every header in an object is supported.  Should it be considered to implement the JWE and JWS specs or not?

--Richard

On Fri, Feb 8, 2013 at 6:33 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I'm not going to spend a lot of time arguing semantics, but there are lots of ways to meet this requirement in a library and still allow extensions to be used by the system as a whole that are not understood by the library.

                                                                Cheers,
                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Barnes
Sent: Friday, February 08, 2013 3:25 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Header criticality -- hidden consensus?

--Richard

                                                                -- Mike

No: 10
Yes: 14

-----END-JWS-----

--Richard

-----BEGIN-Tabulation-----
1       2       3    Name:
N       -       -    Bradley
N       -       -    Ito
N       N       A    Yee
N       N       B    Barnes
N       N       B    Rescorla
N       N       C    Manger
N       N       C    Octman
N       Y       A    Fletcher
N       Y       A    Miller
N       Y       A    Sakimura
Y       Y       -    D'Agostino
Y       Y       A    Biering
Y       Y       A    Brault
Y       Y       A    Hedberg
Y       Y       A    Jay
Y       Y       A    Jones
Y       Y       A    Marais
Y       Y       A    Nadalin
Y       Y       A    Nara
Y       Y       A    Nennker
Y       Y       A    Solberg
Y       Y       B    Hardt
Y       Y       B    Medeiros
Y       Y       C    Matake
Y       Y       C    Mishra
-----END-Tabulation-----

---

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Feb 2013 19:16:39 -0500

So your answer is "No".

Conversely, if it DOES reject headers it doesn't recognize, it is also out
of compliance, because they might be recognized at a higher layer.

So you're saying that nothing can implement this spec besides a complete
system that can never have anything layered on top of it. Of course, you
can always layer something on top, so you can actually never implement this
spec.

This is what I meant about the "whole system" language bein meaningless.
You have to draw a line somewhere.

--Richard

On Friday, February 8, 2013, Mike Jones wrote:

>  It implements part of them.  That’s the truth. J****
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>]
> *Sent:* Friday, February 08, 2013 3:54 PM
> *To:* Mike Jones
> *Cc:* [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
> not?****
> The answer to that question has to be "Yes" or "No".  No cheating :)****
>
> ** **
>
> --Richard****
>
> ** **
>
> On Fri, Feb 8, 2013 at 6:33 PM, Mike Jones <[email-masked]>
> wrote:****
>
> I’m not going to spend a lot of time arguing semantics, but there are lots
> of ways to meet this requirement in a library and still allow extensions to
> be used by the system as a whole that are not understood by the library.**
> **
>
>  ****
>
> By that definition, a system that imp
>

---

From: Mike Jones <[email-masked]>
Date: Sat, 9 Feb 2013 00:22:05 +0000

See my answer in http://www.ietf.org/mail-archive/web/jose/current/msg01523.html.  There are several ways to layer solutions and easily meet the intent of the specs.

Out of respect for everyone else's time, who probably don't want to continue reading ongoing minutiae of semantic arguments that don't seem to be converging, maybe we could let this topic go until Monday? ;-)

Enjoy your weekend.

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, February 08, 2013 4:17 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: Header criticality -- hidden consensus?

So your answer is "No".

Conversely, if it DOES reject headers it doesn't recognize, it is also out of compliance, because they might be recognized at a higher layer.

So you're saying that nothing can implement this spec besides a complete system that can never have anything layered on top of it. Of course, you can always layer something on top, so you can actually never implement this spec.

This is what I meant about the "whole system" language bein meaningless. You have to draw a line somewhere.

--Richard

From: Richard Barnes [mailto:[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>]
Sent: Friday, February 08, 2013 3:54 PM
To: Mike Jones
Cc: [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>
Subject: Re: [jose] Header criticality -- hidden consensus?

--Richard

                                                                Cheers,

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Friday, February 08, 2013 3:25 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Header criticality -- hidden consensus?

"

"

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 9 Feb 2013 15:04:53 +0200

Richard, 

I am wondering whether it wouldn't make more sense to let the chairs judge the consensus call and to propose the next steps. They asked the question and I am sure they had a specific reason to frame the questions in that particular way. 

Ciao
Hannes