I believe the "kid" Key ID header parameter already meets the need for named keys.
On Sat, Feb 9, 2013 at 4:45 AM, Hannes Tschofenig <[email protected] > wrote: > Hi Brian, > > keys need to have a name. > > Whether you call it SPI, key id, or something else does not really matter. > > It also does not matter whether the keys (and the associated parameters) > are established manually, or using some key management. > > In the context of OAuth there are actually various keys flying around and > therefore they need to have different names. > I was referring to the key used between the client and the resource server > when used with > > I believe even without Richard's proposal the necessary pieces are already > in the current document; what is need is to further clarify them. > Ciao > Hannes > > On Feb 8, 2013, at 4:21 PM, Brian Campbell wrote: > > > Seems to me that, in the absence of more advanced management, the use of > spi is potentially very very fragile. And that, in many cases, such > advanced management would be a lot more trouble than it's worth. But maybe > I'm missing the bigger picture. > > > > My own applications of JOSE are in OpenID and OAuth (and similar) and > the JOSE message is generally sent from one entity to another thought a web > browser user agent as an intermediary. That situation doesn't lend itself > well to use of spi or even easily creating some management protocol around > it. > > > > WRT collision and scoping to sender, I had the same thought but there's > not, AFAIK, a reliable way to identify the sender. No? > > > > Anyway, I get the point of just establishing the basic behavior. But I'd > like to be careful not to inadvertently impose a lot of complexity or > potential operational or security issues when doing so. > > > > > > > > > > > > > > On Thu, Feb 7, 2013 at 7:52 AM, Richard Barnes <[email protected]> wrote: > > 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 < > [email protected]> 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 <[email protected]> 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 > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
