No known issues in draft-ietf-lamps-nf-eku
", "time": "2023-11-06T16:39:46Z"}, {"author": "Aritra Banerjee", "text": "*open
", "time": "2023-11-06T16:40:28Z"}, {"author": "Yoav Nir", "text": "At least from remote, the speaker's mic is very low. Is it just that they're standing far from it, or is it an amplification issue?
", "time": "2023-11-06T16:41:47Z"}, {"author": "Yoav Nir", "text": ":+1:
", "time": "2023-11-06T16:42:43Z"}, {"author": "Mike Ounsworth", "text": "@Yoav Nir Better now?
", "time": "2023-11-06T16:42:47Z"}, {"author": "Yoav Nir", "text": "Yeah
", "time": "2023-11-06T16:42:59Z"}, {"author": "Daniel Gillmor", "text": "re: draft-ietf-lamps-cert-binding-for-multi-auth: i don't understand any meaningful advantage of having an optional hash algorithm. it seems like one more thing to break. keep it simple.
", "time": "2023-11-06T16:51:36Z"}, {"author": "Sean Turner", "text": "If the chairs accept my request I can present the ML-KEM (n\u00e9e Kyber) Certificates I-D.
", "time": "2023-11-06T16:54:13Z"}, {"author": "Alison Becker", "text": "@dkg thanks for the note - I like simple as well!
", "time": "2023-11-06T16:55:09Z"}, {"author": "Michael StJohns", "text": "I\u2019m not where I can talk.
", "time": "2023-11-06T16:55:48Z"}, {"author": "Tim Hollebeek", "text": "I accepted the Kyber slides, I'm going to suggest to Russ we consider returning to them after Corey (who is next)
", "time": "2023-11-06T16:57:16Z"}, {"author": "Tadahiko Ito", "text": "instead of Corey, I am presenting
", "time": "2023-11-06T16:57:51Z"}, {"author": "Tadahiko Ito", "text": "(5019bis)
", "time": "2023-11-06T16:58:22Z"}, {"author": "Michael StJohns", "text": "But more likely than not you will end up with multiple attestations where the chains are identical except for the attestation key certificate.
", "time": "2023-11-06T16:59:15Z"}, {"author": "Tim Hollebeek", "text": "Thank you Tadahiko
", "time": "2023-11-06T17:04:01Z"}, {"author": "Sean Turner", "text": "@Tim that works!
", "time": "2023-11-06T17:06:48Z"}, {"author": "Mike Ounsworth", "text": "Michael StJohns said:
\n\n\nBut more likely than not you will end up with multiple attestations where the chains are identical except for the attestation key certificate.
\n
I thought that was one of the core usecases that Carl's suggestion handles gracefully.
\nIs there a reason those multiple attestations can't bundled into a single EvidenceBundle?
EvidenceBundle {\n evidence: [ [evidence1], [evidence2], [evidence3] ],\n certs: [ [EndEntity1], [EndEntity2], [EndEntity3], [common-intCA], [common-rootCA] ]\n}\n?
", "time": "2023-11-06T17:09:12Z"}, {"author": "Ned Smith", "text": "Does EE mean end-entity or evidence or both?
", "time": "2023-11-06T17:11:58Z"}, {"author": "Mike Ounsworth", "text": "Ned Smith said:
\n\n\nDoes EE mean end-entity or evidence or both?
\n
Edited. Clearer?
", "time": "2023-11-06T17:14:18Z"}, {"author": "David Benjamin", "text": "Doesn't the Kyber spec have an opinion on this already? We should just do whatever it does.
", "time": "2023-11-06T17:16:54Z"}, {"author": "Mike Ounsworth", "text": "David Benjamin said:
\n\n\nDoesn't the Kyber spec have an opinion on this already? We should just do whatever it does.
\n
Yeah, I think that's exactly the point; NIST is telling us how to encode a Kyber public key (right?); far from us to re-engineer that.
", "time": "2023-11-06T17:17:39Z"}, {"author": "David Benjamin", "text": "Well public key it had better have an opinion on or we really have problems. I think it also has the same opinion on the private key. Which is that, in both cases, you leave the A matrix out of the format and expand it on use or import.
", "time": "2023-11-06T17:18:23Z"}, {"author": "Ned Smith", "text": "Mike said: >Edited. Clearer?
", "time": "2023-11-06T17:18:56Z"}, {"author": "Ned Smith", "text": "I'm thinking about SPDM alias cert models
", "time": "2023-11-06T17:19:19Z"}, {"author": "Mike Ounsworth", "text": "Specifically the problem is that we become the COSE WG who are still arguing about how to encode ECC public keys :P
", "time": "2023-11-06T17:19:20Z"}, {"author": "David Benjamin", "text": "I can imagine a use case for shipping the A matrix with the private key if you want to avoid computing it and trust the source of your private key. They can do something special. For general interchange, let's avoid the redundancy.
", "time": "2023-11-06T17:19:53Z"}, {"author": "Mike Ounsworth", "text": "Ned Smith said:
\n\n\nI'm thinking about SPDM alias cert models
\n
... I don't know what that is.
", "time": "2023-11-06T17:19:55Z"}, {"author": "David Benjamin", "text": "Mike Ounsworth said:
\n\n\nSpecifically the problem is that we become the COSE WG who are still arguing about how to encode ECC public keys :P
\n
Yeah, ECC made the mistake of not being quite firm enough in sticking to the \"there is only one encoding, stop arguing\" model. Let's never make that mistake again.
", "time": "2023-11-06T17:20:29Z"}, {"author": "Mike Ounsworth", "text": "RE: \"ML-KEM\" vs \"Kyber\": nobody uses \"Rijndael\" anymore. It's AES.
", "time": "2023-11-06T17:23:21Z"}, {"author": "David Benjamin", "text": "I guess this is also because JOSE set a precedent of exploding all the parameters into JSON. E.g. rather than just base64-encoding the usual ASN.1 encoding, each RSA field is stuck into a separate key. I wasn't there, but I guess people consider ASN.1 gross and wanted to avoid it? And then likewise they exploded the EC point coefficients, even though there isn't even any ASN.1 involved.
", "time": "2023-11-06T17:23:32Z"}, {"author": "Ned Smith", "text": "Mike Ounsworth said:
\n\n\nNed Smith said:
\n\n\nI'm thinking about SPDM alias cert models
\n... I don't know what that is.
\n
SPDM cert model allows dynamic extension of the cert path by an embedded CA. ECA issued certs can contain evidence.
", "time": "2023-11-06T17:31:52Z"}]