# RATS @ IETF 112

## RATS Agenda November 8th Monday Session I
Room 7, RATS Session 1, 1200 UTC

Note takers: Thomas Fossati (TF) and Michael Richardson (MCR)

Time zone: UTC

### 12:00 - 12:05	Agenda Bash & Logistics (5 min)
    Nancy Cam-Winget (NCW), Kathleen Moriarty (KM), Ned Smith (NS)
Meeting opened by Ned.


### 12:05	- 12:15 RATS Architecture and next steps (10 min)
    Michael Richardson (MCR)

    MCR: no changes since Apr.  Waiting for shepherd write-up and then go to IESG.  Design team has not met until Apr. Discussion of what it is we are waiting for, what is going on.  And what is going on.

    Kathleen Moriarty- Called for IPR, received message that we need to wait until December. Have IPR claim from Intel, WG needs to decide what to do based on that claim. Person sent claim individually, not to the group. Up to the individual to send it out more broadly.

    MCR- would have been great to know we had to wait until December, even if we didn't know what. Are there other area reviews we need to wait for?

    KM- Area reviews start after IETF LC (last call).

    Roman - WG needs to decide what to do with IPR claims. Need positive confirmation to proceed based on those claims.

    MCR- are all claims now submitted, or are we waiting until December?

    Roman- there might be others coming in

    Ned- status is that the US patent office will not make it public until December.

    MCR - I understand now, so it will show up on the Internet in December.

    Henk - WG should agree how to move forward independently of the IPR claims content.  How are we approaching this?

    MCR- If you can form an opinion without reading the patent, you can express a view. Could be that all that matters are the terms. Can't form a conclusion until those who will read the patent can do so in December.

    Henk - personal opinion is I am not sure how that would apply, and that wouldn't be a problem.

    MCR- it (IP disclosure) is concerned with layered attestation.

    Dave Thaler- I think we should proceed. I have a hypothesis about what the patents might apply to. But, this is an arch document, not one that someone could claim compliance to. Nothing is mandatory. All of RATS fits under this category. Very unlikely any patent could cover the entire document.

    Roman- Request for comments on the mailing list, on comfort or discomfort level of proceeding in light of the patent claims and we will adjudicate like we'd do on last call.

    Hannes- We made a lot of investment in attestation technology. Patent claims scare off developers, unfortunately. Timing and procedural aspects of this don't look good: this happened too late in the process. Perhaps we should consider not publishing the document at all, protect the technology space.

    Ned- out of time with this topic now.  We can bring it up again on Friday when there's open mic time.

    Eric Voit- suggests that patents are not a problem for open source if the terms are RF.

### 12:15 - 12:20 Attestation Event Stream Subscription (5 min)
    Eric Voit (EV)

    EV: short update.  Draft has been adopted.  It has a dependency on the CHARRA draft which is now in AD review.  It has dependencies through a number of other drafts.  The idea is to use RPC to subscribe to router and get notifications on PCR (Platform Configuration Register) updates. Encourage to read the details (e.g., filtering, configuring the notification stream, etc.).  Plans: YANG model dependencies need to be reflected in here.  We'll be monitoring that and adding anything else that is needed.

(no time for questions, none queued)

### 12:20 - 12:40 A CBOR Tag for Unprotected CWT Claims Sets (10 min)
    Carsten Bormann (CB)

    CB: Sometimes it's possible to do the same as CWT (COSE Web Token) using another kind of secure channel.  Therefore, you could use an unprotected claim set. It's a good idea to add a tag in case it's useful.  Why do we need a document?  
    1. adds clarity about the use of the claims set "predicate".  
    2. security considerations are quite specific in the RATS context - in particular, what RATS considers a secure channel.   

    next steps - add CDDL for CCS?  The alternative is to put it into another document (++overhead).  One more round of edits from reviewers, then go to WGLC (working group last call).

    HB: okay with scoping.  People got used to idea that UCCS (Unprotected CWT Claims Sets) are context-specific, and RATS is the first iteration of this.  Get the backlog of comments done. Thomas (Fossati?) is aware of that.  They will get done in the next weeks and that would be the version that goes for WGLC.

    LL: There are a lot more comments in the next presentation and coming soon.


### 12:40 - 12:55 The Entity Attestation Token (EAT) r11 changes (15 min)
    Laurence Lundblade (LL)

    LL: version revision -11.  I personally think the document is ready for LC.  Some text can be removed now that there is more mature RATS architecture.  LL goes through the change log from -10:
    * Terminology is consistent with RATS-ARCH as well as CWT (CBOR Web Token) & JWT (JSON Web Token)
    * Add alternatives to CoSWID for simple claims about SW name and version
    * Describe attestation results of comparing SW measurement against reference values: added a new "SW results" claim
    * OEMID claim: clarify it's only for HW
    * Lots of examples added, including CoSWID (Concise Software ID), DEB (Detached EAT Bundles), measurements.  The examples in CBOR DIAG format are automatically checked against the EAT CDDL (Concise Data Definition Language) as well as the SUIT (Software Update for IoT) and CoSWID CDDL.
    * Define JSON equivalent of UCCS, called UJCS (Unprotected JWT Claims Sets) -- what Carsten said in the presentation just before advising that we shouldn't do this.
    * Clarification about nesting of EAT
    * Added a way to sign detached claims-set: Detached EAT Bundles (DEB)

### 12:45 - 13:15 EAT Topics: CDDL for Claims-Sets & Nesting CWT in JWT (30 min)
    Laurence Lundblade (LL)

    LL: Take a claims-set in an EAT and detach it from the EAT, and leave its trace via a digest. This allows you to build a smaller attester in HW that instead of signing the whole claims-set it is given a digest of it (via a trusted channel, by a trusted entity) which it signs, and the claims-set is attached separately.

    DT: I think the document is ready when it also meets the TEEP requirements (the 5 claims that are not TEEP specific).   SW version is now in, but there are 4 still missing.  Do you plan adding those?

    LL: I had some comments sent via email but I don't recall the details now.

    HB: Align with supply chain requirements as well.  We should join forces and design something that works generally.

    Note: There was a request to Dave Thaler to file TEEP things as issues to EAT github.

    LL: CDDL can do both JSON and CBOR (in theory).  EAT should be in both formats and there is consensus on that.

    CB: What other documents are needed? CWT and JWT are different standards. There are aspects in CWT that are CWT-specific.  In general, because they are not the same thing, it is not always possible to achieve parity.

    LL: Looking for a solution that aligns with what we agreed to do in EAT (i.e., support for both JWT and CWT). I'd like to work to achieve that goal.  I'll continue working on this and see what comes out of that.

    LL: Presented CDDL for Claims-Set that aims to support both JSON and CBOR. This shows how to use CDDL sockets to extend the EAT claims-set.

    CB: When designing new claims that support both worlds is a good thing to have a single CDDL.  However, I am not sure we can retroactively apply this to things that are already out there.

    LL: One compatibility issue at the moment is the fact that JSON does not have a native `bstr` type.  Need convention for mapping CBOR `bstr` and JSON `string`.  Another is that there is no explicit tagging in JSON.

    Note: 'bstr' refers to a binary encoding. For example base64 encoding allows a binary string to be represented as text.

    LL: UJCS is in the EAT document, but doesn't need to stay there.  Why is UJCS important: JSON is very popular, in particular in B2B, which takes a good chunk of the RATS conceptual messages (e.g., on the RP-Verifier leg).  JWT has `alg: none` which is kind of equivalent to UCCS, but it's slightly awkward / non-uniform.  Seems like "simple" addition which brings value.

    LL: Mixed bags are also a possibility (JSON claims-set inside CBOR claims-set), e.g., in composite devices to support creation and verification of nested composite evidence.

    CB: Sent a couple comments to jabber.  I think what you're doing here requires semantics and not just syntax to carry these things around.  What do the claims in the nested thing have to do with the claims in the main EAT.  It'd be nice to understand better the relation and interactions between the two -- "feature interaction" as we used to call it back then.  This needs significant analysis.

    LL: Let's separate syntax and semantics.  The semantic issues have been there since day one with submods.  That is settled issue for me.  The issue for me is purely syntactical.

    HB: We should do some divide and conquer here.   Echoing Carsten's semantic concerns.  We could cut this out and solve i in another doc, otherwise this would push publication of EAT forwards at a time when we need EAT to be published.

    MCR: I don't think we should try to solve nested attestations in the base EAT document, at least if it means the document is at all delayed.

    LL: Some of the claims (e.g., manifest) already allow you to plug in a different format in an EAT.

    HB: But in that case it's just a value which doesn't need to be interpreted.

    LL: I'd like to hear what are the issues that are that are so difficult: it'd be helpful if you (Carsten, Henk) could summarize the challenges in an email to the list.

### 13:15 - 13:30 EAT Open Issues (5 min)
    Giri Mandyam (GM)

    GM: goes through the slides
    * Only one issue currently that is LC blocking.
    * Recommend to go to LC immediately.

    Specific points:

    * issue 15: "SHOULD/MUST consistency" -- potentially LC-blocking, but tempted to close this with no action.  assuming it will pop up in reviews.
    * issue 131: IANA registers filling (not LC blocking)
    * issue 135: submods relation to target environments (recommends not addressing it before LC, similar to issue 15)(not LC blocking)

### 13:30 - 13:40 WGLC for EAT (10 min)
    RATS chairs

    DT: TEEP question... a profile is not what TEEP wants.  TEEP already has a profile for other things...
    1. Use a separate document that adds non-profile specific things to EAT,
    2. If any comments made after WGLC, may result in additional rounds of review. Don't like having to do multiple rounds of WGLC.
    3.  Non-controversial stuff could just be added now.

    If we could do revision -12, add in four little sections (if non-controversial). Preference to do it all in one WGLC.

    HB: Do not see an easy solution to resolving things in a single blob.  Let's get the CBOR/CWT stuff out in a document now, but include some sockets for the next document and do it in parallel.   Resolving it all at once makes a better document, but that probably won't be done until the end of next year.

    GM: re: CBOR/CWT. Would it be possible to actually take EAT to RFC, but have a follow-on document that builds off of it?

    HB: Exactly. EAT is the basis, and we can build other things on top of it.

    NS: Can revision -12 be published between now and Friday? This would allow us to continue LC discussion then.

    KM: Would Henk's ask (CBOR-only document) be possible in -12?

    LL: Not by friday, and not even sure there is consensus on that.

    HB: Clarifying that my ask was Dave's request about the TEEP claims.

    DT: Keep JSON because it's an important use case and it's not worth major changing to the document that may be destabilize the document (as I hear from Laurence).

    HB: Choose between delaying and understanding JWT/CWT relationship (semantic dissconect) or cater to the immediate need from TEEP and GlobalPlatform now.

    Nancy: Calling LC on -12 would accelerate the discussion.

    Note: There was significant discussion among many about whether the document should close now, or continue.

    Nancy: Request authors make rev -12 available and then ask the group what is missing before LC can be declared.

    LL(from chat): most important decision points:
    1. CBOR/JSON & yes/no for nesting concept in the current I-D

    MCR(from chat): dual orientation will attract more review work and will make it harder for implementers to sort it out.  Nesting is important (to those that need it), such that it deserves its own document.

### 13:40 - 13:50 Attestation Results for Secure Interactions (10 min)
    Eric Voit (EV)

    EV: attestation-results draft. the draft has been split in two:
    * part 1: info elements for attestation results generated by the Verifier.
    * part 2: interaction options (e.g., BG check, AR augmented evidence).
    As a result of discussion at IETF 111, there are two implementations.  We aim for requesting adoption.

    EV: Reasons for having standardized attestation results:
    * help RPs to make sense of what the verifier says (simplify coding the policy for assessing attestation results).
    * homogenize different formats from attesters onto pre-canned semantics.

    EV: It goes through the different IEs and proposed encoding (part 1 of the draft). Also, the work done to map ARs to existing HW sources (e.g., TZ (Arm Trust Zone), SGX (Intel Software Guard Extensions)).

    EV: Explained ways to put together a complete protocol based on the IEs, including topology and freshness considerations.

    EV: This is where we are, questions?

    GM: I read through trustworthy claims several times, although claim values are defined, the criteria are not clear.  Interoperability seems difficult in that context.  ... an attestation is provided in the form of a token... firmware is at version X (not the tip). One verify might lower the trust because it is not at the tip, while another verifier might know that the TIP does not affect trustworthiness.

    EV: It's up to the Verifier defining the policy rules for evidence assessment.

### 13:50 - 13:55 Trusted Path Routing (5 min)
    Eric Voit (EV)

    EV: An instance of the attestation-results draft that solves the problem of accepting routers to the mesh based on their state.

    EV: The only thing changed from latest version is we got it up-to-date with the attestation-results draft.  we are not going to call for adoption until the fate of attestation-results is clear.

### 13:55 - 14:00 Scalable Remote Attestation for Systems, Containers, and Applications (5 min)
    Kathleen Moriarty (KM)

    KM: Goal is to simplifying posture assessment => group collected evidence, label it and send the whole bundle to a remote repository.

    KM: The draft establishes a registry for naming and defining semantics for the sets.

    KM: Please read the draft, it's short and simple!


## RATS Agenda November 12th Friday Session II
Room 7, RATS Session 2

Time zone: UTC, 1 hr

Note takers: TBD

### 14:30	- 14:35 Agenda Bash & Logistics (5 min)
    RATS chairs

### 14:35 - 14:50 Overlap between Attestation Results, EAT and Attestation Sets (15 min)
    Eric Voit (EV), Laurence Lundblade (LL), Kathleen Moriarty (KM)

### 14:50 - 14:55 Direct Anonymous Attestation for RATS Architecture (5 min)
    Henk Birkholz (HB)

### 14:55 - 15:15 Concise Reference Integrity Manifest (20 min)
    Henk Birkholz (HB), Thomas Fossati (TF)

### 15:15 - 15:30 Open Mic (15 min)
    RATS Chairs