On Fri, May 1, 2020, at 14:08, Jonathan Hoyland wrote: > Maybe I'm missing something, but I don't see what your draft adds? If > someone wants to construct a channel binding then they agree with > their peer on a context and a label, and use that to construct an > exporter key.
The draft just registers a method of using it with the IANA Channel Binding Types registry so that you can negotiate and use exported keying material in eg. SCRAM based SASL auth. Right now if I wanted to use EKM for channel binding, what would I negotiate (ie. what would I set the p field of a gs2 header to in SASL based auth?) > Is the idea to reserve the string for some specific use? If so, then > the suggested string is far to general, as it describes _any_ use of > the interface. Yes, that's the idea. This registers the "tls-exporter" channel binding type in the registry, and the label EXPORTER-Channel-Binding to use with it. This is supposed to be a generic channel binding type that can be used to negotiate channel binding when multiple are available, eg. if the server supports both tls-unique (the last TLS finished message) and exporter data, we need an identifier to decide that we want to use exporter data. That also means having a label that we can associate with this context. I'd be happy to change the name if the consensus is that this is too general, but I didn't think it made sense to make this SASL or <other auth system> specific. —Sam _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
