First stage client flow overview for 'sign' command

[lukehinds]

This issue roughly maps out the client flow and implementation milestones.

1. The client performs an open ID connect session towards fulcio which acts as the (relying party). The client opens a browser to the OpenID connect page (login as google, github etc). If the user logins successfully to the identity provider , then fulcio will request the users email address.

2. The client creates a keypair, we are using ecdsa at the moment. ecdsa P256. These keys should not need to be written to disk and can be stored in memory for the transaction of a sign event.

https://ruby-doc.org/stdlib-2.5.3/libdoc/openssl/rdoc/OpenSSL/PKey/EC.html

3. The client then hashes (sha256) the email it received from fulcio at step 1 (which in turn is via the IDP (Google, Github). It signs that hash using the key pair created at step 2.

4. The client constructs a JSON payload which it will then send to fulcio, this includes the following:

{
  "publicKey": {
    "content": "string",
    "algorithm": "ecdsa"
  },
  "signedEmailAddress": "string"
}

publicKey is the pubk from the keypair we created from point 2. signedEmailAddress is from point 3.

We then need to handle the response from fulcio (200, 404, 500) etc. We get sent back a cert, which we might store either into the gem or the disk, however its more of a 'fyi' cert and not important to any other flows, that all happens on fulcios side.

After this we then look at signing the gem and sending the signature to rekor and then the verify command. Let's scope that out in a second, third issue.