Sorry, meant to start with: Revised text for the SPI proposal follows. On Fri, Mar 8, 2013 at 2:26 PM, Richard Barnes <[email protected]> wrote:
> -----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
