Proposed Specification for New Consumer-Server Commnunications

[Nathan D. Bowen]

Paul Crowley wrote:

> I slightly prefer mac_secret, since it's possible to imagine that 
> future protocols might include other secrets.  Or come to think of it, 
> mac_key, which is even more straightforward and even shorter.

mac_key and enc_mac_key are looking great.

Just one more little question about one more little variable name, if 
it's not too much to ask...

Any chance that 'enc' is still negotiable?
Since future protocols might encrypt something other than secrets, or 
might specify some type of 'enc'oding, could we change 'enc' to anything 
that makes sense but includes more of "mac key encrypted with=" or 
"encryption type of mac key="?

"MAC Key Encryption" would unfortunately succest "mac_key_enc" which 
won't cut it next to "enc_mac_key".

I don't love any of these, but for the sake of brainstorming:
    mac_key_encryption
    mac_key_enc_type
    mac_key_enctype

Actually, maybe mac_key_enctype's pretty good.

> Thanks for continuing to push for this sort of thing, it's making a 
> better protocol in a way that will last.

Well, thanks for spending your time with this, too, and helping to keep 
the crypto vocab accurate, for the same reason.