Update 2024-01-29.md

meetingNotes/2024-01-29.md

@@ -12,9 +12,56 @@ I think we are due for a scoping conversation: how big a kettle are we building?
 
 # Attendance
 
+* Mike Ounsworth
+* Dieter Bong
+* Tschofenig, Hannes (T CST SEA-DE)
+* AMADOR Eric
+* Kemp, John
+* Daniel Migault
+* Jean-Pierre Fiset (Crypto4A)
+* Willard 'Monty' Wiseman
+* Birkholz, Henk
+* Stein, A.J. Mr. (Fed)
+* Chris Trufan
+* Smith, Ned
+
 
 # Discussions
 
+LAMPS > csr-attestation
+
+Discussed at some length about freshness and the current wording of security consideration section 7.1. We all agree that freshness is good, but that CSRs need to work in edge-cases where freshness is not possible (ex.: HSMs in air-gapped networks where a challenge round-trip is not possible and the device does not have access to NTP and so has an un-reliable system clock), and even is cases where there is a notion of freshness, the exact freshness mechanism will be specific to the Evidence statement type and/or the certificate management protocol -- ex.: one HSM vendor may use an Epoch-based freshness mechanism, while another uses a clock-based mechanism; or a cert management protocol like ACME or CMP might build in their own freshness mechanism -- so Evidence freshness really does not belong at the CSR wrapper layer specified in this I-D.
+
+So we are all agreed on what the goal is, and we all have homework to re-read 7.1 and see if it is saying that clearly enough.
+
+Discussions on this point are happening in:
+https://github.com/lamps-wg/csr-attestation/issues/80
+https://github.com/lamps-wg/csr-attestation/issues/84
+
+
+
+
+Discussed at some length the OID references registry
+
+https://github.com/lamps-wg/csr-attestation/pull/83
+
+Basically, implementors writing Relying Parties against this spec will ask "Ok, but where can I find a list of all the OIDs that I can expect to see show up in EvidenceStatement.type?". 
+So this document will instruct IANA to create a new registry that is a collection of, and references to, Attestation Evidence format OIDs that have been registered elsewhere. The proposed format for the table is:
+
+| OID              | Description                | Reference(s)   | Change Controller |
+|------------------|----------------------------|----------------|-------------------|
+| 2 23 133 5 4 10  | DICE Evidence              | {{TCGDICE1.1}} |  TCG              |
+| 2 23 133 5 4 9   | Conceptual Message Wrapper | {{TCGDICE1.1}} |  TCG              |
+
+
+
+
+RATS > x509-evidence
+
+We really want to get the CSR draft shipped so that we can dedicate more time to the x509-evidence draft than just the last 8 minutes of every meeting.
+
+We discussed that for draft-x509-evidence, the main driver is "big" HSMs which currently do not have any standardized Evidence formats, and who prefer to stay in ASN.1. The conversation has so far been dominated with discussion of how to make this format appropriate for TPMs. We have decided to, for now, sideline all TCG / TPM / DICE discussion, focus on satisfying the core HSM usecase, and then at the end we can come back and then at the end come back to whether the resulting Evidence format would have any value for TPMs to implement.
+