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>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]
> *Sent:* Monday, April 15, 2013 8:41 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****
>
> ** **
>
> 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>
> 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] *On Behalf
> Of *Karen O'Donoghue
> *Sent:* Thursday, April 11, 2013 5:00 PM****
>
>
> *To:* 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
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>