[{"author": "kivinen", "text": "can you hear the chairs, or do they need to get closer to mic?
", "time": "2022-03-22T09:04:26Z"}, {"author": "Nancy Cam-Winget", "text": "@Giri: will do!
", "time": "2022-03-22T09:04:54Z"}, {"author": "cabo", "text": "Certainly better than John (who has strong room reverb)
", "time": "2022-03-22T09:05:03Z"}, {"author": "Roman Danyliw", "text": "We're moving quite fast ...
", "time": "2022-03-22T09:10:00Z"}, {"author": "Roman Danyliw", "text": "To revisit charra (draft-ietf-rats-yang-tpm-charra), the document has enough IESG ballot to pass when the DISCUSSes are cleared. If these don't clear before the IESG turn-over it will lose ballots
", "time": "2022-03-22T09:10:59Z"}, {"author": "Nancy Cam-Winget", "text": "@Roman: when will the turn over close?
", "time": "2022-03-22T09:13:10Z"}, {"author": "Nancy Cam-Winget", "text": "close -> complete
", "time": "2022-03-22T09:13:25Z"}, {"author": "Henk Birkholz", "text": "@Roman: Warren's comments on charra are the only remaining blocker. I am happy to resolve them with Eric online and MD onsite on Wed
", "time": "2022-03-22T09:16:26Z"}, {"author": "Henk Birkholz", "text": "@Roman: please sync with Rob about his discuss
", "time": "2022-03-22T09:16:52Z"}, {"author": "Henk Birkholz", "text": "MD -> me
", "time": "2022-03-22T09:17:25Z"}, {"author": "Henk Birkholz", "text": "@Roman: My perception is that Rob's comments might have resolved to an extend that allows to progress
", "time": "2022-03-22T09:18:37Z"}, {"author": "Roman Danyliw", "text": "I was clarifying the process point that it _does_ have enough ballots (we just need to convert the DISCUSSes to No Objective or Yes).
", "time": "2022-03-22T09:20:56Z"}, {"author": "Roman Danyliw", "text": "^^ these just appeared. IESG turn-over happens on Wednesday evening at the plenary
", "time": "2022-03-22T09:21:55Z"}, {"author": "Roman Danyliw", "text": "draft-ietf-rats-architecture = Publication requested (with me as AD).
", "time": "2022-03-22T09:24:01Z"}, {"author": "Roman Danyliw", "text": "The confusion is that there was talk about doing directorate reviews _before_ WGLC (but that didn't occur). After I complete my AD re-review it can to IETF LC.
", "time": "2022-03-22T09:24:59Z"}, {"author": "kivinen", "text": "And during the IETF LC there will be directorate reviews done anyways, so no point of starting them now if document is ready for IETF LC.
", "time": "2022-03-22T09:25:59Z"}, {"author": "Thomas Hardjono", "text": "DAA is designed for the TPM
", "time": "2022-03-22T09:27:17Z"}, {"author": "Thomas Hardjono", "text": "Needs more work to look into a Privacy-CA for DICE
", "time": "2022-03-22T09:27:31Z"}, {"author": "Thomas Hardjono", "text": "DAA was designed to \"hide\" the EK-Certificate in the TPMv1.2 to prevent tracking of multiple signatures done by the TPM.
", "time": "2022-03-22T09:30:01Z"}, {"author": "Thomas Hardjono", "text": "Different problem from mobile phone tracking
", "time": "2022-03-22T09:30:13Z"}, {"author": "Giridhar Mandyam", "text": "@Diego Lopez, please provide your question directly into the Notepad
", "time": "2022-03-22T09:32:28Z"}, {"author": "Ira McDonald", "text": "UECS? Unprotected Encoding Claims Sets?
", "time": "2022-03-22T09:36:07Z"}, {"author": "Giridhar Mandyam", "text": "(As an EAT editor) Recommend any decisions on UCCS be deferred until after my presentation in 2 days
", "time": "2022-03-22T09:36:44Z"}, {"author": "Roman Danyliw", "text": "Per early allocation in EAT, https://mailarchive.ietf.org/arch/msg/rats/nmCc8LnRRNTi_8K2y04dTjZbvag/
", "time": "2022-03-22T09:39:55Z"}, {"author": "Roman Danyliw", "text": "Thanks @Mike Jones for the review.
", "time": "2022-03-22T09:40:08Z"}, {"author": "Giridhar Mandyam", "text": "Thanks @Mike Jones
", "time": "2022-03-22T09:44:15Z"}, {"author": "Roman Danyliw", "text": "Please use the meetecho poll tool. Those in the room should be
", "time": "2022-03-22T09:50:31Z"}, {"author": "Roman Danyliw", "text": "Can we bring up the proposed charter text. This is the old text
", "time": "2022-03-22T09:50:59Z"}, {"author": "Ira McDonald", "text": "Reading stuff on GitHub is too much extra bandwidth - sorry
", "time": "2022-03-22T09:53:48Z"}, {"author": "Kristina Yasuda", "text": "can someone post a link to the GH in the chat?
", "time": "2022-03-22T09:54:23Z"}, {"author": "Dave Thaler", "text": "I like 6 but why 5?
", "time": "2022-03-22T09:55:06Z"}, {"author": "Roman Danyliw", "text": "https://github.com/ietf-rats/charter/blob/master/ietf-rats-charter.md
", "time": "2022-03-22T09:55:45Z"}, {"author": "Dave Thaler", "text": "ah because 5 was there before
", "time": "2022-03-22T09:55:49Z"}, {"author": "Dave Thaler", "text": "but do we think we actually need protocols?
", "time": "2022-03-22T09:56:20Z"}, {"author": "Dave Thaler", "text": "(new)
", "time": "2022-03-22T09:56:27Z"}, {"author": "Dave Thaler", "text": "+1 to Henk. maybe reword as \"Standardize USE of interoperable...\"
", "time": "2022-03-22T09:56:58Z"}, {"author": "Thomas Hardjono", "text": "There are use case needing different protocol.
", "time": "2022-03-22T09:58:10Z"}, {"author": "Thomas Hardjono", "text": "A vehicle ECU unit with a TPM may need a different protocol
", "time": "2022-03-22T09:58:29Z"}, {"author": "Thomas Hardjono", "text": "from a PC computer over the Internet
", "time": "2022-03-22T09:58:40Z"}, {"author": "Thomas Hardjono", "text": "Different also from a server chases with DICE
", "time": "2022-03-22T09:59:35Z"}, {"author": "Ira McDonald", "text": "+1 to USE of interoperable protocols
", "time": "2022-03-22T09:59:42Z"}, {"author": "Roman Danyliw", "text": "+1 to Dave + Ira's idea to reduce scope of #5
", "time": "2022-03-22T10:00:50Z"}, {"author": "Ira McDonald", "text": "TH - a non-Internet protocol is out-of-scope for an IETF spec
", "time": "2022-03-22T10:02:38Z"}, {"author": "Thomas Hardjono", "text": "@Ira: oh yes, I forgot. Thx :-)
", "time": "2022-03-22T10:03:10Z"}, {"author": "Dave Thaler", "text": "@Ira: there's lots of non \"Internet\" IETF protocols, ARP, DHCP, mDNS, etc
", "time": "2022-03-22T10:04:22Z"}, {"author": "Thomas Hardjono", "text": "@Dave: I think you are correct that we need to say which part of the flows is being discussed.
", "time": "2022-03-22T10:05:01Z"}, {"author": "Ira McDonald", "text": "Dave Thaler - all of which are in service of the Internet Suite
", "time": "2022-03-22T10:05:03Z"}, {"author": "Chris Inacio", "text": "+1 Hannes
", "time": "2022-03-22T10:05:18Z"}, {"author": "Thomas Hardjono", "text": "The protocol form Attester-to-Verifier may be different from Verifier-to-RP
", "time": "2022-03-22T10:05:32Z"}, {"author": "Dave Thaler", "text": "agree Thomas
", "time": "2022-03-22T10:05:46Z"}, {"author": "Ira McDonald", "text": "TH - agree - several protocols are necessary probably
", "time": "2022-03-22T10:05:55Z"}, {"author": "Dave Thaler", "text": "in the original WG scoping discussion people said there wasn't a strong case for an interoperable protocol for verifier communication. Maybe that's changed now, would be worth asking the WG.
", "time": "2022-03-22T10:07:06Z"}, {"author": "Roman Danyliw", "text": "We can get feedback here and a sense here. However, when we have the FINAL version of the charter text it will go back to the list for final confirmation.
", "time": "2022-03-22T10:09:06Z"}, {"author": "Roman Danyliw", "text": "We will also need milestones with the re-charter
", "time": "2022-03-22T10:10:01Z"}, {"author": "Roman Danyliw", "text": "I see the following pending milestones:
", "time": "2022-03-22T10:13:23Z"}, {"author": "Roman Danyliw", "text": "Last Submit direct anonymous attestation procedures for IESG publication
draft-ietf-rats-daa
Submit CBOR tag for unprotected CWT claims sets to IESG for publication
draft-ietf-rats-daa
Submit attestation results for secure interactions to IESG for publication
draft-ietf-rats-ar4si
Next Call for adoption on proposal to address the framing and format of Endorsements and Reference Values
", "time": "2022-03-22T10:13:24Z"}, {"author": "Dave Thaler", "text": "I'm not sure I understood that either
", "time": "2022-03-22T10:21:51Z"}, {"author": "Robin Wilton", "text": "+1 Hannes
", "time": "2022-03-22T10:23:08Z"}, {"author": "Robin Wilton", "text": "You can't pre-judge (let alone define in the architecture) what qualities of an attestation result make it \"reliable on\" for an RP. RPs gonna rely.
", "time": "2022-03-22T10:24:42Z"}, {"author": "Thomas Hardjono", "text": "@Brendan: yes, correct. Different types and verifiers
", "time": "2022-03-22T10:35:56Z"}, {"author": "Thomas Hardjono", "text": "performing different \"degrees\" of verifications
", "time": "2022-03-22T10:36:13Z"}, {"author": "Thomas Hardjono", "text": "I think the word \"verifier\" needs qualifier
", "time": "2022-03-22T10:36:55Z"}, {"author": "Dave Thaler", "text": "@Eric: you have an Appraisal Policy for ARs in the RP. Terminology wise, that's different from a Verifier. (Which may or may not be together with the RP)
", "time": "2022-03-22T10:37:39Z"}, {"author": "Ira McDonald", "text": "+1 to Marco's comment - Level of Assurance is fundamental and necessary for any useful attestation ecosystem
", "time": "2022-03-22T10:38:18Z"}, {"author": "Robin Wilton", "text": "Ahah... Levels of Assurance. Slowly but surely, the Vectors of Trust I-D is creeping towards us...
", "time": "2022-03-22T10:38:30Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "RFC now, no?
", "time": "2022-03-22T10:40:36Z"}, {"author": "Thomas Hardjono", "text": "How's about a AR4SI-LOA ? :-)
", "time": "2022-03-22T10:40:39Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "(RFC 8485: Vectors of Trust)
", "time": "2022-03-22T10:40:51Z"}, {"author": "Thomas Hardjono", "text": "AR4SI-LOA-VOT
", "time": "2022-03-22T10:41:06Z"}, {"author": "Robin Wilton", "text": "@Ben Yes - my bad!!
", "time": "2022-03-22T10:41:44Z"}, {"author": "Robin Wilton", "text": "https://datatracker.ietf.org/doc/rfc8485/
", "time": "2022-03-22T10:42:12Z"}, {"author": "Ira McDonald", "text": "And the ITU second edition of much earlier work from 15 years ago on LOA https://www.itu.int/rec/T-REC-X.1254-202009-I/en
", "time": "2022-03-22T10:42:46Z"}, {"author": "Brendan Moran", "text": "IMHO, device identity can NEVER be anything other than a public key. Nothing else can be *proven*
", "time": "2022-03-22T10:44:54Z"}, {"author": "Dave Thaler", "text": "+1 to Hannes (identifier not identity per se)
", "time": "2022-03-22T10:45:33Z"}, {"author": "Brendan Moran", "text": "+1 to Hannes
", "time": "2022-03-22T10:45:53Z"}, {"author": "Robin Wilton", "text": "@Ira and OMB 04-04, from about 2003...
", "time": "2022-03-22T10:47:00Z"}, {"author": "Dave Thaler", "text": "yep UEID text says it's an identifier (not identity)
", "time": "2022-03-22T10:47:39Z"}, {"author": "Thomas Hardjono", "text": "Each layer in the DICE model may end-up with different \"identities\"
", "time": "2022-03-22T10:48:08Z"}, {"author": "Dave Thaler", "text": "@Henk: I would also have no objection to adding to arch doc, but personally I don't think it's needed (for reasons others like Ned said)
", "time": "2022-03-22T10:49:34Z"}, {"author": "Ira McDonald", "text": "@Robin OMB == US White House Office of Mgmt and Budget? or something else?
", "time": "2022-03-22T10:50:01Z"}, {"author": "Brendan Moran", "text": "By the same logic, I could claim that you should convert all EUIDs and convert them to version 5 UUIDs
", "time": "2022-03-22T10:50:58Z"}, {"author": "Robin Wilton", "text": "@Ira yes - apologies for the cryptic algorithm!
", "time": "2022-03-22T10:53:41Z"}, {"author": "Robin Wilton", "text": "https://www.documentcloud.org/documents/2852019-OMB-Memo-M-04-04-EAuthentication-Guidance-for.html
", "time": "2022-03-22T10:54:08Z"}, {"author": "Ira McDonald", "text": "Attestation Results seems to be an amorphous term that's a religious subject and not an architectural concept
", "time": "2022-03-22T10:56:14Z"}, {"author": "Brendan Moran", "text": "FWIW, I don't see any protocol changes regardless of the semantics we're discussing
", "time": "2022-03-22T10:58:49Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "device identity as a public key is attractive in some ways, akin to
HIP's \"the address *is* the key\". But it's pretty rare that using
that as the only device identifier is feasible, and the database
binding public-key id to other ID remains a possible vector of attack.
", "time": "2022-03-22T10:59:02Z"}, {"author": "Brendan Moran", "text": "@ben, I agree, but I'd also argue that any other identity has a larger attack surface.
", "time": "2022-03-22T11:00:15Z"}, {"author": "Brendan Moran", "text": "Perfect is the enemy of good \u00af_(\u30c4)_/\u00af
", "time": "2022-03-22T11:00:28Z"}, {"author": "Robin Wilton", "text": "Thanks Nancy - great job, as ever!
", "time": "2022-03-22T11:00:54Z"}, {"author": "Massimiliano Pala", "text": "Thanks Everybody!
", "time": "2022-03-22T11:00:57Z"}, {"author": "Guy Fedorkow", "text": "Thanks Nancy, Ned!
", "time": "2022-03-22T11:01:25Z"}, {"author": "Robin Wilton", "text": "@Brendan/Ben I think you want a layer of abstraction between the thing the device thinks of as its own identifier, and any key pair bound to that.
", "time": "2022-03-22T11:02:00Z"}]