Re: [Rift] RIFT fingerprint coverage

[Bruno Rijsman <[e-mail]>]

> I don't like the change of inner security key name, we may one day protect something else than TIEs with it and on top it makes the naming less intuitive, the outer and inner works really well IMO

I am perfectly fine with calling it inner security key instead of TIE origin security key.  Actually, I also like that better.

I only called it TIE origin security key because it is part of what is currently called (and AFAIK has always been called) the TIE Origin Security Envelope Header.  So, I was just trying to be consistent with what was already there.

Soooo…. if we agree to call it inner security key then we should consistently call it inner security key / inner security key id / inner security fingerprint / inner security envelope header everywhere and purge any mention of TIE origin key / TIE origin key id / TIE origin security fingerprint / TIE origin security envelope header completely from the draft (and code for that matter, at least the CLI and yaml files).

Speaking of consistency: we should decide whether it is “inner key” or “inner security key” or “inner authentication key” and be consistent about that as well.  In RIFT-Python followed your RIFT-Juniper example and used “authentication key” instead of just “key” or “security key”.

I propose we use the following going forward:

outer authentication key
outer authentication key id
outer authentication fingerprint
outer authentication envelope (or "outer authentication envelope header” but that seems redundant)

inner authentication key
inner authentication key id
inner authentication fingerprint
inner authentication envelope (or “inner authentication envelope header” but that seems redundant)

Final obsessive compulsive nitpick :-) :  in the Thrift data model we should be consistent in CamelCaseNamingStyle for types and underscore_naming_style for variables (for example: type InnerAuthenticationKeyID and constant invalid_inner_authentication_key_id).

— Bruno