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