Yes, it needs to be clarified in the text that it also refers to the algorithms associated with that key.
And: I noticed that the kid is now a header parameter (which is good). On Feb 7, 2013, at 4:40 PM, Richard Barnes wrote: > As I understood it, 'kid' identifies a key, not the whole collection of > security parameters. But if that's not the case, sure, we can use 'kid'. > > In either case, apparently the spec needs to be clarified. > > > On Thu, Feb 7, 2013 at 1:35 AM, Hannes Tschofenig <[email protected]> > wrote: > Hi Richard, > > when I tried to use the JW* specifications in OAuth my assumption was that > the kid (key id) provides exactly the purpose you outline below (and call > spi). (Btw, I prefer kid rather than SPI). > > The only problem with the KID, as I raised on the list before, is that it > should be in the header and not in the body (since otherwise it would not be > visible when the data inside the body is encrypted. > > Ciao > Hannes > > On 02/07/2013 12:11 AM, Richard Barnes 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 > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
