# TEEP Monday March 27 15:30-17:00 JST, Session III   {#teep-monday-march-27-1530-1700-jst-session-iii}

Chairs: Nancy Cam-Winget, Tiru Reddy

Notetakers:  
 Kohei Isobe, Haiguang Wang

### Agenda Bash & Logistics - Chairs (5min)   {#agenda-bash--logistics---chairs-5min}

### Hackathon Report – Akira Tsukamoto (15 min)   {#hackathon-report--akira-tsukamoto-15-min}

*   Clarification of the CNF only containing hash value of TEEP agent
*   Compromised TEEP agent: TEEP Broker running on SGX should be
    protected by SGX. No action fom the TEEP Agent as that is not the
    one compromised which is the consideration in the main draft.
*   Clarification of token and challenge TEEP message. No changes
    required in the draft.
*   CDDL and decision to use CBOR required updates to the Makefile in
    the implementation
*   No new issues from this hackathon.

### TEEP HTTP Transport – Dave Thaler (10 min)   {#teep-http-transport--dave-thaler-10-min}

•
Draft: https://datatracker.ietf.org/doc/html/draft-ietf-teep-otrp-over-http

*   Expect to have draft version 15 to cover comments to address IESG
    comments
*   Comments from INT AD (Erik Kline) to address errors around timeout
    considerations.
*   All responses have been posted to the ADs all who have approved
*   Stean Santesson (Secdir review) on normative vs. use of "strongly"
    now reviewed
*   Sec AD: missing "message buffer" usage now clarified. Also URI
    guidance and now references RFC 3986
*   Transport AD (Zaheduzzaman Sarker) commnts addressed from
    introduction (using normative language)
*   TSV AD: POST messages without freshness are unreached. Adding
    Cache-Control header MUST NOT be used.
*   ART AD (Francesca Palombini): requiring clarifications and
    referencnes to BCP195 and RFC9205
*   ART AD: re-echos similar comments from other AD
*   RTG AD (John Scudder) claificaion on client initiation
*   Will publish v15 unless there's any other comments

### TEEP Protocol and transport drafts – Dave Thaler (40 minutes)   {#teep-protocol-and-transport-drafts--dave-thaler-40-minutes}

• Draft: https://datatracker.ietf.org/doc/draft-ietf-teep-protocol/ •
Issues: https://github.com/ietf-teep/teep-protocol/issues

*   Issue 297: Error return for QueryResponse, added update message for
    symmerty with QueryResponse.
*   Issue 310: threat of compromised agent trying to use Attestation
    results from a healthy agent. Mitigation is to require a "cnf" claim
    as defined in S3.1 of rFC 8747
*   Updated security consideration to ensure mitigation on the attack.
*   Issue 281: EAT profile didnd't have any mandatory claims. Update now
    includes required claims
*   Issue 289: relationship of TEEP to AR4si; informative reference with
    inclusion of 3 cases that are applicable (line between the TAM and
    verifier). Category 1: asks verifier to give both ar4si and teep
    profile; category 2: can only give 1 without nonce, send evidence in
    2 formats, category 3: can only ask one per evidence have TEEP agent
    talk directly to verifier to get ar4si
*   Issue 285: update TEEP EAT profile : adding sw-name claim and
    manifests cialm to convey software information
*   Issue 286: summary of crypto algorithm use cases. Clarifications on
    how to deal with sensitive information in EAT and SUIT reports. To
    ensure AEAD algorithms were used
*   Add EAT/SUIT cipher negotiation supported-eat-suit-ciphersuites in
    QueryRequest : as like supported-teep-cipher-suites. Added new field
    covers both EAT and SUIT encryption. Should we split?
*   Current draft may need a change as MTI document to be consistant
    with SUIT draft.
*   WGLC on next step? Dependency of HPKE, EAT, SUIT.

### Firmware Encryption - Hannes Tschofenig and Russ Housley (20 min)   {#firmware-encryption---hannes-tschofenig-and-russ-housley-20-min}

*   Major change made on the HPKE key distribution.
*   Hannes: not sure if there's a way to remove the normative dependency
    but will have to review
*   Dave Thaler: believes the TEEP document can make it an informative
    reference (but SUIT manifest and others do need to stay normative)
*   Hannes: prefers that as the trust domains may fall into the same
    categorization
*   Based on SUIT meeting outcome, can make the chanage to make FW
    encryption informative, but not sure can shift the others as they
    are required (e.g. normative)

AOB

### cnf Implementation   {#cnf-implementation}

*   Hannes asked the details of cnf implementation in this hackathon.
*   Kohei shared Ken's and his implementation. He couldn't find the
    concreate caluculate way of public key's hash in COSE compared with
    JWK. He'll post more details in TEEP mailing list.
*   Akira Tsukamoto: the hash of public key in CNF is already on Github
*   Dave: There is some concern on the KID value and Dave trying to
    anser the question.
*   An issue need to be raised to address the cddl file updates.