RATS at IETF 116 27 March 9:30 Note Takers: Pieter Kasselman, Rich Salz Attendees: 52 (online count) ## Agenda Bash & Logistics {#agenda-bash--logistics} (5 min) WG Chairs - Nancy Cam-Winget, Kathleen Moriarty, Ned Smith David Thaler: If grouping technology, putting CoRIM vs EAT should be near Concise RIM, but if group WG docs first, this is fine. Some discussion, left as-is. ## Media Types {#media-types} (10 min) Thomas Fossati Defines media-types for different EAT token encodings Two open issues * Use cases and rationale. Ask is for someone else to review. * Early allocation. May need action if process is slow (if it takes more than 2-3 months). Roman, probably not needed. Next steps: Working Group Last Call. Nancy: Action to issue working group last call. And make sure the draft text about why this doc addresses the question raised. ## Concise RIM - CoRIM {#concise-rim---corim} (15 min) Thomas Fossati 01 version added (1) tags (reserved a space of tags as "earmarked", which is a compromise) and (2) conditional endorsements Two PRs in flight * CoRim verification * Introductory text ToDo * Editorial (issues assigned, editors working on them) * Lifecylce (new triples needed that goes beyond CoBOM) * setup registries Aiming for WGLC in September, hopefully a couple of iterations before IETF 117. Want to emphasize slippage is not for lack of interest/energy, just took awhile. Weekly meeting cadence for editors. ## Direct Anonymous Attestation - DAA {#direct-anonymous-attestation---daa} (10 min) Henk Birkholz DAA a 15 year old solution, adds privacy features/anonmous operation Long discussion on previous blocking issue: how to put DAA protocols into RATS architecture; insight (from Thomas) was that this is a protocol that lets "things" take on some of the RATS entities. Next Steps - Asking WGLC. Nancy will issue last-call ## Conceptual Message Wrapper - CMW {#conceptual-message-wrapper---cmw} (10 min) Thomas Fossati Encapsulation format for RATS conceptual messages. Use-cases include TLS auth credentials, include evidence about certs/crl's, etc (DICE), archiving attestation results as files, transport in APIs. Allows multiple protocols to tunnel attestation data and pass it around without unwrap/process/rewrap steps. May add secion for registration Since London editorial fixes/updates and using latest cbor/cddl features. Cross- working group and SDDO discussions * Work in Trusted Computing Group (DICE) - add X.509 extension * LAMPs Want call for adoption. Expect to be done by July, but depends on TCG timelines. Russ: Schedule not reasonable, LAMPS having a big discussion on it. Currently last agenda item so might not happen at this IETF. Nancy: RATS is referencing LAMPS draft Both were confused by last bullet on page 9 of the slide set. Thomas: It is the other way round (LAMPS references RATS inderictly via TCG) Nancy: Will request clarification during adoption call to make sure all agree about the dependency chain within the docs. ## CoRIM vs. EAT (really about endorsement formats and use) {#corim-vs-eat-really-about-endorsement-formats-and-use} (15 min) Dave Thaler Original charter did not allow for endorsements, recharter now allows it Draft outlines what endorsements are; "current state" is not the same as "desired/required/needed-for-verification" state. Endorsements are "current state" (e.g. state of hardware at time of manufacture) Appraisal policy defines comparison rules between reference and current state What endorsements formats (plenty in industry already)? Coparison rules are the simplest if all "current state" use same format, same for "reference state". Less risk of things going wrong (security concerns with increased complexity, such as using different formats). Security: Use CoRIM or EAT, but be consistent for "current state" and "reference state". Question for Working Group, which one to recommend? Footprint: e.g. what if you want to use it on a Cortex M? How many parser do you need in a constrained node? Is there a defintiion of internal verifuer? Dave - yes Thomas: we did discuss this in CoRIM. *Note-taker: not sure of what issues/conclusions, if any, they had reached* Henk: CoRIM goal is to reduce complexity for big verifiers, for small verifiers agrre with Dave (should be consistent and avoid multiple formats for verifiers) Andrew Draper: Already have multi-format evidence protocols, verifiers already have to deal with this, so should make it easy to have safe transformations. Dave to make an update, and then will ask for WG adoption. ## Attested Proximate Location {#attested-proximate-location} (10 min) Giri Mandyam Attested geo-location provides "evidence" of security state See FIRA consortium for some background on location. It is productized, conveyed via geodetic coordinates (WGS-84). Secure ranging detects relative location of device (car keys, point-of-sale under development) Proximate location is different from geolocation attestation Projected location * Assumption reader knows own location UTM System (not discussed in document) * planar projection may be sufficient (small distance between device) Secure ranging reader determines target device location and makes projection * needs to identify the device (out-of band protocol like Bluetooth) What is the trust relationship betwwen decice and reader. Answer - a shared key derived from trusted element Henk: Need is for a new claim? What is the problem with the architecture? There is no concept of distance between attesting device and attested device. Conversation to continue offline and maybe during open mic time. ## Epoch Markers {#epoch-markers} (20 min) Henk Birkholz EpochIDs a mechanism to determine freshness of messages (like nonce, but used by multiple parties - terminolofy work-in-progress) Conveyance of Epoch Bells is what is being introduced. Draft includes seven types o Epoch Markers, Bell veracity proofs Next Steps: Working Group Call for Adoption? Ned: If we define role for bell ringer and we use a nonce, do we still need this new role? Dave: Support going to WG Adoption, with terminology changes (Nonce is confusing) Nancy: Can go to adoption call, with changes ## EAT Attestation Results - EAR {#eat-attestation-results---ear} (10 min) Thomas Fossati Prototypes two use cases: * Composite attesters * Split appraisals Lessons from prototpyes folded into draft Implementations in Golang and C (both apache 2.0 license; at github.com/veraison/\{ear, c-ear}) * C implementation is minimalist * Go is fully fledged EAR = EAT + AR4SI * Working Group question - is this a working group item or a EAP profile (charter supports both, happy with either outcome) Dave: Argue for (B) the EAP profile, not want another doc Giri: Do we have guidance on whether a profile needs to adopted by the working group as it will require IANA registration Nancy: All IETF docs must be adopted aby a WG or have a shepherd. Dave: The doc also has as ection on TEEP. Should not be in a RATS document, but could be brought to the TEEP working group instead. Laurence: If you want to standardise a profile do, if not don't Rich: Profile can just be an individual draft (they don't expire anymore) Nancy: First session where we finish early # Open Mic {#open-mic} (15 min) Laurence: Question about endorsements - doesn't an endorsement have a public key to verify the signature on the claims? Dave: Happy to add that. Same as for evidence. All should be signed by a key. Endorser has key and signs claims Michael Richardson: Want to have conversation at the COSE working group about mediatype registration (+cwt compared to +cbor+cose) Thomas: Can have conversation on COSE mailing list. Haven't heard from them. Thomas: Suggest differnece between endorsed identities vs status Henk: Public key in an endorsement is an identity document. There is more to endorsement than that. Laurence: Endorsements is more than a key securing a message. Should carry implications or informationabout level of trust from the evidence. Lot's of implications from an endorsement, More than range values to check against. Andrew Draper: May need different levels of information/endorsement Dave: Can build out the concept of endorsement, happy to discuss and explore further Andrew: Endorsements are conditional on device properties, would be interested in discussing with Dave. Ned: Question for Dave - is there a repo for discussion? Yes. Will post link, but once adopted will move to WG repo. Giri: Is TCG looking at EAT? Ned: Short answer is yes; if there's a need to put an unsigned eat token in a cert, there would be a way to do that using a CMW cert extension. Dave: added github repository to datatracker document page. *Editorial note: do this for all drafts :)* Thomas: Question for chairs on progress of EAT - timeline wise, what are the next steps Roman: AD review completed, wrking group to review and resolve Giri: Was expecting IANA review, and havent seen further reviews. is AD review gating it. Roman: After AD review, goes for IETF last call. Director reviews (by statute - GenArt etc). IANA takes a look as well at thispoint. IESG review after that Laurence: Thanks for thorough review. Next draft is a few weeks out. Roman: If there are specific concenrs with IANA, we can discuss. Session closed