Let me reiterate! I don't think pre-negotiated use cases are precluded, I just think that by default, the protocol should not rely on pre-negotiated parameters, including what key to use.
--Richard On Mon, Apr 15, 2013 at 1:47 PM, Mike Jones <[email protected]>wrote: > 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:[email protected]] > *Sent:* Monday, April 15, 2013 10:31 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**** > > ** ** > > 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
