BTW, what JSON data type did you intend to be used for the "spi" value? A JSON
string? A string with any structure, or an unconstrained Unicode string? A
base64url-encoded byte sequence?
-- Mike
From: Mike Jones
Sent: Wednesday, February 06, 2013 2:27 PM
To: 'Richard Barnes'; [email protected]
Subject: RE: [jose] SPI proposal
Thanks for writing this up, Richard. I believe that captures the intent fairly
well.
As we'd discussed off-list, I believe that it would be more consistent if, in
the case were you are using a previously cached "spi" value, that the header
contained "alg":"spi" and "spi":spi-value. That would maintain the invariant
that implementations always use the "alg" value to determine what the rest of
the structure is - albeit in this case, via an indirection.
Also, then we'd register "spi" like any other "alg" value. Other algorithms
specify the use of particular header parameters. This one would be no
exception. Registering it as an algorithm would also make it clear that it is
up to implementations whether to support it or not.
I don't feel super-strongly about this, but I always try for consistency, where
reasonable. I think that this is such a case.
Again, thanks for the write-up to help move this forward.
Cheers,
-- Mike
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Richard Barnes
Sent: Wednesday, February 06, 2013 2:12 PM
To: [email protected]<mailto:[email protected]>
Subject: [jose] SPI proposal
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
[email protected]
https://www.ietf.org/mailman/listinfo/jose
