# Open Enclave SDK SIG-Attestation Meeting

**When:** weekly at 10am Wednesday, US West Coast [(convert to your local timezone)](https://www.thetimezoneconverter.com/?t=10:00&tz=PT%20%28Pacific%20Time%29)

Join Zoom Meeting
https://zoom.us/j/93385124853?pwd=YWJOY0E2Tnp5VHhlNUtuU3hrSnArdz09

Meeting ID: 933 8512 4853
Passcode: 470887

## Scope and Mission

This meeting is a place for technical discussions related to attestation architecture.

Rather than having informal architecture discussions during the Triage meeting, we are creating this meeting as a dedicated space for all interested parties and stakeholders to come together and drive consensus on difficult and often cross-domain questions. Broadly speaking, if it might relate to a [design document](https://github.com/openenclave/openenclave/tree/master/docs/DesignDocs), it's probably in scope for this meeting.

The Open Enclave project values being a friendly and inclusive space. This meeting is open to all community members. Everyone is asked to abide by the procedure documented below, and reminded that the community follows a [Code of Conduct](https://github.com/openenclave/openenclave/blob/master/docs/CodeOfConduct.md).

## Procedural Guidelines

The chair of the next meeting should attempt to **establish an agenda before the meeting**, but attendees may (and should) add to the agenda themselves in this shared document. hackmd.io is a collaborative editing tool, and everyone is welcome to edit this in real-time as well.

**At the start of the meeting**, the chair should ask for a volunteer to take minutes and roll call. Minutes should capture any decisions made and action items discussed. Minutes are stored in this document, and are public.

The chair should **get consensus on the agenda**, editing as appropriate. It is the chair's job to ensure that the meeting then follows the agenda, and that everyone is given an equal chance to speak.

Because the community is distributed by nature and this meeting may not include everyone every time, any decision must be followed up with an artefact (for example, a PR or an email to oesdk@ mailing list) to record the outcome.

### 18 May, 2022 10:00 AM PDT
(Cancelled)

### 20 April, 2022 10:00 AM PDT
Chair: Andy
Minutes: Ryan

* (Radhika, Rathna, Dave, Yen) Issue [4456](https://github.com/openenclave/openenclave/pull/4456): change names of generic claims to be non-sgx specific.
* Main focus: `OE_CLAIM_SGX_PCE_SVN`, `OE_CLAIM_SGX_QE_ID`, `OE_CLAIM_SGX_FMSPC`
* [Dave] I will join the meeting at around 20 after the hour, I have a conflict until then.
* [Andy, Yen] `software_svn` and `platform_id` do the job of getting away from SGX-specific terms, but "PCE security version" and "Quoting Enclave ID" in the details should go away.
* [Mark] PCE is something specific, not compatible to most general cases.
* [Yen] Any alternatives (to the naming)?
* [Mark] We'll need to discuss it.
* [Yen] If there is no way can we rename those claims to something that sounds non-SGX-specific, then we can move them to SGX header files. We'd like to hear what Dave thinks, too.

Next chair: Yen

### 6 April, 2022 10:00 AM PDT
(Cancelled)

### 23 March, 2022 10:00 AM PDT
(Cancelled)

### 09 March, 2022 10:00 AM PST
Chair: Andy
Minutes:

(Cancelled)

### 23 February, 2022 10:00 AM PST
Chair: Yen
Minutes: Francisco

* (Andy, Dave, Shiv) Issue [4367](https://github.com/openenclave/openenclave/pull/4367): Propose an API change for verifying quotes with collateral baselines
* Dave has some comments in the PR to clarify/correct some of the wording in the doc.
* Andy will check if the APIs are internal/external, since there is no need for backward compatibilities if it's internal only
* Dave: Consider a way to avoid relying on #define'd strings. If there is one missing, customers may write their own string, leading to a possible way to make an error that is hard to correct. There is no compile-time errors though. ENUM may suffer from same issue. One possible way would be to use a union/struct, which are type-safe.

Next chair: Andy

### 9 February, 2022 10:00 AM PST
Chair: Ryan
Minutes: Yen

* (Andy, Dave, Shiv) Issue [4367](https://github.com/openenclave/openenclave/pull/4367): Propose an API change for verifying quotes with collateral baselines
* Two main files: "Attestation SGX QPL Enforcement Support" and "Remote Attestation Collaterals"
* (Dave) Do we need any SGX-specific APIs that is public in OE?
* (Shiv) This is for verifier. MAA is the possible consumer
* (Yen) I prefer TEE-agnostic APIs, and they don't need to be SGX-specific.
* (Dave) Strong-type and TEE-agnostic API is preferred.
* (Shiv) This is a pass-through API. Contract between caller (MAA) and quote/collateral/endorsement provider (QPL). It will be great the param to the API is opaque.
* (Dave) String value is not opaque. Blob is opaque. Maybe Intel can modify the QPL API to be strong-type.
* (Francisco) Intel typically prefers strong type.
* (Dave) Compile time error is better than run-time error. Prefer strong type.
* (Shiv) Perhaps define a struct as a contract between caller and provider
* (Dave) Cloud provider routing destination maa.h defines the structure for blob between MAA and QPL. Strongly typed. OE has a general API but caller includes cloud-specific header.
* (Dave) Attestation Plug-in recognizes the policy type. It knows who to pass the blob to but does not parse the content.
* How to define new policy_type in generic header but individial attestation plug-ins knows this is the policy_type it should handle?
* (Dave) oe_policy_type_t with sub policy_type. For examples UUID as sub type to avoid collision.

* (Ming-Wei) Issue [4202](https://github.com/openenclave/openenclave/issues/4202): New verifier plugin (or relying party APIs) for SGX that support specific attestation service
* Any updates on this?

Next chair: Yen

### 17 November, 2021 10:00 AM PST
(Cancelled)

### 3 November, 2021 10:00 AM PDT
(Cancelled)

### 20 October, 2021 10:00 AM PDT
(Cancelled)

### 6 October, 2021 10:00 AM PDT
Chair: Shanwei
Minutes: Yen

* (Ming-Wei / all) update / close on issue [4202](https://github.com/openenclave/openenclave/issues/4202): New verifier plugin (or relying party APIs) for SGX that support specific attestation service
* Will move to the next meeting
* (Dave): Layered claim sets
* https://github.com/openenclave/openenclave/issues/4033
* https://github.com/openenclave/openenclave/pull/4273
* Dave: On the attester side, there is no need to modified as the claims are collected by the attester plugins/platform internally. The only user input is custom claim which is out of scope of this design.
* Dave: Current API only covers case 1 with single layer and 2 nested claims: init-time and run-time.
* Dave: Namespace or category can be split into each claim set. It's not specifically called out in this design.
* Dave: PR was submitted 15 minutes before the meeting. Will fill in more details.
* (Yen): (no issue yet, just brain storm) Pass in "endorsement baseline" (e.g. SGX collateral data evaluation number) to oe_verify_evidence()
* Dave/Shanwei - sounds good but would like to see proposal.
* Yen - baseline will likely be an integer that increases over time. For SGX, it maps to data evaulation number in the collateral.
* Dave - Integer sounds good for other platforms such as OPTEE.
* Shanwei - what if the baseline is invalid? Best match or just fail?
* Yen - Was thinking exact match but might not be the best approach. Will think about this.
* (All) Update on [SIG-attestation projects](https://github.com/openenclave/openenclave/projects/18)

Next chair: Ryan

### 22 September, 2021 10:00 AM PDT
Chair: Mark
Minutes: Ryan

* (Yen) Update on issue [4105](https://github.com/openenclave/openenclave/issues/4105) update on [proposal](https://github.com/openenclave/openenclave/issues/4105#issuecomment-879473833) for `oe_verify_evidence()` to return OE_OK for all non-terminal TCB status
* (Mark) Postpone it to v1.0? I can get back to take a look at the proposal.
* (Yen) In 2 to 3 months. One of the main attestation issues on our mind but we haven't got many resources yet.
* (Ming-Wei) Update on issue [4201](https://github.com/openenclave/openenclave/issues/4201): API for parsing an evidence without verification
* (Mark) Perhaps we can set a milestone for it.
* (Ming-Wei) I can update that.
* (Ming-Wei) Update on PR [4138](https://github.com/openenclave/openenclave/pull/4138) and [4237](https://github.com/openenclave/openenclave/pull/4237) for attested TLS API design and implementation

Next chair: Shanwei

### 08 September, 2021 10:00 AM PDT
Chair: Ming-Wei
Minutes: Ryan

* New attested TLS APIs:
* Design doc: PR [4138](https://github.com/openenclave/openenclave/pull/4138)
* (Dave / Shanwei) When do we use what is in inittime and runtime custom claims buffers?
* (Dave) Backward compatibilities while adding new fields to `evidence_buffer`.
* (Dave) Should inittime and runtime custom claims buffers be in evidence buffer instead?
* Implementation PR [4237](https://github.com/openenclave/openenclave/pull/4237)
* (Dave) `oe_parse_layered_evidence`: What does "layered evidence" mean? Arbitrary number of sets of claims also?
* (Dave) Add SGX to function names as this is SGX-specific? (no)
* (Shanwei) That should be fine as it is for internal use.
* (Ming-Wei) Once we have new plugins we need some verifiers for them, hence the new OID `oid_oe_attestation_result`.
* Discuss issue [4201](https://github.com/openenclave/openenclave/issues/4201) next week.
* Moved to in-progress list

Next chair: Shanwei

### 25 August, 2021 10:00 AM PDT
Chair: Yen
Minutes: Francisco

* (Ming-Wei / Dave) Issue [4202](https://github.com/openenclave/openenclave/issues/4202): New verifier plugin (or relying party APIs) for SGX that support specific attestation service
* Dave: Agrees with Ming-Wei to put them all in the same repo, the main OE repo. It's OK to have dependencies on other repos. No need to separate out the repo. You can separate them in different library/directory.
* Francisco: Should not be an issue to keep them in same repo assuming the code for CSP/TEE-specific implementation can keep the same license that already exists in OE.
* (Ming-Wei) Please review implementation on PR [4237](https://github.com/openenclave/openenclave/pull/4237/files)
* It's OK to return unsupported format if they specify an unknown format to *oe_get_background_check_attestation_certificate_v1* API.

### 11 August, 2021 10:00 AM PDT
Chair: Ryan
Minutes: Francisco

* (Ming-Wei) Follow up on PR [4138](https://github.com/openenclave/openenclave/pull/4138): Attestation APIs with flexible claims proposal
* Dave: Relying party APIs never look inside evidence. Would like to split oe_parse_attestation_certificate API to be broken into two: one for passport and one for background check. Is there a situation where someone needs to call both?
* Ming-Wei: Don't want to mix relying party API with the verify API. Should be OK to split into two APIs
* Dave: Why would background check have custom claims buffer?
* Ming-Wei: We don't want to modify the underline verifier APIs. If we put claims into evidence we are modifying them.
* Dave: Would verifier ever need to know contents of custom claims buffer?
* Ming-Wei: They would get a hash. No need to look at actual values, integrity check is OK, no need to have policy on those.
* Dave: If there's a sequence number, then this may not work. Anything verifier needs to operate on needs to be in the evidence buffer.
* Dave: Evidence definition is a set of claims that is part of the stack of the TCB (hardware, firmware, software). OE should try to stick to this industry standard definition.
* Dave: Add a _v1_ to show it's still WIP until we get layered claims.
* Ming-Wei: OK.
* Dave: Do we need a relying party API to parse attestation results?
* Ming-Wei: Yes, could be a separate discussion.
* Ming-Wei: Does attestation result require OID?
* Yen: Use a separate OID for attestation result.
* Dave: Agree.
*
* (Ming-Wei / Dave) Issue [4201](https://github.com/openenclave/openenclave/issues/4201): API for parsing an evidence without the dependency on DCAP client
* Dave: When would a verifier want to extract fields from evidence without verification? (this would be a better title for the issue)
* Yen: Should the API name reflect the intent? Like oe_parse_unverified_evidence clearly indicates the evidence has not yet been verified.
* (Ming-Wei / Dave) Issue [4202](https://github.com/openenclave/openenclave/issues/4202): New verifier plugin (or relying party APIs) for SGX that support specific attestation service
* Dave: Should oe_verify_evidence be only used by verifiers or should a relying party also be able to call this API? It's cleaner to be split, but since there are some people already using it this way, maybe it can stay like this.
* Yen: May need to continue conversation next time.
* Ming-Wei: Perhaps one API for verifiers and another API for relying parties is the better way.
*

Next chair:

### 28 July, 2021 10:00 AM PDT
Chair: Shanwei
Minutes: Yen

* (Shanwei / Yen) Follow up on issue [4105](https://github.com/openenclave/openenclave/issues/4105): API oe_verify_evidence() should return OE_OK for all non-terminal TCB status
* Review [Yen's proposal](https://github.com/openenclave/openenclave/issues/4105#issuecomment-879473833)
* How to avoid CI/CD tests failure on platforms with non-terminal TCB status?
* Coffeelake and Icelake may return differently. This has to be considered in the CI/CD.
* Change comment "Do not allow non-terminal" to "Return success on ..."
* (Ming-Wei) Follow up on PR [4138](https://github.com/openenclave/openenclave/pull/4138): Attestation APIs with flexible claims proposal
* Shanwei: Suggested top-down design to have passport and background-check models.
* Dave: Original API wasn't designed for more general purpose.
* Ming-wei: Changed the title to Attested TLS API
* Ming-wei: in oe_get_attestation_certificate(), attestation_results_buffer is input (something related to the public key input).
* Dave: Prefer option 1 in the oe_parse_attestation_certificate section. More agnostic and we don't have a way to deal with relying party model.
* Ming-wei: oe_parse_attestation_certificate() does not do verification (or call SGX QPL).
* Shanwei: have to document how caller deals with attestation_results_buffer.
* Yen: concerned about backward copatibility. If it's called "certificate", customer may think it can be verified by oe_verify_certificate_* API.
* Dave: Propose making it backward compatible only on the verifier side. The attester side does not have to be compatible (in passport model).
* Shanwei: create different API for getting attestation certificate in passport and background-check models because the input parameter sets are different.
* Dave/Ming-wei: backgroun-check mode - inittime claim is for relying party to verify. OE does not interpret inittime_custom_claims.
* Bo: probably rename inittime_custom_claims to a name with generic purpose since it can be anything.
* Bo: If we take OID approach, use different OIDs for different objects.
* Ming-Wei: API name suggestion welcome.

### 14 July, 2021 10:00 AM PDT
Chair: Yen
Minutes: Ryan

* (Ming-Wei) Issue [4138](https://github.com/openenclave/openenclave/pull/4138): Attestation APIs with flexible claims proposal
* Refer to "Open Enclave Init-time Configuration Interface"
* No breaking change to the underlying API; new run- and init-time custom claims buffers
* (Dave) The new proposal is limited when it comes to evidence authentication
* (Dave) Why would a relying party do the client authentication with a public key but not with a certificate?
* (Shanwei) The cert is self-signed, while the key is certified by evidence
* (Bo) The verifier is supposed to verify the relying party
* (Dave) But it doesn't tell you who the relying party is
* (Shanwei) [Article: Integrating Intel SGX Remote Attestation with Transport Layer Security
](https://arxiv.org/ftp/arxiv/papers/1801/1801.05863.pdf)
* (Eric) draft-voit-rats-attestation-results
* (Bo / Dave) Client credentials are wrapped into a specific claim, which is used in evidence and can be used for authentication
* (Dave) A verifier can choose what to account for. e.g., by allowing the patched ones and disallowing the vulnerable ones
* (Dave) Pass in an evidence buffer (a pre-constructed buffer) in order to make it cleaner
* (Dave) Maybe we can have a more general API instead of separate, parallel APIs for certificates and - if there's a need for them - JWTs and CWTs
* (Yen) If there are more people requesting it, then we can do so
* (Dave) Why does the attester need access to the endorsements buffer?
* (Yen) `endorsements_buffer` and `evidence_buffer` are separate so we need to get both; `endorsements_buffer` is optional though
* (Yen) A verifier or a plugin can reach out to a server to get the corresponding collaterals
* (Dave) `endorsements_buffer` may not be required as a result
* (Yen) Issues with backward compatibilities?
* (Ming-Wei) v2 APIs may need to be revised to fully resolve them
* (Shanwei / Yen) Issue [4105](https://github.com/openenclave/openenclave/issues/4105): API oe_verify_evidence() should return OE_OK for all non-terminal TCB status
* Proposal added to the issue

    typedef enum _oe_policy_type
    {
        /**
         * Allows non-terminal TCB status cases such as
         * - Software hardening needed
         * - Configuration needed
         * - Out of date
         *
         * The policy will be in the form of `uint32_t`
         * - 0: Do not allow non-terminal TCB status cases (default)
         * - 1: Allow non-terminal TCB status cases
         */
        OE_POLICY_ALLOW_NON_TERMINAL_TCB_STATUS
    } oe_policy_type_t;

Next chair: Shanwei

### 30 June, 2021 10:00 AM PDT
Chair: Ryan
Minutes: Yen

* (Shanwei / Yen) Issue [4105](https://github.com/openenclave/openenclave/issues/4105): API oe_verify_evidence() should return OE_OK for all non-terminal TCB status
* Shanwei: low risk error should be treated as success.
* Yen: OE_MAYBE should not be categorized as OE_OK.
* Shanwei: SWHardeningNeed is also non-terminal but is treated as OE_OK today.
* Shanwei: Only invalid and revoked are treated as terminal.
* Yen: What if we introduce a new error for non-terminal cases and probably edit some test cases to treat the new error as success.
* Yen: Customers have been relying on the return value alone. Backward compatibility is important.
* Shanwei: One thing to consider if we introduce another error for non-terminal cases, SWHardeningNeed should return the new error.
* Mark: SWHardeningNeeded treated as success seems to build in a policy to oe_verify_evidence(). This should be a decision for relying party. Without breaking backward compatibilty, API has to change.
* Shanwei: Create a wrapper to bypass compatibility issue.
* Yen: Wrapper is similar to _v2_ API. How about using policy input in oe_verify_evidence() to indicate the caller wants different error for non-terminal cases.
* Mark: It's important to not break current customer. If there's a parameter we can use to extend and change the attestation result for non-terminal cases, we can consider it.
* Dave: Use policy parameter seems OK. CI/CD test should run through all the possible cases including default and specific policies.
* Yen: I will add comment to the issue with draft decision. We can discuss offline.

### 16 June, 2021 10:00 AM PDT
Chair: Shanwei
Minutes: Francisco

Opens: (none)

Agenda:
* (Dave / Yen) Issue [4033](https://github.com/openenclave/openenclave/issues/4033) There is no defined way to represent layered claimsets
* oe_get_evidence = takes a custom claim
* oe_verify_evidence = returns an array of claims. If it's a very simple EAT (EAT supports both JSON or CBOR), then there's no issue because they are a "flat array."
* There is an issue when it is a nested EAT. In SGX there is really only 2, but the format has no upper bound on how many levels of nesting. In addition, each EAT can have an element, and the element itself may be signed by the layer underneath, or, the layer underneath can rely on the parent structure to sign it.
* In order to support TrustZone, which uses DICE, OE needs to support nested claims.
* Dave: Proposed a new struct typedef that is backwards compatible, and can express all of EAT/DICE as far as we know. See comment https://github.com/openenclave/openenclave/issues/4033#issuecomment-862572625 for more details and caveats.
* (Qiucheng) Issue [3885](https://github.com/openenclave/openenclave/issues/3885) Ctest for the attestation failed
* The author of the issue gave a thumbs up. We are interpreting this as a sign that it is OK to close this issue.
* Issue [4086](https://github.com/openenclave/openenclave/issues/4086) Is it possible to extract MRENCLAVE from an invalid/expired quote?
* Dave: On failure we should not only return an error code. We should also return the claim.
* Shanwei: We have moved in that direction in other APIs.
* Dave: This is helpful for logging/debugging.
* Mark: Returning the claims even with an error code may lead to problems if people accidentally ignore the error code and interpret the claim as valid.
* (All) Review other items in the [SIG Attestation](https://github.com/openenclave/openenclave/projects/18) project
* https://github.com/openenclave/openenclave/issues/3988
* How to query whether the Enclave is running in debug mode without triggering remote attestation

### 02 June, 2021 10:00 AM PDT
Chair: Yen
Minutes: Qiucheng

* Issue [4027](https://github.com/openenclave/openenclave/issues/4027): `oegenerate` does not generate enclaves
* `oegenerate` was unfortunately released one day after the last meeting.
* Yen: To correct the mistake, I suggest we rename it before the next release (6/25).
* Dave: Use `oeutil` to combine OE utilities(`oesign`, `oeverify`, `oegenerate`). `oegenerate` can be added first, not to combine all utilities in one shot.
* Yen: Next release in two weeks. Need to determine the naming in this meeting.
* Dave: `oeutil generate-evidence` that can be matched by abbreviation like `oeutil gen` or `oeutil generate`.
* Yen: Generate function will not be available in non-enclave environment.
* Shanwei: Other utilities naming, like `oeutil sign-enclave`.
* Dave: Can cover other utilities in SIG-ARCH meeting.

* Issue [4033](https://github.com/openenclave/openenclave/issues/4033): TCB level, aka version, should be exposed as a claim
* Security versions such as SGX cpusvn and pcesvn should be exposed as claims.
* Dave: oe_verify_evidence is lacking today in not having any defined way to represent layered claimsets.
* Shanwei: Is `TCB status` a string or a number?
* Yen: A enum type.
* Mark: Status like SW configuration / configuration needed does not necessarily fail the attestation.
* Dave: Verify API return claims.
* Dave: What's the right way to return different lists of claimsets. Same claim, like version, can appear several times. Flattern structure or more complicated structure.
* Shanwei: Like json structure.
* Dave: x509.
* Yen: Add `catogory` field in oe_claim_t struct.
* Dave: `catogory` can be evidence, endorsement, attestation result.
* Dave: Multiple layers of verification, application, evidence(claim), firmware, hardware. Each layer could have a `version` field.
* Yen: More generic naming like namespace.
* Dave: Need to have strict order for each layer. So that each layer can be vouched by other layer in sequence.
* Shanwei: The field in json is not ordered. So as claim entry. Need to have way to identify each claim component in the verification chain.
* Yen: Can put them in certain order. But people not have to check the order.
* Yen: `TCB status` is already merged defined in enum.

* Shanwei:
* Tag the issues with attestation tags for discussion.

### 19 May, 2021 10:00 AM PDT
Chair: Ryan
Minutes: Mark

* Dave: issue [4027](https://github.com/openenclave/openenclave/issues/4027): `oegenerate` does not generate enclaves
* e.g., `oetestattest`, `oetestevidence`
* `oetestevidence` sounds better than the other and is less tongue-twisting
* `oegenerate` is supposed to pair with `oeverify`
* Dave: there is a larger issue - do we want a completely seperate executable for each command, or do we want one tool which can perform many attestation commands?
* Ryan: this will be merged with another tool currently called "oecertdump".
* Ryan: agree that a common tool would be better. (there were no objections to this direction).
* Dave: it would be bad to rename the tool in one release and then rename it again in a subsequent release.
* Mark: suggest that we choose a name for the common tool and then later add features to the common tool.
* Dave: that is one option, or we can change the name of the oegenerate tool back to the old name for this release (so that it is the same as the last release), then change it in the next release when tools are combined.
* Mark: suggest "oeutil*" naming convention where the * is the utility function.
* Dave: other precedence include apt ""<command>"". Preference is "oeutil <command>" for example, "oeutil generateevidence" (or something shorter) for this specific function
* openenclave/tests/tools will also need to be updated - will need to change names of test folders.
* Agreed: plan on revert back to "oecert" for the next release unless a new name/command can be agreed upon in the issue discussion.

* Qiucheng: PR [4014](https://github.com/openenclave/openenclave/pull/4014): Map two proposed claims `OE_CLAIM_TCB_STATUS` and `OE_CLAIM_TCB_DATE` to EAT claims.
* One match could be 3.9 security level that characterizes the device/entity ability to defend against attacks. How about name as `OE_CLAIM_SECURITY_LEVEL` and `OE_CLAIM_SECURITY_LEVEL_ISSUED_DATE`?
* Shanwei: question is whether we can map the SGX TCB Status to claims listed in the EAT Security Level Claims (section 3.9 of the document).
* JimB: TCB Date (OE_CLAIM_TCB_DATE) is the date at which the TCB recovery associated with the status was announced. It is associated with a TCB version for the patch issued with the TCB recovery.
* Dave: is this the issue date of the patch? Jim: no, it is the date of the TCB recovery announcment.
* Jim: endorsements carry a TCB status and TCB date. TCB level is a set with a variable number of entries.
* Dave: EAT is a format for the evidence or attestation results, but not for endorsements. A better question is "Can the TCB level map to anything in EAT?" For example, a quote is evidence and a PCK Cert is an endorsement.
* Jim: can pass endorsements with the quote, but it is not required.
* Jim: can encode TCB level into a single 16-byte ordered value
* Dave: can we map the TCB level to a parameter in the main EAT document? Try "Version" in section 3.1.8. Need to find out if Version can support a 16 byte value (it is not detailed in the document, but it is likely either a string or a UUID). The best writeup is in the suit claims document which is for proposed additions to the EAT document.
* Dave: Conclude that TCB Status and TCB Date are claims in endorsements and cannot be mapped to anything in the EAT which is for evidence and attestation results
* Dave: need to make sure that EAT works for SGX - Dave and Ned Smith (Intel)
* Dave: it is best if we can map the TEE agnostic names to terms in RATS
* EAT doc proposed 4 level types for the security level claim. Should we map the claim values (SGX defined TCB status term) to those types as well? Or the claim values can be defined by attester/verifier, in this PR's case, SGX?

Next chair:

### 05 May, 2021 10:00 AM PDT
(Cancelled)

### 21 April, 2021 10:00 AM PDT
Chair: Shanwei
Minutes: Dan

* Followup: issue [3885](https://github.com/openenclave/openenclave/issues/3885#issuecomment-810597371) Ctest for the attestation failed
* How to handle soft error conditions like SGX quote verification code SGX_QL_QV_RESULT_CONFIG_AND_SW_HARDENING_NEEDED, both inside oe_get_evidence() implementation and at application level?
* Discussion:
* Some platforms should be configured to mitigate certain sidechannels. The HW will respond with HW Hardening required, others will respond to the effect of SW config required (e.g. LVI), these are "soft" errors that come out of the QVL. OE will translate these to TCB CONFIG INVALID.
* There's nothing OE can do to fix these conditions, they require admin intervention.
* The issues in the ticket are triggered in ctest.
* Should never get s/w hardening because all code is OE controled.
* Or .. Will always get SW hardening message because it's an indication of the platform as a notification that you need to make sure your tool chain is hardened.
* Thaler proposal 1: Hand up these "soft" errors as CLAIMS to the verifier. In the case of ctest, policy can accomodate these.
* More specifically, oe_verify_evidence() should return these as CLAIMS (probably standard claims)
* Thaler proposal 2: oe SGX tool to print this information.
* Consider also dates and lag between changes in vendor policy and current machine. How to build in policies for OE verification API, e.g., I will allow one week or one SVN version.
* Note that
* SW Hardening needed is not an out of date condition (see above "soft" error)
* HW Config Needed also not date related.
* TCB Out of Date is date related.
* ctest should not fail the test for these conditions because oe_verify_evidence should return OK. Ctest should also look at supplemental claims to verify that the claim was added.
* See also https://datatracker.ietf.org/doc/draft-ietf-rats-eat/
* not all claims are in that doc, a second relevant doc is https://datatracker.ietf.org/doc/draft-birkholz-rats-suit-claims/ which has some that we expect to get folded into the first doc above
* 2nd doc has: "3.1.8. version The Version of a hardware or software component of the Attester.

        * Yen will add an issue for adding new claims and return values and update ctest accordingly.
* Other TODO items in the [SIG-attestation project](https://github.com/openenclave/openenclave/projects/18) (all opened by Yen)
    * Issue cards / board updated.



### 7 April, 2021 10:00 AM PDT
Chair: Yen Lee
Minutes: Dan

* Issue [3937](https://github.com/openenclave/openenclave/issues/3937) Test cases for SGX AESM attestation evidence generation and QVL evidence verification
    * Add test coverage for 
        * SGX in-proc or AESM out-of-proc quote generation
        * SGX DCAP QVL quote verification
        * How to create Linux kernel 5.11 environment? Install the latest PSW (2.13)?
    * Discussion...
        * Issue introduced
        * Install steps... no driver install required so long as you are using 5.11 kernel...
            * however CI environment targeted at Ubuntu 20.04 (probably 5.4 kernel by default)
            * 1.41 driver should create the env var (d/l from 01.org)
                * Yen: [Download](https://download.01.org/intel-sgx/latest/linux-latest/distro/ubuntu18.04-server/)
            * 1.41 driver will enforce provisioning key access (as alternative to using the 5.11 kernel)

* Issue [3885](https://github.com/openenclave/openenclave/issues/3885#issuecomment-810597371) Ctest for the attestation failed
    * SGX quote verification returns SGX_QL_QV_RESULT_CONFIG_AND_SW_HARDENING_NEEDED. How to resolve?
    * discussion...
        * user specio resolved their own issue which may be unrelated to the original issue submitter's issue (ChrisVoile)
        * SMT, Internal Gfx, and Overclocking related to this issue...
        * ... probably some difficulty in correlating Advisory IDs and the tcbDate field. Best practice is to search for SAs related to the given date.
        * Decision to wait for ~1 week to see if ChrisVoile will add further dialog to issue.

### 24 March, 2021 10:00 AM PDT
Chair: Ryan
Minutes: Simon

* Issue [3896](https://github.com/openenclave/openenclave/issues/3896) Remove @experimental tag from attestation APIs
    * Yen: Only comment is from Dave regarding `oe_policy_t`
    * Dave: For context, the @experimental tag was added because of uncertainty about stability of the API surface until a second TEE implementation was added. We can change the requirement for removing the tag, by comparing the API against the proposed API requirements instead, and Dave found that there were no issues except for the `oe_verify_evidence` API in its use of `oe_policy_t`. That seems to be the only open issue.
    * Options:
        * Wait until a second TEE implementation to remove
        * Remove from all APIs and address issues as they come up
        * Remove from all other APIs and keep `oe_verify_evidence` as experimental.
    * Shanwei: What's the issue with just keeping them as experimental
    * Yen: The feedback is that having them as experimental leaves users with no confidence that they are ready for use.
    * Yen: We can also wait until we have plug-in samples in and wait for the feedback to have better confidence. The plan for the plug-in samples are at least a month away though.
    * Dave: agree that the samples at least would give better confidence on the subset of the plug-in APIs.
    * Shanwei: Agree that having the samples would increase confidence, but also depends on the pressure from the community wanting to switch from the legacy attestation APIs to the extensible ones.
    * Dave: If the wait is only one month then we could just wait.
    * Yen: Not necessarily only a month, need to resource the work. 
    * Dave: Regarding the `oe_policy_t` issue, it contains embedded pointers whch can be problematic with lifetime management when used with the suggested `oe_initialize_evidence_datetime_policy`
    * Shanwei: What is the intended use for this policy?
    * Dave: It meets all the usage requirements specified by the API requirements, such as allowing the app to pass policy down into the plugin implementation and surfacing the claims back up (standard & custom), the issue is with the design of the API.
    * Shanwei: A failed policy would return failure correct?
    * Dave: Yes, and that's a feature, not an issue. The syntax should support common policy types like the datetime in a typesafe way. We should update that syntax either before we remove the experimental tag or as a v2 update after.
    * Shanwei: Does this affect the attester side?
    * Dave: No, the equivalent would be using optional parameters on that side. 
    * Shanwei: documentation to clarify intended usage of the policy input would also be useful.
    * Yen: I would prefer to keep everything as experimental and remove the tag for everything at the same time. We should address the policy syntax issue and then remove the experimental tag.
    * Dave: I agree
    * Yen: We can work offline to resolve that then.
* (Yen) Propose changing SIG Attestation to taking place once every two weeks.
    * Ryan & Dave both agree
    * Dave: we've been cancelling every other week anyway.
    * Yen: I'll take an action item to update the meeting invitation.
* Reviewed [SIG-Attestation project](https://github.com/openenclave/openenclave/projects/18) tasks
    * No questions on current progress.


### 17 March, 2021 10:00 AM PDT
Chair: Shanwei
Minutes: Yen

* PR [3871](https://github.com/openenclave/openenclave/pull/3871): Add oe_verify_attestation_certificate_with_evidence_v2()
    * Discuss questions raised in PR review comments.
    * Why is a callback needed?
    * Dave/Shanwei/Yen/Ryan all agree to remove the callback
    * V1 will be deprecated but the API will not change.

* PR [3890](https://github.com/openenclave/openenclave/pull/3890): Add test for verifying new fields in sgx_report_body_t struct
    * Triaged. Assigned to Yen. Currently in progress.

* Triaged all attestation TODO items.

Next chair: Ryan

### 10 March, 2021 10:00 AM PST
Chair: Yen
Minutes: Dan

* ACTION follow-up (see 3/3)
    * Not optional dependency right now. Will be made optional for a future release (near term).
* SGX in-kernel transition timeline
    * When will OE customers be impacted
        * Whenever a distro picks up that kernel version (5.11)
    * Actions for adoption
        * Will announce at [e-mail]
            * Upstream kernel driver changes behavior compared to earlier DCAP driver.
            * Earlier DCAP driver allows an intel signed enclave to load;  
            * Upstream driver instead checks that the linux user is in a certain user group.
            * Later versions of DCAP driver (e.g. v1.41) align with upstream driver and check the user group membership. 
            * When upstreamed kernel version becomes available, it will supplant the DCAP driver.
            * Provide resolution paths to users
                * Give user permission
                * Have application go out of proc to aesm (which is permissioned) by setting SGX_AESM_ADDR.
        * Will contact first party customers
* Publish oecert tool (Yen) - PR [2898](https://github.com/openenclave/openenclave/issues/2898)
    * For users to generate evidence or certificate in a file
    * For log collection and issue diagnosis
    * Discussion:
        * Need two binaries. One for host and one for enclave. 
        * Previously only available as a test tool. Move to bin/.
        * Add documentation for how to use tool.
        * Tool is useful to test platform and try verification. It generates an attestation of a dummy enclave.

### 3 March, 2021 10:00 AM PST
Chair: Ryan
Minutes: Dan

* Regarding (Ryan) PR [3806](https://github.com/openenclave/openenclave/pull/3806): Set out-of-process call path as default on Linux ....
    * (Yen / Ryan) Since two environment variables is error-prone, we suggest taking the out-of-proc path by default unless `quote-ex` is uninstalled and `SGX_AESM_ADDR` is unset.
 
| Windows    | Quote-Ex | No Quote-Ex | sgx_prv |
| ---------- | -------- | ----------- | --------|
| AESM Set   | Out proc | Error       | N/A     |
| AESM Unset | In proc  | In proc     | N/A     |

| Linux      | Quote-Ex | No Quote-Ex | sgx_prv |
| ---------- | -------- | ----------- | ------- |
| AESM Set   | Out proc | Error       | N/A     |
| AESM Unset | Out proc | In proc     | Required|

* Discussion... What is the scenario / problem 
    * What is the desired behavior when the SGX_AESM_ADDR environment variable is not set?
        * Should fail. 
        * Two resolutions:
            1. User/operator should set the env variable.
            2. Add the user running the process to the sgx_prv group:
		`$ sudo usermod -a -G sgx_prv <user name>`
            * See design [doc](https://github.com/openenclave/openenclave/blob/master/docs/DesignDocs/SGX_QuoteEx_Integration.md#background-the-sgx-dcap-and-quote-ex-libraries).
        
* Consensus Recommendation: Document this behavior rather than trying to automate workarounds in the SDK.
    * Document correct way to unset/mark false SGX_AESM_ADDR
    * see https://man7.org/linux/man-pages/man3/unsetenv.3.html

* ACTION: Shanwei/Mark - ensure that libsgx-dcap-ql has optional dependency on libsgx-quote-ex.

* How to within a unit test determine whether executing as in-proc / out-proc? Will investigate offline.

### 24 February, 2021 10:00 AM PST
Chair: Shanwei
Minutes: Yen

* (Dave / Ryan) Issue [3820](https://github.com/openenclave/openenclave/issues/3820) oe_get_attestation_certificate_with_evidence is insufficient for security 
    * Proposal to add optional endorsements and polices parameters to `oe_verify_attestation_certificate_with_evidence()`
    * https://github.com/openenclave/openenclave/pull/3845
    * Similar pattern should be address in `oe_verify_attestation_certificate_with_evidence()`. Suggest open another issue for this.
    * Dave/Shanwei both agree.
    * Ryan will open the issue for it.
* (Yen) How to pass nonce from attesters to relying parties
    * Note: as described in the Design Notes doc [Semantics of Custom Claims and Optional Parameters](https://github.com/openenclave/openenclave/blob/master/docs/DesignDocs/NotesOnAttestationAPI.md#semantics-of-custom-claims-and-optional-parameters) section, custom claims can be used. 
    * Relying party does not verify nonce.
    * Attester has not direct communication with relying party.
    * Shanwei: is it a valid usage if relying party needs to verify freshness.
    * Refer to RATS documentation.
    * Per current design, custom claim is the carrier for challenge to be passed from and checked by relying party.
* (Ryan) PR [3806](https://github.com/openenclave/openenclave/pull/3806): Set out-of-process call path as default on Linux
    * Suggested renaming of `SGX_USE_IN_PROCESS_QUOTING`
    * Ryan is still working on the PR. Renaming is to be done.
    * Yen: the variable only switch between using DCAP QL or Quote-Ex.

Next chair: Ryan

### 17 February, 2021 10:00 AM PST
(Cancelled)

### 10 February, 2021 10:00 AM PST
Chair: Yen
Minutes: Simon

* (Dave) oe_get_attestation_certificate_with_evidence is insufficient for security 
    * https://github.com/openenclave/openenclave/issues/3820
    * Core issue is that `oe_get_attestation_certificate_with_evidence()` lacks optional parameters buffer as an input param, which is used for core scenarios like including a challenge/nonce in the evidence. 
    * Shanwei: is this a security or functionality issue?
    * Dave: Can't determine liveness wihout challenge info.
    * Alan: And this allows for replay attacks (so is also a security issue)
    * Yen: This version was created when there was no use case for it
    * Dave: There was a use case that did not require replay protection? It seems unlikely, but there could be other mechanisms in that channel that provided the replay protection, for example the establishment of the TLS channel itself provides it.
    * Bo: Is this missing field an issue if the method is used to wrap the evidence in a certificate? Doesn't the certificate provide the liveness requirement?
    * Simon: No, the certificate doesn't provide a liveness requirement because it is always a self-signed cert with no PKI chain and trust in the cert itself is derived from trust in the evidence.
    * Yen: Yes, this is a gap based on the difference with the existing `oe_get_evidence()` API, and it is easy enough to add to this API.
    * Bo: there could still be other methods to establish freshenss.
    * Dave: yes, if there are, I would like to see a writeup for it. There are also uses for the optional parameters buffer outside of its use for the challenge.
    * Bo: the enclave is never supposed to give out the signing key for the certificate, so the certificate with the evidence should not be replayable (the certificate should not be cached outside the enclave anyway).
    * Dave: do we need both the custom claims and the optional parameters buffer? 
    * Shanwei: That's the `public_key` parameter as the custom claims passed to `oe_get_evidence()` maybe that should be renamed since it could be something more.
    * Yen: Yes, I think this method should just be a passthrough of the parameters to `oe_get_evidence()`

### 3 February, 2021 10:00 AM PST
(Cancelled)

### 27 January, 2021 10:00 AM PST
Chair: Ryan
Minutes: Yen

* (Yen, Ryan) Out-of-process call path issue for Windows: while `quote-ex` could be located but could not be initialized. What binary/package do we need in order to make it work on Windows (in this case, a Windows Server machine)?
    * See PR [3806](https://github.com/openenclave/openenclave/issues/3806) for more details.
        * Besides quote-ex, what other libraries are needed? (AESM plugins?)
            * Mark will take action item to list all libraries needed for AESM
                * Mark: I have listed the dependencies for libsgx-quote-ex as a comment in the pull request.
        * For Windows, how are quote-ex and other AESM libraries installed?
            * Mark: Server 2019 base binary package should install the proper binaries.
            * Francisco/Mark: come in 2 packages
            * Look for *sgx*.dll. Some do not have sgx prefix.
            * Instructions from Francisco
                * First install the latest ACPI device drivers from https://www.catalog.update.microsoft.com/Search.aspx?q=acpi%5CINT0E0C
                    * http://download.windowsupdate.com/d/msdownload/update/driver/drvs/2020/11/a59c585b-e021-4d6f-adc0-011ff165e1d6_301ad2d530bcd2e0742f21614a572920b2e30c72.cab
                        * If you want to opt-in to for SGX DCAP attestation, add this to the registry
                    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\sgx_lc_msr\Parameters]
"SGX_Launch_Config_Optin"=dword:00000001
                * Then install the latest PSW runtime from https://www.catalog.update.microsoft.com/Search.aspx?q=VEN_INT%26DEV_0E0C
                    * http://download.windowsupdate.com/d/msdownload/update/driver/drvs/2020/12/51a00f00-670e-4b2d-b836-56a2221c0d02_e2556cc079d26ded138c392fffea767926121e8b.cab
                * Then install the latest DCAP libraries https://www.catalog.update.microsoft.com/Search.aspx?q=SWC%5CVEN_INT%26DEV_0E0C_DCAP
                    * http://download.windowsupdate.com/c/msdownload/update/driver/drvs/2020/12/208782ba-3250-47c1-9cc0-c2b3223b0661_830aacca9a6ce01b42bf39a78789554505b79fb6.cab
            * The steps above can also be done via Device Manager by:
                * Right-Click on System Devices -> "SGX Device" (clean OS) or "Intel(R) Software Guard Extensions..." and updating the ACPI device drivers
                * Right-Click on Software Components -> "Intel(R) Software Guard Extensions..."" and updating drivers for these devices.
            * Mark: Installation document describes the setting environment variables.
        * Possible impact of using this new version of OE SDK on an old (4.15) kernel.
            * OE SDK has code to decide to go out-of-proc or in-proc.
            * OE does not call QL (quote library) for quote generation. It loads QuoteEx, if exists, and check if AESM environment variable is set.
            * Old kernel will remain in-proc unless quote-ex and all necessary libraries are installed.

* Next chair: Yen

### 20 January, 2021 10:00 AM PST
Chair: Shanwei
Minutes: Yen

* (Dave) Review of issue [3804](https://github.com/openenclave/openenclave/issues/3804): Could host-verify process also be used from kernel-mode?
    * Mark: In theory this could work. Kernel can set up privilege process to verify a quote.
    * Simon: Host verify can run on non-SGX machine.
    * Dave: Trust enclave rather than a trusted module.
    * Jim: Treat trusted module as relying party.
    * Dave: Enclave communicates with kernel running host verifying code.
    * Mark/Jim: Same device but different VMs can detect they are in the same platform.
    * Jim: provision something in the quote so it can be detected that's from the same platform.
    * Dave: Any user mode proces can be trusted by kernel - signed by MS, or data center.
    * Cedric: Kernel can launch a user-mode code that creates enclave.
    * Simon/Dave will add comments to the issue.
    
* (Cedric) Review of PR [3652](https://github.com/openenclave/openenclave/pull/3652): Add Sealing APIs
    * Simon: Objection - when you are asked to hold a blob (key info) which may be compromised without you knowing it. Key info does not have to be exposed publicly.
    * Simon: Code maintainer has to be convinced that it's an acceptable design to maintain.
    * Cedric: Collection of the params are defined in struct defined by TEE. Design should be stable unless cryptographic is changed dramatically inside. I think hardware similar definition is easier for developers familiar to the hardware (e.g. SGX). Getting error at build time is better than at runtime.
    * Simon: OE API definition wants to be TEE agnostic.
    * Dave: OK to pass in a void blob with SGX type for the blob.
    * Dave and Simon object the PR. Cedric will update the PR and make decision in a week.

* Ryan will chair next week.

### 13 January, 2021 10:00 AM PST
Meeting cancelled

### 6 January, 2021 10:00 AM PST
Chair: Ryan
Minutes: Yen

* (Yen) Goal: Make OE SDK's quote generation use out-of-process call path (i.e., through AESM daemon) as the default setup
    * Seek advice from Bo, Mark and Shanwei.
    * PDF link?
    * Simon: Can we provide container the contains AESM with the ev setting?
    * Mark: This is documented in SGX spec.
    * Yen: Is there plan to make AESM out-of-proc default?
    * Mark: No plan on that.
    * Shanwei: Can we make code set the environment variable?
    * Yen: I think that's too aggressive.
    * Dave: Can ql check to see if AESM is isntalled and pick the best approach?
    * Shanwei: OE check ev setting and calls quote-ex directly (bypassing SGX QL). It can be fixed in OE SDK by making AESM out-of-proc default.
    * For information about DCAP Quote Library Enhancements (which was proposed March 2019), please ask Mark because it is internal.
* [Dave] CCC Attestation "SIG" (i.e., proposed SIG)
    * Information sharing between CCC Attestation SIG & OE SIG-Attestation
    * Old link (should change to a new link to allow comments, I hope) https://docs.google.com/document/d/1a6Swoki2Vb3MAFhC_msyRdZq1JMFk_t9ecvQdZB-r-4/edit#

* Next chair: Shanwei

### Meeting Minutes in 2020

* https://hackmd.io/dcsZ1Z5vQW-lkB3z-zEULA