-----BEGIN----- Section 4.1.X. "spi" (Security Parameters Index) Header Parameter
The "spi" (Security Parameters Index) header parameter contains a base64url-encoded 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 use an out-of-band mechanism to negotiate cryptographic parameters. Entities using an out-of-band negotiation mechanism maintain a table of cached security parameters. The maintenance of this table, e.g., how entries are added or removed, is done by the out-of-band key management protocol. Each entry in the table is indexed by an SPI value, and contains pre-negotiated parameters for the JWE, such as values for the "alg" or "zip" parameters, or a value for the Encrypted Key component. A JWE whose header contains an SPI value MAY omit the Encrypted Key component, by making this field zero-length in the compact serialization. An entity receiving such a JWE reconstructs the full JWE by adding the cached header fields to the header, and adding the Encrypted Key components to the JWE. The reconstructed JWE is then processed as normal. If a JWE object contains an unrecognized SPI value, then the recipient MUST consider it invalid. The out-of-band management protocol MUST ensure that the SPI value is unique within the sender's context. To prevent the SPI value from being used to interfere with JOSE processing, the management protocol SHOULD also ensure that it is difficult for a third party (who has not participated in the management protocol) to guess an SPI value. As a simple way to meet both of these requirements, it is RECOMMENDED that the SPI value be a 128-bit random value. -----END----- On Wed, Feb 27, 2013 at 1:50 PM, Richard Barnes <[email protected]> wrote: > Ah, sorry I never got around to those. Responses inline. > > - What are the security implications of repeatedly reusing the same >> CMK and IV and how can/should they be mitigated? >> > > Good point. Re-using IVs is a terrible idea. SPI should represent some > set of pre-negotiated parameters, where the set of parameters that are > pre-set is part of the pre-negotiation. So one application might > pre-negotiate algorithms, but pass keys in-band, but another might > pre-negotiate algorithms and keys. (You could even envision agreeing on an > IV generation procedure...) > > >> **** >> >> - Is having the absence of an “alg” field, paired with the presence of >> an “spi” field the best way to handle this? >> > > "alg" is an indicator of key wrapping technique. So if this is one of the > pre-negotiated parameters, then it should be absent. > > >> **** >> >> - What are the complexity implications of having JWEs no longer contain >> a fixed set of field? >> > > Very little. SPI would add a little pre-processing to populate the > missing fields in a JWE/JWS > > >> **** >> >> - Would JWSs similarly have a different number of fields? >> > > Yes. > > >> **** >> >> - Indeed, is the proposal even applicable in the JWS case, or does it >> only make sense for JWEs? >> > > There's less of a need for JWS. You could say SPI "1234" indicates that > I'm signing under a given 4096-bit RSA key, saving yourself hundreds of > octets. So it would be like "jku", with fewer octets and without the > implication that you could go fetch it over the Internet. > > >> **** >> >> - What are the motivating use cases for this functionality? >> > > As I said before, cases where there's some out-of-band mechanism to > pre-negotiate certain parameters. For example, the OpenID Connect > discovery process. > < > http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest > > > > > >> **** >> >> - What syntax would be used for the “spi” parameter? Unrestricted >> Unicode strings? Base64url-encoded byte strings? UUIDs? … >> > > Doesn't really matter. Make it the same as "kid" (i.e., string); they're > both opaque identifiers. > > > >> **** >> >> ** ** >> >> I don’t think a number of them have been answered.**** >> >> ** ** >> >> Thanks,**** >> >> -- Mike**** >> >> ** ** >> >> *From:* [email protected] [mailto:[email protected]] *On Behalf >> Of *Richard Barnes >> *Sent:* Wednesday, February 20, 2013 10:04 AM >> *To:* Nat Sakimura >> *Cc:* Brian Campbell; [email protected]; Edmund Jay >> *Subject:* Re: [jose] Proposal about the SPI proposal**** >> >> ** ** >> >> Obviously, this will not be in a -00 draft for Orlando. So discussion >> should continue based on the text proposed to the list.**** >> >> ** ** >> >> Does anyone have further technical comments?**** >> >> ** ** >> >> --Richard**** >> >> ** ** >> >> On Wed, Feb 20, 2013 at 11:25 AM, Nat Sakimura <[email protected]> >> wrote:**** >> >> ditto. **** >> >> 2013/2/11 Edmund Jay <[email protected]>**** >> >> +1 for new I-D. >> >> **** >> >> ** ** >> ------------------------------ >> >> *From:* Brian Campbell <[email protected]> >> *To:* "[email protected]" <[email protected]> >> *Sent:* Fri, February 8, 2013 3:01:51 PM >> *Subject:* [jose] Proposal about the SPI proposal**** >> >> ** ** >> >> Maybe this was apparent from my comments/questions on the SPI proposal >> over the last couple days[1] but I have concerns that run the gamut from >> operational complexity and fragility to security problems. I believe >> strongly that, without considerably more analysis and specification detail, >> the current SPI work is much too risky to consider go in the current base >> JOSE WG drafts.**** >> >> As an alternative I'd like to request/propose that the SPI stuff be >> submitted as new I-D to help facilitate that additional discussion and >> analysis that I think it needs.**** >> >> ** ** >> >> Thanks, >> Brian**** >> >> >> [1] http://www.ietf.org/mail-archive/web/jose/current/msg01500.html**** >> >> ** ** >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose**** >> >> >> >> **** >> >> ** ** >> >> -- >> Nat Sakimura (=nat)**** >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en**** >> >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose**** >> >> ** ** >> > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
