Re: [jose] SPI proposal

[Brian Campbell <[e-mail]>]

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 <[e-mail]
> 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 <[e-mail]> 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 <
> [e-mail]> 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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/jose
> >
> >
> >
> >
> > _______________________________________________
> > jose mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/jose
>
>