Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory

I'll plan on reviewing the Use Cases document after finishing the current spec updates to the other specs.  If you believe that the use Cases Document as written precludes use cases where keys are exchanged by mechanisms other than the JOSE headers, that's an indication that some use cases are missing from the document.

                                                            Best wishes,
                                                            -- Mike

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Monday, April 15, 2013 10:31 AM
To: Mike Jones
Cc: odonoghue@isoc.org; jose@ietf.org
Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory

You're making the same false argument I just addressed.  Covering use cases involving pre-negotiation does not imply that headers can't be mandatory.  It implies that they can't be mandatory in all cases -- that is, that there needs to be a "pre-negotiated mode" in which headers are not mandatory in addition to the "stand-alone mode" where everything needs to be expressed in the headers (no pre-negotiation).

I am completely fine with supporting both modes, but in order to do that, it needs to be clear to a recipient which mode is in use.  So we need to:
(1) Choose a default mode,
(2) Have a switch that indicates when the non-default mode is being used, and
(3) Define generation and processing rules for both modes.

What I'm saying here is that:
(1) The default mode should be "stand-alone"
(2) The switch is SPI
(3) The processing rules for the stand-alone mode should REQUIRE at least one key indicator

What you're arguing is that there should not be a well-defined stand-alone mode, effectively that the recipient always does some pre-negotiation in order to know what fields it needs.  So you're arguing that the following basic requirements from the use cases document aren't actually requirements:
"""

   o  The JOSE encrypted object format must support object encryption in

      the case where the sender and receiver share a symmetric key.

   o  The JOSE encrypted object format must support object encryption in

      the case where the sender has only a public key for the receiver.

   o  The JOSE signed object format must integrity protection using

      Message Authentication Codes (MACs), for the case where the sender

      and receiver share only a symmetric key.

   o  The JOSE signed object format must integrity protection using

      digital signatures, for the case where the receiver has only a

      public key for the sender.
"""
The implication of all those "only"s is that everything else has to be defined by the protocol specification, including which fields are mandatory.

--Richard

On Mon, Apr 15, 2013 at 11:45 AM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
You could say "nice straw man, Jim", as it was Jim Schaad who proposed that the right question to ask was whether such use cases are important or not.  I agree with Jim that clearly if they are important/in scope, then key indicators in the headers can't be mandatory.

                                                            -- Mike

From: Richard Barnes [mailto:rlb@ipv.sx<mailto:rlb@ipv.sx>]
Sent: Monday, April 15, 2013 8:41 AM
To: Mike Jones
Cc: odonoghue@isoc.org<mailto:odonoghue@isoc.org>; jose@ietf.org<mailto:jose@ietf.org>
Subject: Re: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory

Nice straw man, Mike  :)

Nobody is arguing that cases with out-of-band negotiation are not important.  The question is how they should be supported.

What ISSUE-9 and ISSUE-15 are about is saying that the default assumption should be that all communication is via JW* headers.  Otherwise, we're not designing a stand-alone protocol, we're designing an adjunct to something else, and we should do it in that WG.  That default assumption means that you have to have certain contraints, like a key indicator being REQUIRED.  The SPI header is then the "get out of jail free card", releasing you from those constraints.

Let's design a real protocol first, then let people cheat.

--Richard

On Fri, Apr 12, 2013 at 1:25 AM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
Reading this question, I believe that there's a possibility for the question to be misinterpreted, since the sense of the question in the subject is opposite of the sense of the question in the body.  I believe that the intent of 1 and 2 were as follows:

1.  Yes - Use cases where key information is exchanged by means other than the JWS and JWE headers ARE important.
2.  No - Use cases where key information is exchanged by means other than the JWS and JWE headers ARE NOT important.

Maybe people could reply with 1 and 2 as above, so that their answers to the question of whether these use cases are important are not are unambiguous.

                                                            -- Mike

From: jose-bounces@ietf.org<mailto:jose-bounces@ietf.org> [mailto:jose-bounces@ietf.org<mailto:jose-bounces@ietf.org>] On Behalf Of Karen O'Donoghue
Sent: Thursday, April 11, 2013 5:00 PM

To: jose@ietf.org<mailto:jose@ietf.org>
Subject: [jose] Feedback request on jose tracker issue #15: Should at least on key indicator be mandatory

Issue #15 http://trac.tools.ietf.org/wg/jose/trac/ticket/15. suggests requiring that a key indicator, such as a "kid" field, be required in all JWS and JWE headers. Are use cases where key information is exchanged by means other than the JWS or JWE headers important?
Which of these best describes your preferences on this issue?
1.  Yes.
2.   No.
0.  I need more information to decide.

Your reply is requested by Friday, April 19th (or earlier).

_______________________________________________
jose mailing list
jose@ietf.org<mailto:jose@ietf.org>
https://www.ietf.org/mailman/listinfo/jose