Re: [jose] Proposal about the SPI proposal

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:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf
> Of *Richard Barnes
> *Sent:* Wednesday, February 20, 2013 10:04 AM
> *To:* Nat Sakimura
> *Cc:* Brian Campbell; jose@ietf.org; 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 <sakimura@gmail.com> wrote:
> ****
>
> ditto. ****
>
> 2013/2/11 Edmund Jay <ejay@mgi1.com>****
>
> +1 for new I-D.
>
> ****
>
> ** **
>  ------------------------------
>
> *From:* Brian Campbell <bcampbell@pingidentity.com>
> *To:* "jose@ietf.org" <jose@ietf.org>
> *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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=nat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>