Subject: Re: [jose] POLL(s): header criticality

From: Mike Jones <[email-masked]>
Date: Fri, 8 Feb 2013 02:05:55 +0000

I agree that this should be described in the document.

One common application that uses discovery/negotiation to decide what algorithms are supported and to use is TLS (https).

Cheers,
-- Mike

From: Hannes Tschofenig
Sent: ‎February‎ ‎7‎, ‎2013 ‎12‎:‎51‎ ‎AM
To: Mike Jones, [email-masked], [email-masked]
CC: [email-masked]
Subject: Re: RE: [jose] POLL(s): header criticality

Hi Mike,

whatever story the group comes up with I believe it would be important to describe this in the document since other specifications have followed a different approach.

Knowing you guys I had already expected that you try to solve this extensibility issue using additional OpenID Connect specifications.

I am wondering what approach other specifications have used in the past. My understanding is that XML, CMS, and PSKC follow a model where the mandatory to implement functionality is defined in the specification and additional specifications indicate what additional extensions have to be used. Is my understanding correct?

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Thu, 7 Feb 2013 07:20:32 +0000
> Von: Mike Jones <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
> CC: "[email-masked]" <[email-masked]>
> Betreff: RE: [jose] POLL(s): header criticality

> Hi Hannes,
>
> One tried-and-true method of enabling extensions is through discovery
> and/or negotiation.  (This fits into your (b) - there is another higher layer
> specification that says what is required.)  For instance, if two parties
> come to understand through discovery that both support an extension, then they
> are free to use it between themselves.
>
> For instance, yes, in OpenID Connect, implementations can discover what
> algorithms and other features are supported and then use only those that are
> implemented by both communicating parties.  I can't imagine that this is
> the only JOSE use case that will employ discovery and/or negotiation.
>
> When discovery and/or negotiation is used, implementations don't have to
> ignore not-understood features, because none would be used in the first
> place.
>
>     Best wishes,
>     -- Mike
>
> P.S.  Yes, you're right that (a) - out-of-band agreement - could be used
> in some cases too.  For instance, OAuth deployments almost all employ
> out-of-band agreements.
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hannes Tschofenig
> Sent: Wednesday, February 06, 2013 10:32 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [jose] POLL(s): header criticality
>
> Hi Karen,
>
> thanks for running this poll.
>
> My problem with answering your questions is the following:
>
> The question you are raising deals with how you want to handle extensions.
> While it is easy to say that all the features in specification X must be
> implemented it is not even clear which specifications you are actually
> referring to with question #1.
>
> So, I am wondering how you plan to handle any extension when someone
> answers question #1 with YES. I see only the following ways:
>
> a) there is an out-of-band agreement (for a specific system, such a
> federation) that defines what values need to be present, or
>
> b) there is another higher layer specification that says what is required.
>
> I assume that many of the OAuth folks have answered the question with YES
> since they are thinking that they will just write that specification as
> part of OpenID Connect.
>
> If that's the plan I think it should be clearly articulated to avoid
> raising wrong expectations of the level of interoperability this work provides.
>
> If there is a different plan then please let me know.
>
> Ciao
> Hannes
>
>
> On 02/04/2013 04:48 PM, Karen O'Donoghue wrote:
> > Folks,
> >
> > I am wrestling with how to help drive consensus on the topic of
> > criticality of headers. For background, please review the current
> > specification text, the minutes to the Atlanta meeting (IETF85), and
> > the mailing list (especially the discussion in December with (Subj:
> > Whether implementations must understand all JOSE header fields)). We
> > need to come to closure on this issue in order to progress the
> specifications.
> >
> > As a tool to gather further information on determining a way forward,
> > the following polls have been created. Please respond before 11
> > February 2013.
> >
> > Thanks,
> > Karen
> >
> > *******************
> > 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 "YES", should text
> > like the following be added? "Implementation Note: The requirement to
> > understand all header fields is a requirement on the system as a whole
> > - not on any particular level of library software. For instance, a
> > JOSE library could process the headers that it understands and then
> > leave the processing of the rest of them up to the application. For
> > those headers that the JOSE library didn't understand, the
> > responsibility for fulfilling the 'MUST understand' requirement for
> > the remaining headers would then fall to the application."
> >
> > YES - Add the text clarifying that the "MUST understand" requirement
> > is a requirement on the system as a whole - not specifically on JOSE
> > libraries.
> >
> > NO - Don't add the clarifying text.
> >
> > ************************
> > THIRD 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.
> >
> > C - Other??? (Please specify in detail.)
> > _______________________________________________
> > 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: Richard Barnes <[email-masked]>
Date: Thu, 7 Feb 2013 23:08:09 -0500

One might note that TLS does not require that all headers be understood.
 You can send SNI, say, without the risk of breaking interop with older
servers.

More to the point, unless you're going to actually define a negotiation
mechanism, saying that one would help is not all that constructive. This
group needs to either define a negotiation mechanism, or else not add
features for which negotiation is a absolute requirement.  And I would
strongly oppose the former, as an unnecessary expansion of scope.

--Richard

On Thursday, February 7, 2013, Mike Jones wrote:

> One common application that uses discovery/negotiation to decide what
> algorithms are supported and to use is TLS (https).
>
> Cheers,
> -- Mike
>
>  *From:* Hannes Tschofenig
> *Sent:* February 7, 2013 12:51 AM
> *To:* Mike Jones, [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>, [email-masked] <javascript:_e({},
> 'cvml', [email-masked]');>
> *CC:* [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
> *Subject:* Re: RE: [jose] POLL(s): header criticality
>
> Hi Mike,
>
> whatever story the group comes up with I believe it would be important to
> describe this in the document since other specifications have followed a
> different approach.
>
> Knowing you guys I had already expected that you try to solve this
> extensibility issue using additional OpenID Connect specifications.
>
> I am wondering what approach other specifications have used in the past.
> My understanding is that XML, CMS, and PSKC follow a model where the
> mandatory to implement functionality is defined in the specification and
> additional specifications indicate what additional extensions have to be
> used. Is my understanding correct?
>
> Ciao
> Hannes
>
> > Von: Mike Jones <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>
> > An: Hannes Tschofenig <[email-masked] <javascript:_e({},
> 'cvml', [email-masked]');>>, "[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>"
> <[email-masked] <javascript:_e({}, 'cvml', [email-masked]');>>
> > CC: "[email-masked] <javascript:_e({}, 'cvml', [email-masked]');>" <
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>>
> > From: [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');> [mailto:[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>]
> On Behalf Of
> > Hannes Tschofenig
> > To: [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>
> > Cc: [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>; [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>
> > > [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
> > [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>

---

From: Mike Jones <[email-masked]>
Date: Fri, 8 Feb 2013 06:02:32 +0000

I agree with you that we don't need to define a negotiation mechanism.  As I believe Hannes correctly observed, either negotiation or out-of-band agreement will typically be used to agree on parameters to be used, but it's not the job of this working group to define them.  In fact, the right choices are typically dependent upon the particular use case.

I know of three publicly known systems built using the current JOSE specs (Mozilla Persona, a system Dick Hardt is building for the province of BC, and OpenID Connect) where one of these techniques are applied.  None of them needs to ignore parameters, to my knowledge.  See http://openid.net/specs/openid-connect-discovery-1_0.html for the discovery system used by latter.

My main point is that just because we don't define a discovery mechanism, that doesn't mean that one won't be used, when appropriate.

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, February 07, 2013 8:08 PM
To: Mike Jones
Cc: Karen O'Donoghue; Hannes Tschofenig; [email-masked]
Subject: Re: [jose] POLL(s): header criticality

One might note that TLS does not require that all headers be understood.  You can send SNI, say, without the risk of breaking interop with older servers.

More to the point, unless you're going to actually define a negotiation mechanism, saying that one would help is not all that constructive. This group needs to either define a negotiation mechanism, or else not add features for which negotiation is a absolute requirement.  And I would strongly oppose the former, as an unnecessary expansion of scope.

--Richard

Cheers,
-- Mike

From: Hannes Tschofenig
Sent: February 7, 2013 12:51 AM
To: Mike Jones, [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>, [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>
CC: [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>
Subject: Re: RE: [jose] POLL(s): header criticality

Hi Mike,

Ciao
Hannes

-------- Original-Nachricht --------
> Von: Mike Jones <[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>>
> An: Hannes Tschofenig <[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>>, "[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>" <[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>>
> CC: "[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>" <[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>>

> From: [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');> [mailto:[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>] On Behalf Of
> Hannes Tschofenig
> To: [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>
> Cc: [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>; [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>
> > [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>
> [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 8 Feb 2013 10:02:48 +0200

The comparison with TLS is a bit tricky since JOSE is not a multi-roundtrip protocol but rather a one-shot message (similar to XML digital signature and XML encryption, CMS, or PSKC). 

There is an IAB document that is relevant to this discussion, namely http://tools.ietf.org/html/rfc6709

Interestingly Appendix A.3 talks about TLS extensions and makes a few remarks that are relevant to this discussion (see http://tools.ietf.org/html/rfc6709#appendix-A.3):

"
   It has turned out that many SSLv3 and TLS implementations that do not
   support TLS extensions did not ignore the unknown extensions, as
   required by the protocol specifications, but instead failed to
   establish connections.
"

At a minimum I expect that the document describe a story for how extensions are behind handled.

Ciao
Hannes

---

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

So you're saying that if any of these systems wants to define an optional
parameter, they need to coordinate with all of the others.

For example: The Persona verification process is largely server-based.
 Suppose the Persona spec wanted to include an optional attribute 'vsf'
that has the key fingerprint of the server that should be used to verify
the assertion.  Not mandatory, because you can still fall back to PKIX and
domain-based verification, but adds another layer of security.  Suddenly,
Persona cannot use the same JOSE library that OpenID Connect uses.

What benefit do you think comes from forcing all of these entities to
upgrade in lock-step?

--Richard

On Fri, Feb 8, 2013 at 1:02 AM, Mike Jones <[email-masked]>wrote:

>  I agree with you that we don’t need to define a negotiation mechanism.
> As I believe Hannes correctly observed, either negotiation or out-of-band
> agreement will typically be used to agree on parameters to be used, but
> it’s not the job of this working group to define them.  In fact, the right
> choices are typically dependent upon the particular use case.****
>
> ** **
>
> I know of three publicly known systems built using the current JOSE specs
> (Mozilla Persona, a system Dick Hardt is building for the province of BC,
> and OpenID Connect) where one of these techniques are applied.  None of
> them needs to ignore parameters, to my knowledge.  See
> http://openid.net/specs/openid-connect-discovery-1_0.html for the
> discovery system used by latter.****
>
> ** **
>
> My main point is that just because we don’t define a discovery mechanism,
> that doesn’t mean that one won’t be used, when appropriate.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Thursday, February 07, 2013 8:08 PM
> *To:* Mike Jones
> *Cc:* Karen O'Donoghue; Hannes Tschofenig; [email-masked]
>
> *Subject:* Re: [jose] POLL(s): header criticality****
>
> ** **
>
> servers. ****
> ** **
> On Thursday, February 7, 2013, Mike Jones wrote:****
>
> I agree that this should be described in the document.****
>
>  ****
>
> algorithms are supported and to use is TLS (https).****
>
>  ****
>
> Cheers,****
>
> -- Mike****
>
>  ****
>
> *To:* Mike Jones, [email-masked], [email-masked]
> *CC:* [email-masked]
> *Subject:* Re: RE: [jose] POLL(s): header criticality****
>
>  ****
>
> Hi Mike,
>
> > https://www.ietf.org/mailman/listinfo/jose****
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Feb 2013 10:56:55 -0500

> algorithms are supported and to use is TLS (https).
That's not quite accurate. TLS specifies mandatory to implement algs. 
Clients and servers can
use the handshake to discover/negotiate algs, but they always know that 
the mandatory to implement
algs are available.

Steve