Subject: [jose] Comments on draft-barnes-jose-spi-00

From: "Jim Schaad" <[email-masked]>
Date: Tue, 2 Apr 2013 08:58:18 -0700

Richard,

There is not yet sufficient detail in this document for me to do a proper
evaluation of how things are going to work.  Example questions that I have.

1.        What headers are required and which can  be implicit - for example
can the algorithm fields be implicit in the SPI?

2.       Are the integrity value computed across the fully populated header
or the SPI header?

3.       Is there a way to forward a message from person A which knows the
SPI values and person B which does not?

4.       What is the correct algorithm for determining the JWS vs JWE in the
event that all of the algorithms are implicit

5.       What happens if you have implicit parameters and explicit
parameters and they do not match?

6.       Is there a recommended way to determine what the SPI parameters are
going to be?  Does the application need to pre-parse the message to get the
SPI value or is there a recommendation that some type of callback be
included

7.       Can you make things like the IV be implicit?  Thus agree on a
starting value and an increment and compute the new IV for each new message

8.       If you are requiring that the values be populated by the
application - does this require that you have a canonical encoding of how
those values are placed into the header for the purposes of the integrity
check?

Jim

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Apr 2013 20:41:54 +0300

I don't understand why you need an additional spi parameter when there 
is already a kid parameter, which serves the same purpose.

Here is the kid parameter in the JWE:
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-4.1.10

Here is the kid parameter in the JWS:
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section-4.1.7

Ciao
Hannes

On 04/02/2013 06:58 PM, Jim Schaad wrote:
> Richard,
>
> There is not yet sufficient detail in this document for me to do a
> proper evaluation of how things are going to work.  Example questions
> that I have.
>
> 1. What headers are required and which can  be implicit – for example
> 2.Are the integrity value computed across the fully populated header or
> the SPI header?
>
> 3.Is there a way to forward a message from person A which knows the SPI
> values and person B which does not?
>
> 4.What is the correct algorithm for determining the JWS vs JWE in the
> 5.What happens if you have implicit parameters and explicit parameters
> and they do not match?
>
> 6.Is there a recommended way to determine what the SPI parameters are
> going to be?  Does the application need to pre-parse the message to get
> the SPI value or is there a recommendation that some type of callback be
> included
>
> 7.Can you make things like the IV be implicit?  Thus agree on a starting
> value and an increment and compute the new IV for each new message
>
> 8.If you are requiring that the values be populated by the application –
> does this require that you have a canonical encoding of how those values
> are placed into the header for the purposes of the integrity check?
>
> Jim
>
>
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 2 Apr 2013 14:00:02 -0400

"kid" identifies a key.  "spi" identifies anything/everything.

Think of it this way:
"spi" --> { "alg", "enc", "zip", "kid", ... }

On Tue, Apr 2, 2013 at 1:41 PM, Hannes Tschofenig <[email-masked]
> wrote:

> I don't understand why you need an additional spi parameter when there is
> already a kid parameter, which serves the same purpose.
>
> http://tools.ietf.org/html/**draft-ietf-jose-json-web-**
> encryption-08#section-4.1.10<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-4.1.10>
>
> http://tools.ietf.org/html/**draft-ietf-jose-json-web-**
> signature-08#section-4.1.7<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section-4.1.7>
>
> Ciao
> Hannes
>
>
>> ______________________________**_________________
>> jose mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/jose<https://www.ietf.org/mailman/listinfo/jose>
>>
>>
> ______________________________**_________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/jose<https://www.ietf.org/mailman/listinfo/jose>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Apr 2013 21:08:49 +0300

"kid" vs. "spi" - both are just identifiers that reference something.
Only the context gives them a meaning.

There is no need to define another parameter.

On 04/02/2013 09:00 PM, Richard Barnes wrote:
> On Tue, Apr 2, 2013 at 1:41 PM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I don't understand why you need an additional spi parameter when
>     there is already a kid parameter, which serves the same purpose.
>
>     http://tools.ietf.org/html/__draft-ietf-jose-json-web-__encryption-08#section-4.1.10
>     <http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-4.1.10>
>
>     http://tools.ietf.org/html/__draft-ietf-jose-json-web-__signature-08#section-4.1.7
>     <http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section-4.1.7>
>
>     Ciao
>     Hannes
>
>
>         _________________________________________________
>         jose mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/jose
>         <https://www.ietf.org/mailman/listinfo/jose>
>
>
>     _________________________________________________
>     jose mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/jose
>     <https://www.ietf.org/mailman/listinfo/jose>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 2 Apr 2013 14:15:49 -0400

>
> 1.       ** What headers are required and which can  be implicit – for
> example can the algorithm fields be implicit in the SPI?
>

If "spi" is present, then everything else is optional.

> **
>
> **2.       **Are the integrity value computed across the fully populated
> header or the SPI header?
>
I would suggest using the SPI header, just because it's simpler, but it
doesn't really matter.  If you trust the out-of-band process, then the two
have equivalent security properties.  I don't really care, since we
shouldn't be computing integrity values over the header anyway (ISSUE-4).

> ****
>
> **3.       **Is there a way to forward a message from person A which
> knows the SPI values and person B which does not?
>
I assume by this you mean
1. C -> A -> B, where C and A share an SPI, and B does not.
2. A does not have to do any cryptographic computations

In this case, the answer is "No".  The answer would be "Yes" if there were
no header integrity check -- A could simply fill in the pre-negotiated
parameters.  But the fact that the header is integrity-protected means that
A cannot do this, so the "spi" remains in place.

****
>
> **4.       **What is the correct algorithm for determining the JWS vs JWE
> in the event that all of the algorithms are implicit****
>
> **
>
Unless you know the SPI, you cannot make that distinction.  But you can't
reliably distinguish JWS from JWE right now anyway.

> 5.       **What happens if you have implicit parameters and explicit
We should specify this, but I don't have a strong feeling for which option
we should choose:
1. SPI wins; b/c more trusted
2. Explicit wins; use SPI as default; override when necessary
3. Throw an error; malformed object

> ****
>
> **6.       **Is there a recommended way to determine what the SPI
> parameters are going to be?  Does the application need to pre-parse the
> message to get the SPI value or is there a recommendation that some type of
> callback be included
>
I would expect an API of a JOSE library supporting SPI to provide an
interface where an app could specify bindings between an SPI and a set of
parameters.  That way, the pre-negotiation protocol could use that
interface to configure the JOSE library, and the JOSE-using application
could just use the normal JOSE interface to process objects.

> ****
>
> **7.       **Can you make things like the IV be implicit?  Thus agree on
> a starting value and an increment and compute the new IV for each new
> message
>
That would be up to the pre-negotiation mechanism.  In general, this
doesn't seem like a good idea; you could think of secure ways to do it, but
it might be fragile.

> ****
>
> **8.       **If you are requiring that the values be populated by the
> application – does this require that you have a canonical encoding of how
This sounds like a good reason to do the integrity check over the SPI
header.

--Richard

> ****
> ** **
> Jim****
> ** **

---

From: Richard Barnes <[email-masked]>
Date: Tue, 2 Apr 2013 14:17:07 -0400

You would be overloading "kid", since it would mean different things
depending on what else is present.  It's not even clear to me how a
recipient would be able to decide which meaning to use.

On Tue, Apr 2, 2013 at 2:08 PM, Hannes Tschofenig <[email-masked]

>> <[email-masked] <mailto:hannes.tschofenig@gmx.**net<[email-masked]>>>
>> wrote:
>>
>>     http://tools.ietf.org/html/__**draft-ietf-jose-json-web-__**
>> encryption-08#section-4.1.10<http://tools.ietf.org/html/__draft-ietf-jose-json-web-__encryption-08#section-4.1.10>
>>
>>     <http://tools.ietf.org/html/**draft-ietf-jose-json-web-**
>>     http://tools.ietf.org/html/__**draft-ietf-jose-json-web-__**
>> signature-08#section-4.1.7<http://tools.ietf.org/html/__draft-ietf-jose-json-web-__signature-08#section-4.1.7>
>>
>>     <http://tools.ietf.org/html/**draft-ietf-jose-json-web-**
>>         ______________________________**___________________
>>         jose mailing list
>>         https://www.ietf.org/mailman/_**_listinfo/jose<https://www.ietf.org/mailman/__listinfo/jose>
>>         <https://www.ietf.org/mailman/**listinfo/jose<https://www.ietf.org/mailman/listinfo/jose>
>> >
>>
>>
>>     ______________________________**___________________
>>     jose mailing list
>>     https://www.ietf.org/mailman/_**_listinfo/jose<https://www.ietf.org/mailman/__listinfo/jose>
>>     <https://www.ietf.org/mailman/**listinfo/jose<https://www.ietf.org/mailman/listinfo/jose>
>> >
>>
>>
>>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Apr 2013 21:20:11 +0300

Just to give you two examples:

http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03
uses a JWE protected JWT.

The key used to encrypt the JWT needs to be pre-configured between the 
authorization server and the resource server. This would be a long-term 
secret.

http://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/
uses an alternative design (a bit outdated already; needs to be 
refreshed) that uses the JOSE work for communication between the client 
and the resource server. The symmetric key used between these two 
parties would be short lived but we still use the JOSE work here.

http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-02

Whether algorithm information is included in the JWS/JWE structure is a 
matter of what you agree with the other party and how.

A requirement for the current documents, however, would be to ensure 
that the parameters are not mandatory because in certain situations you 
may have configured them out of band already.

Reading through the JWS/JWE documents I am not sure whether this is 
allowed or not.

Ciao
Hannes

---

From: Richard Barnes <[email-masked]>
Date: Tue, 2 Apr 2013 14:25:46 -0400

On Tue, Apr 2, 2013 at 2:20 PM, Hannes Tschofenig <[email-masked]

> http://tools.ietf.org/html/**draft-ietf-oauth-v2-http-mac-**03<http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03>
> http://datatracker.ietf.org/**doc/draft-tschofenig-oauth-**hotk/<http://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk/>
> uses an alternative design (a bit outdated already; needs to be refreshed)
> that uses the JOSE work for communication between the client and the
> resource server. The symmetric key used between these two parties would be
> short lived but we still use the JOSE work here.
>
> http://tools.ietf.org/html/**draft-tschofenig-oauth-hotk-02<http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-02>
>
> A requirement for the current documents, however, would be to ensure that
> the parameters are not mandatory because in certain situations you may have
> configured them out of band already.
>

This is exactly my point.  These pre-negotiation cases prevent us from
having clear requirements levels.

The goal of SPI is to explicitly say "SPI indicates that pre-negotiated
parameters are being used, so some things that are otherwise REQUIRED might
be missing."  That way, you can still have fields that MUST be included in
general, but if you include an SPI, you can omit them.

--Richard

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Apr 2013 21:52:57 +0300

On 04/02/2013 09:25 PM, Richard Barnes wrote:
> parameters are being used, so some things that are otherwise REQUIRED
> might be missing."  That way, you can still have fields that MUST be
> included in general, but if you include an SPI, you can omit them.

AHA. Now I got it.

There are two options to address it:

1) Create a new parameter, as you suggested

2) Fix the specs
(to allow parameters like alg to be optional)

---

From: Richard Barnes <[email-masked]>
Date: Tue, 2 Apr 2013 14:57:49 -0400

On Tue, Apr 2, 2013 at 2:52 PM, Hannes Tschofenig <[email-masked]

> (to allow parameters like alg to be optional)

Option 2 is not good, because it means that if you have an object that's
*not* pre-negotiated, you don't know what has to be there.  In fact, both
types of object (with and without pre-negotiation) benefit from Option 1,
since the stronger requirements could be applied in both cases.  In the
pre-negotiated case, you would just apply the requirements after
"rehydrating" the object.

--Richard