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 <[email protected]>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:[email protected]]
> *Sent:* Monday, April 15, 2013 8:41 AM
> *To:* Mike Jones
> *Cc:* [email protected]; [email protected]
> *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 <[email protected]>
> 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:* [email protected] [mailto:[email protected]] *On Behalf
> Of *Karen O'Donoghue
> *Sent:* Thursday, April 11, 2013 5:00 PM****
>
>
> *To:* [email protected]
> *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
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
