Re: [jose] SPI proposal

The motivation here is not very deep.  A lot of the current design (e.g.,
the three-letter names) is focused on reducing header size.  The SPI
proposal further compresses header size in cases where two entities will be
exchanging many JOSE objects.  I understood from some discussions with
OpenID folks that this was often the case for their use cases.

Obviously, you could build a whole management protocol around this stuff
(cf. IKE for IPsec).  Whatever application is using this would need to
figure out how to deal with the issues you note, as well as things like
what happens when an object shows up with an unknown SPI.  (I don't think
collision is an issue, if you can scope to sender; the sender just ensures
uniqueness.)  The idea of this basic proposal is to establish the basic
behavior, around which you could then wrap more advanced management.

--Richard

On Thu, Feb 7, 2013 at 9:42 AM, Brian Campbell
<bcampbell@pingidentity.com>wrote:

> Admittedly I'm not really up on this spi issue or the motivation behind it
> but a couple questions came to mind when I saw this. How does the receiver
> protect against unbounded growth of the cache? And index collision? And for
> distributed environments, it seems supporting this could be very cumbersome.
>
>
>
>
>
>
>
>
> On Wed, Feb 6, 2013 at 3:11 PM, Richard Barnes <rlb@ipv.sx> wrote:
>
>> To move us toward closing Issue #9 [9], here is some proposed text for an
>> SPI [1] field.  To recall, SPI stands for "security parameters index",
>> borrowing a term from IPsec.  The idea is that in cases where the same
>> crypto parameters are being used repeatedly, this would save the parties
>> from having to re-send the same parameters.
>>
>> The below text is designed for the JWE spec, but could be adapted for JWS
>> (just keep header, ignore part about key/iv).  Similar text is probably
>> needed for the encryption/decryption/signing/verification sections.
>>
>> Feedback welcome,
>> --Richard
>>
>> -----BEGIN-----
>> Section 4.1.X. "spi" Header Parameter
>>
>> The "spi" (Security Parameters Index) header parameter contains an opaque
>> byte string that labels a set of security parameters.  This index is
>> designed to enable the use of smaller headers in cases where entities will
>> be re-using the same security parameters for several messages.
>>
>> Entities supporting the use of the "spi" parameter MUST maintain a table
>> of cached security parameters.  When an entity receives an object whose
>> header contains both "spi" and "alg" values, then it MUST cache the
>> following values from the JWE, indexed by the "spi" value:
>> -- Contents of the JWE header
>> -- Encrypted Key
>> -- Initialization Vector
>>
>> If an object containing an "spi" parameter but no "alg" parameter, then
>> it MUST NOT contain an Encrypted Key or Initialization Vector.  That is, it
>> will have the form "header.ciphertext.integrity_value".  When a recipient
>> receives such an object, it uses the "spi" value to retrieve cached header,
>> key, and initialization vector and reconstructs a full JWE.  This full JWE
>> can then be further processed according to the normal JWE processing rules.
>>  If the recipient has no cached parameters for the "spi" value, the process
>> MUST fail.
>> -----END-----
>>
>>
>> [9] http://tools.ietf.org/wg/jose/trac/ticket/9
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>