xtt tool organization

[drbild]

The current xtt appears to me (i.e., this is my opinion!) like an arbitrary collection of commands, not a cohesive xtt utility.

Take the six actions today:

1. genkey (ecdsa)
2. gen509cert (x509 cert)
3. wrapkeys (ASN.1 wrapped keys)
4. genrootcert (root cert)
5. genservercert (server cert)
6. infocert (any cert)

I see the following inconsistencies (not an exhaustive list):

• One of the commands specifies something about the data format (x509); the rest do not.
• The gen cert commands are split by type (x509, server, and root); the info cert command is combined.
• The genkey help string mentions the underlying crypto details (ecdsa). The wrapkeys and various cert commands do not mention the underlying crypto details.
• None of the commands reference the terminology used in our discussions, e.g., provisioning key (DAA) vs identity key (formerly ed25519, now ecdsa).
• 5 of the command names are a combined verb and noun (gen/wrap and key/cert). The 6th is two nouns, info and cert.

I think it's worth discussing an organization for these commands.

Should the "types" of cert and key be based on the usage (e.g., root, identity, server) or should they be based on structure (e.g, ecdsa, x509, ed25519).

Should the commands be organized beyond just a single action? E.g., "xtt cert show", "xtt cert generate", "xtt keys generate", "xtt keys show --public".

What additional commands are planned or desired? Getting those documented (perhaps as strawman usage strings in this issue thread) would be helpful.

[kathrynfejer]

Usage	Command	Component	Structure
Root	Generate	Keypair	ASN.1
Server	Run	Certificate	x509
Client	GetInfo
NVRAM	Read

These commands could be laid out into four parts.

One slightly difficult part in naming these is that commands, right now, do not necessarily use all 4 parts. For example, the x509 certificate does not have a specific usage(root, identity, server), and the server and root certificates do not have a "structure" that we have a name for--since no one else uses this structure. Edit: This may have changed since the decision to create x509 extensions for both the server and root certificate--it may be enough to say that the key pair is always ASN.1 and any certificate is always in x509 format.