On Mon, Jan 11, 2021, at 17:07, Joseph Salowey wrote:
> 
> 
> On Thu, Jan 7, 2021 at 2:42 PM Martin Thomson <m...@lowentropy.net> wrote:
> > Hi Joe,
> > 
> > Thanks for doing this, I think that this is a distinct improvement (and I 
> > will take your word for the difficulties involved with further splits).
> > 
> > One point that I made poorly perhaps, and was dismissed, might be worth 
> > restating:
> > 
> > MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK", Type-Code, 64) 
> > 
> 
> [Joe] I think you propose something like this instead (eliminating context):
> 
> MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK-" + ASCII-Type-Code, 64) 
> 
> Where + is concatenation and ASCII-Type-Code is "13"

I was not exactly.  I was thinking that EAP-TLS uses the unadorned string and 
other usages (that need a different MSK) define their own string as needed.  
Though what you describe would scale more, if the ordinality of that scale is 
bounded by RFC numbers, defining the extra strings would not be that hard.  You 
could provide some sort of infrastructure in the form of a recommended label 
prefix if you are concerned about misuse.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to