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
