I was thinking base64-encoded binary. --Richard
On Wed, Feb 6, 2013 at 5:28 PM, Mike Jones <[email protected]>wrote: > 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]<[email protected]>] > *On Behalf Of *Richard Barnes > *Sent:* Wednesday, February 06, 2013 2:12 PM > *To:* [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
