Re: [Unbearable] ramifications of longer EKMs

[Brian Campbell <[e-mail]>]

Thanks Andrei.

I admit to having had some fondness for option 4). But I guess, at this
point, I'd lean towards 3) as well. It simplifies the TTRP case as well as
server processing logic (assuming the logic would be generalized to
accommodate future TB key params with a longer EKM).


On Thu, Feb 23, 2017 at 2:00 PM, Andrei Popov <[e-mail]>
wrote:

> Tokbind-tls-term does not necessarily have to be on the standards track,
> but I think the issue Brian has raised deserves discussion regardless of
> the destiny of tokbind-tls-term.
>
>
>
> WRT Brian’s listed options, I prefer 3) or, failing that, 1).
>
> Option 2) affects the tokbind-tls-term document, not the core I-Ds; from
> the core I-D perspective it is identical to option 1).
>
> Option 4) makes the TB key parameter negotiation less definitive. It says
> that the length of the EKM now depends not only on the signature scheme of
> the TB key that signs this EKM, but also on the type of the Binding, and on
> the signature scheme of a different, unrelated TB key.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Anthony Nadalin
> *Sent:* Thursday, February 23, 2017 9:54 AM
> *To:* Brian Campbell <[e-mail]>; Andrei Popov <
> [e-mail]>
> *Cc:* IETF Tokbind WG <[e-mail]>
> *Subject:* RE: [Unbearable] ramifications of longer EKMs
>
>
>
> I’m not sure the value of standardizing the tokbind-tls-term, not sure how
> much interoperability requirements there are here, maybe this should be an
> experimental until we figure out if there is a need and if so what are the
> requirements
>
>
>
>
>