# RAW Materials Used to Prepare Attestation Flow page

###### tags: `Notes`
:::info
### Saved for reference
:::

:::warning
**Raw notes captured from a review:**
Update the deployment information to include the information about priming and keeping the information
Systemd service
Operator
Tool to fetch and store the CPU and related keys data.
Var/cache/Intel/SGX
var/cache/AMD-SEV - local machine certificate in the cert chain for attestation it comes from AMD and needs refreshed periodically after the firmware update
Vendor information
Top part of the chain is baked into Steward
Middle and bottom is needed
Bottom is generated
Middle is not keep specific
Middle part of the chain is CPU information
VCEK certificate
PCK certificate
Certificate chain CRL
Store as is what we fetched
:::

## Full diagram

sequenceDiagram
    participant publisher
    participant drawbridge
    participant steward
    participant guest
    participant host
    participant relparty


    Note over publisher,relparty: Workload publisher stages workload

    publisher ->> publisher: prepares a workload on local filesystem
    Note right of publisher: a workload contains: wasm(s), config and assets

    publisher ->> publisher: stages workload via `enarx publish`
    publisher ->> publisher: `enarx publish` signs workload with wsigkey owned by publisher
    publisher ->> drawbridge: upload workload (authenticated)

    Note over publisher,relparty: Get and validate package metadata
    
    host ->> guest: repo.domain/user/pkg:version[@wdig]
    Note left of host: format?

    guest ->> drawbridge: get workload public metadata using slug
    drawbridge ->> guest: steward + wdig [+ wsig]

    opt host gave wdig
        guest ->> guest: validate wdig equality
    end

    opt metadata has wsig
        guest ->> guest: validate workload signature
        Note over guest: this validates the signature but NOT trust of the pubkey
    end

    Note over publisher,relparty: Establish workload identity

    guest ->> guest: get platform type [nil, kvm, sgx, snp]
    guest ->> guest: generate TLS keypair
    Note right of guest: Cert URI SAN: slug [w/o wdig]
    Note right of guest: Cert URI SAN: wdig

    opt wsig is present
        Note right of guest: Cert URI SAN: hash(wsig pubkey)
    end

    alt keep
        guest ->> guest: get attestation (hash(TLS pubkey))
        Note right of guest: Cert Extension: attestation blob

        guest ->> guest: generate signed CSR for TLS keypair
        guest ->> steward: CSR (Steward API)
        steward ->> steward: validate attestation*
        Note right of steward: *see Steward documentation
        steward ->> guest: cert
    else not a keep
        guest ->> guest: issue self-signed cert
    end

    Note over publisher,relparty: Download and execute workload

    guest ->> drawbridge: TLS client auth using cert
    loop recursively fetch workload contents
        guest ->> drawbridge: fetch one workload content item
        drawbridge ->> guest: workload content item
        guest ->> guest: validate workload content item digest
    end

    guest ->> guest: start running workload

    Note over publisher,relparty: Attest to relying parties
    alt Connection initiator
        guest ->> relparty: TLS auth via cert (server or client)
    else
        relparty ->> guest: TLS auth via cert (server or client)
    end

flowchart TD
    Blob
    Pdata[Platfrom data]
    Firmware
    subgraph CSR [CSR]
        Metadata
        PubKey2[Pubkey Key copy]
        Attestation2["Attestation blob copy"]
    end
    subgraph PKI [PKI Pair]
        PrivKey[Private Key]
        PubKey[Public Key]
    end
    Content["Drawbridge
             User
             Name 
             Tag
             Hash
             Signature"]
    Message
    Attestation["Attestation blob"]
    Steward((Steward))
    PrivKey<--A PKI pair-->PubKey
    PubKey--Included-->Message
    Message--Hashed-->Blob
    PubKey--Included-->PubKey2
    Content--"What else is included???"-->Metadata
    Content--"What else is included???"-->Message
    CSR--sent for validation and signing-->Steward
    Blob--"get_attestation()"-->Firmware
    Firmware--Return-->Attestation
    Attestation--Included-->Attestation2
    Pdata--"???"-->Attestation
    Firmware--"???"-->Pdata
    Pdata--"???"-->Attestation2
    Pdata--"???"-->Message

### Prerequisites
The attestation flow assumes that the following allready happened:
* A public (Profian operated) instance of Steward service is accessible from a target system or Customer deploys a private Steward service.
* A public (Profian operated) instance of Drawbridge service is accessible from a target system or Customer deployes a private Drawbridge service. Drawbridge is configured to use a specific instance of Steward (in general, customer can choose to use different instances of Steward for different workloads). By default, without any override, the deployed public or private instance of Drawbridge assumes the public instance of Steward. This means that a private instance of Drawbridge will work with a public or private (if deployed and configured) instance of Stewerd, but some instance of Steward is always required.
* User prepared (packaged) a workload to run in a keep.
* User created a signature for the workload using his own method and tools.
* User uploaded the workload and its signature into the Drawbridge. The security of this step is protected by the user identity (established via authentication).
* User triggered a sequence (TBD) of deploying workload to a keep. As a result of this flow:
* Enarx packages are deployed on a target machine. Possible delivery methods include:
* RPM
* Container (Docker/Kubernetes/Nomad)
* ... (???)
* Enarx keep is started on a target machine `enarx deploy [reference to the workload]` passing in a so called "slug", a reference to a workload in format: ???. The launch may also optionally include a hash of the workload.

Open questions:
* *What are the accepted deliver methods? Are containers via Docker/Kubernetes supported? Are there any concerns/issues with that?*
* *How the actual delivery happens? Do we have anything to prescribe?*

### Flow overview
* Enarx keep is started. Slug (workload identifier) is passed in. Hash of the workload is optionally passed in.
* Enarx calls Drawbridge to get the hash and signature of the workload. This connection happens over TLS leveraging embedded Mozilla certificates. No authentication is needed.
* Drawbridge checks the workload identifier and returns:
* Steward URL to use
* Hash of the workload to check
* Signature of the workload to check
* Enarx
* If hash was provided during launch then Enarx compares hash passed at launch with the the hash acquired from Drawbridge
* If user uploaded a signature then Enarx validates provided signature.
* Enarx:
* Collects platform information
* Generates a PKI pair

Note: for ther next step see the flow chart later in the document.

Open questions:
* *What is the "hash of the workload"? How is it constructed?*
* It is a hash of the workload that storeed in the Drawbridge
* *What is the slug format?*
* *What is tag and how it is different from slug?*
* *Is there DOS attack concern regarding the "get tag" call?*
* *Can this be used to try to brute force/guess someone's tag/slug? Should we use hash og the tag instead? It would be much harder to brute force. Should we consider the response encrypted with "pepper"?*
* *Should Drawbridge have a way to not accept connections from undefined subnets?*
* *What does it actually mean to validate a signature in this situation?*
* *What does it actually mean to collect platform infromation in this case?*