Yes, "kid" is used to identify keys. From: [email protected] [mailto:[email protected]] On Behalf Of Richard Barnes Sent: Thursday, February 07, 2013 6:40 AM To: Hannes Tschofenig Cc: [email protected] Subject: Re: [jose] SPI - KID conflict -- Re: SPI proposal
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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
