TIK and the relationship between drafts

[yaronf]

There's a "TIK" mentioned in Fig. 8 and Fig. 9, but not anywhere else in the document (and not in draft-bft-rats-kat either). We need to clarify/rename this element.

At a higher level: we should "close the loop" on generation/attestation of keys by formalizing the whole process in the document with normative language. Right now all we're saying is:

for example, using the PoP key in the KAT evidence [I-D.bft-rats-kat]

IMO this is critical for formal validation to be meaningful.

[ionut-arm]

I'll be plugging the terminology hole related to TIK.

Regarding a formalization of the identity key generation/attestation, I'd argue a more appropriate place for that would be in the KAT draft, though that draft is a bit bare-bones at the moment. Or do you reckon describing this in the context of TLS would have some benefits?

[yaronf]

@ionut-arm If we want modularity, i.e. a single TLS draft and then multiple token "plug in" drafts, then the TLS draft need to define very clearly what are the security expectations from any such plug in.

The value of such modularity is limited IMHO, and it may be better to start with one unified draft, get it adopted by the TLS WG, and then if multiple proposed token/key types appear, move towards modularity.