Re: [Unbearable] ramifications of longer EKMs

[Andrei Popov <[e-mail]>]

Ø  I'm not sure I follow this?

Ø  I'd think, if this kind of model was used, a TTRP could do all the TB validation work and just expose the TB ID(s) to the backend where they can bind to whatever tokens/cookies they are issuing.
Sure, this design would work. My point is that the tokbind-tls-term document cannot require one particular model of TB processing, because if this one model does not meet a data center’s requirements/architecture, the document is easily ignored. And it would be particularly undesirable to lose the “dumb/slim” TTRP model.

Ø  The backend apps would only be able to use TB key parameters that the TTRP supports but that's pretty much true of the other model too - the TTRP still is the one negotiating.
Backend could pass the TB key parameters to the TTRP, or these could be part of the TTRP configuration. All the “dumb/slim” TTRP needs to know is TB protocol version and a prioritized list of TB key parameter IDs.

Ø  It only defeats the purpose of having per-signature-scheme EKM lengths in the case of a refereed TB using a longer EKM than the provided.
Let’s say a client negotiates signature scheme A with the RP, and signature scheme A calls for a 64-bit EKM. Then the client negotiates a signature scheme B with the IDP, and signature scheme B calls for a 32-bit EKM. The client sends Provided and Referred bindings to this IDP, and the Referred binding uses signature scheme A in combination with an EKM length 32 (which does not agree with the signature scheme definition). Is this what you’re proposing as option 4), or did I get it wrong?