[{"author": "Rich Salz", "text": "Thanks for being the stand-in chair for so many meetings, Alexey!
", "time": "2022-03-25T09:00:21Z"}, {"author": "Christian Veenman", "text": "Good morning!
", "time": "2022-03-25T09:00:45Z"}, {"author": "dkg", "text": "kaduk: it worked
", "time": "2022-03-25T09:03:43Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "woohoo! The in-meetecho chat doesn't show the body of the message I
used to do it, interestingly.
", "time": "2022-03-25T09:04:05Z"}, {"author": "Roman Danyliw", "text": "Yes, PS
", "time": "2022-03-25T09:11:18Z"}, {"author": "Tim Hollebeek", "text": "Always nice when someone hides the bodies for you.
", "time": "2022-03-25T09:11:27Z"}, {"author": "Sean Turner", "text": "So many enrollment protocols to progress! :)
", "time": "2022-03-25T09:13:51Z"}, {"author": "Mike Ounsworth", "text": "+1 for \"whole new body of work\"
", "time": "2022-03-25T09:14:31Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Sean: I dunno, maybe we should try to really fix the issues in the
enrollment protocols by writing a new enrollment protocol ;)
", "time": "2022-03-25T09:14:38Z"}, {"author": "Sean Turner", "text": "@kaduk: mwhahaaha
", "time": "2022-03-25T09:14:53Z"}, {"author": "Roman Danyliw", "text": "@tero - yes that would be the process
", "time": "2022-03-25T09:14:56Z"}, {"author": "Massimiliano Pala", "text": "You need to enroll in the enrollment protocol mailing list first...
", "time": "2022-03-25T09:15:08Z"}, {"author": "Yoav Nir", "text": "@kaduk: isn't that ACME? or EST?
", "time": "2022-03-25T09:15:09Z"}, {"author": "Sean Turner", "text": "I mean we should really move p10. Maybe I will do that ;)
", "time": "2022-03-25T09:15:13Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "The IESG can run a last-call on a \"status-change document\" to promote
an existing RFC from PS to IS
", "time": "2022-03-25T09:15:19Z"}, {"author": "Mike Ounsworth", "text": "\"Move CMP to IS\" almost sounds like a charterable chunk of work ...
", "time": "2022-03-25T09:15:39Z"}, {"author": "Thom Wiggers", "text": "I think Tero is using his phone so he doesn\u2019t see chat, fyi
", "time": "2022-03-25T09:15:46Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "I think
https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/
is the documentation for such \"status-change document\"s
", "time": "2022-03-25T09:15:54Z"}, {"author": "Roman Danyliw", "text": "@russ -- adding this story of \"CMP Updates\" is first; then maybe a bis for IS later in the shepherd write-up will motivate the current editorial style
", "time": "2022-03-25T09:16:22Z"}, {"author": "Roman Danyliw", "text": "@thom-wiggers: hadn't noticed. thanks
", "time": "2022-03-25T09:17:08Z"}, {"author": "Russ Housley", "text": "@roman: Ack
", "time": "2022-03-25T09:17:11Z"}, {"author": "Massimiliano Pala", "text": "is there a registry we need to maintain?
", "time": "2022-03-25T09:18:57Z"}, {"author": "Sean Turner", "text": "@roman: Can we move RFC 2986, which is Informational, to IS?
", "time": "2022-03-25T09:19:00Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "> it is not a candidate for any level of internet standard
", "time": "2022-03-25T09:19:27Z"}, {"author": "dkg", "text": "why can't future expansion be to change \u2026/.well-known/cmp/\u2026 to \u2026/.well-known/cmp2/\u2026 ?
", "time": "2022-03-25T09:19:40Z"}, {"author": "Sean Turner", "text": "@Massimiliiano: At this point, I beleieve it is only the \"top\": /cmp and /est
", "time": "2022-03-25T09:19:55Z"}, {"author": "Tim Hollebeek", "text": "yeah, that was my question. the previous label is the expansion point
", "time": "2022-03-25T09:20:07Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "The .well-known DEs might give you a funny look (I suppose we could
ask)
", "time": "2022-03-25T09:20:14Z"}, {"author": "Tim Hollebeek", "text": "could even do /est/v1/arbitrarylabel
", "time": "2022-03-25T09:20:42Z"}, {"author": "Tim Hollebeek", "text": "so it's versioned
", "time": "2022-03-25T09:20:47Z"}, {"author": "Alexey Melnikov", "text": "Option #4 (not using .well-known) is violating HTTP recommendations, so this is not going to be good.
", "time": "2022-03-25T09:21:17Z"}, {"author": "Sean Turner", "text": "You can avoid using .well-known, but expect a fight.
", "time": "2022-03-25T09:21:54Z"}, {"author": "dkg", "text": "i think the .well-known DEs will give a funny look anyway, given the \"discovery problems\" that mcr just raised.
", "time": "2022-03-25T09:23:16Z"}, {"author": "Sean Turner", "text": "I am good with that
", "time": "2022-03-25T09:23:21Z"}, {"author": "Yoav Nir", "text": "example.com/.well-known/RFCxxxxx/whatever
", "time": "2022-03-25T09:23:36Z"}, {"author": "Roman Danyliw", "text": "@sean: I'm pretty sure no, RFC2986 got published informational. The upgrade to IS is only possible if you start as a PS.
", "time": "2022-03-25T09:24:22Z"}, {"author": "Sean Turner", "text": "I can work with Magnus/Burt to do that.
", "time": "2022-03-25T09:24:51Z"}, {"author": "Roman Danyliw", "text": "@hendrik: actions caught for reviews or re-reviews.
", "time": "2022-03-25T09:28:14Z"}, {"author": "Mike Ounsworth", "text": "Oh lord, Sean's going full Santa!
", "time": "2022-03-25T09:28:47Z"}, {"author": "dkg", "text": "are you sure it's not karl marx?
", "time": "2022-03-25T09:29:01Z"}, {"author": "Rich Salz", "text": "\"why not both?\"
", "time": "2022-03-25T09:30:21Z"}, {"author": "dkg", "text": "i agree with Alexey
", "time": "2022-03-25T09:32:46Z"}, {"author": "dkg", "text": "it's ok russ, carry on
", "time": "2022-03-25T09:33:12Z"}, {"author": "dkg", "text": "we have time
", "time": "2022-03-25T09:33:14Z"}, {"author": "dkg", "text": "i didn't read the draft yet then ! :P
", "time": "2022-03-25T09:34:00Z"}, {"author": "MichaelRichardson", "text": "I think that Santa is probably some kind of Marxist.
", "time": "2022-03-25T09:34:16Z"}, {"author": "MichaelRichardson", "text": "@Roman, so if we RFC2986bis, then we could actually publish as PS. Should we do that? I guess I can start a thread.
", "time": "2022-03-25T09:35:08Z"}, {"author": "Massimiliano Pala", "text": "CRL delegate signer.
", "time": "2022-03-25T09:37:01Z"}, {"author": "Corey Bonnell", "text": "CRL issuer
", "time": "2022-03-25T09:37:09Z"}, {"author": "Roman Danyliw", "text": "@mkr - I don't know the history of why informational was chosen for RFC2986, but if we make a bis, it could be PS (from a process perspective)
", "time": "2022-03-25T09:38:14Z"}, {"author": "Sean Turner", "text": "We are just trying to drive the average time to RFC down ;)
", "time": "2022-03-25T09:39:53Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Going back a ways to the CMP well-known URI question, I did send Mark
Nottingham an email to try to get his thoughts explicitly.
", "time": "2022-03-25T09:40:08Z"}, {"author": "Roman Danyliw", "text": "I hope this doc is clean so we can pull off sending a -00 to the IESG?
", "time": "2022-03-25T09:40:14Z"}, {"author": "Sean Turner", "text": "@Roman: I think it is clean, but we'll see what the reviewers find.
", "time": "2022-03-25T09:41:33Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Do I need to take a look at something? ;)
", "time": "2022-03-25T09:41:50Z"}, {"author": "Sean Turner", "text": "With all your free time, you can check out: https://datatracker.ietf.org/doc/draft-ietf-lamps-8410-ku-clarifications/ :)
", "time": "2022-03-25T09:46:14Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Oh, but it's already the -00 ... so that means I should *not* look
", "time": "2022-03-25T09:47:10Z"}, {"author": "Tero Kivinen", "text": "This sounds like having some discussion with the https://www.m3aawg.org/ would be useful. There might be more of those implementors present that can actually do something for this.
", "time": "2022-03-25T09:47:55Z"}, {"author": "Rich Salz", "text": "showing algorithm diffs as python fragments is cool!
", "time": "2022-03-25T09:48:53Z"}, {"author": "Sean Turner", "text": "@Ben ;)
", "time": "2022-03-25T09:49:14Z"}, {"author": "Russ Housley", "text": "@dkg: Getting rid of legacy will take a really long time. Consider pine as one example
", "time": "2022-03-25T09:51:16Z"}, {"author": "Mike Ounsworth", "text": "\"There's nothing more permanent then a temporary solution\"
", "time": "2022-03-25T09:53:22Z"}, {"author": "Mike Ounsworth", "text": "*than
", "time": "2022-03-25T09:53:27Z"}, {"author": "Rich Salz", "text": "hahahaa
", "time": "2022-03-25T10:01:45Z"}, {"author": "Jonathan Hammell", "text": "Would a failure to find \"Thursday dinner plans\" in the obscured headers not work? Adding \"**spam**\" or whitespace before/after would not affect that.
", "time": "2022-03-25T10:03:59Z"}, {"author": "Yoav Nir", "text": "Definitely not when you open your mail application and have to go over 100 emails, most of which are irrelevant. That's not a use case for careful inspection.
", "time": "2022-03-25T10:04:15Z"}, {"author": "Mike Ounsworth", "text": "I feel like all 5 of them are in this room ..
", "time": "2022-03-25T10:04:17Z"}, {"author": "Mike Ounsworth", "text": "@dkg Na\u012bvely, you could ignore the plaintext version if there's an encrypted version, but I suppose the attack you need to prevent is that Bob and Frank see different content for the same email?
", "time": "2022-03-25T10:07:18Z"}, {"author": "justus", "text": "maybe the inner (protected) header could indicate that the outside version was obscured by the sender?
", "time": "2022-03-25T10:09:55Z"}, {"author": "Rich Salz", "text": "agreed: impressive detail dkg&team
", "time": "2022-03-25T10:10:58Z"}, {"author": "Sean Turner", "text": "we need to get pink shoes. Then I can always be in the box.
", "time": "2022-03-25T10:12:41Z"}, {"author": "Ludovic Perret", "text": "julien
", "time": "2022-03-25T10:13:13Z"}, {"author": "Yoav Nir", "text": "ASN.1 requires trigger warnings regardless of who made it
", "time": "2022-03-25T10:14:12Z"}, {"author": "Christian Veenman", "text": "Agreed :)
", "time": "2022-03-25T10:14:31Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Did \"we\" consider a short RFC that Updates: ACP to note that the
CSR/attributes usage is believed to be \"wrong\" (not in that phrasing)?
", "time": "2022-03-25T10:17:11Z"}, {"author": "cw-ietf", "text": "the value field needs a tag
", "time": "2022-03-25T10:18:14Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "(RFC 8295 cites PKCS#12 to pull out the number Sean is looking for)
", "time": "2022-03-25T10:20:43Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "oops, reading on it cites a pile of PKCS, so disregard
", "time": "2022-03-25T10:21:14Z"}, {"author": "dkg", "text": "nice squirrel
", "time": "2022-03-25T10:23:35Z"}, {"author": "Rich Salz", "text": "\"nice squirrel\" is an oxymoron, Daniel.
", "time": "2022-03-25T10:26:16Z"}, {"author": "MichaelRichardson", "text": "But, at least reading RFC8295 is what we need to do.
", "time": "2022-03-25T10:26:18Z"}, {"author": "Massimiliano Pala", "text": "(who is \"we\"?)
", "time": "2022-03-25T10:26:32Z"}, {"author": "Bas Westerbaan", "text": "Many of the AES variants are not meant to be used in practice and are less safe than you might expect. (Eg for Kyber and Dilithium)
", "time": "2022-03-25T10:26:46Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "s/nice/very representative/
", "time": "2022-03-25T10:26:51Z"}, {"author": "MichaelRichardson", "text": "the CSR attributes update design team....
", "time": "2022-03-25T10:27:00Z"}, {"author": "Sean Turner", "text": "@massimiliano: I believe it's a group of ACP implementers
", "time": "2022-03-25T10:27:20Z"}, {"author": "Thom Wiggers", "text": "Why could the 3 variants of Dilithium not just get different oids
", "time": "2022-03-25T10:28:23Z"}, {"author": "MichaelRichardson", "text": "well, at least David and I are ACP/RFC8994/RFC8995 implementers, and Dan who has other deployed EST stuff.
", "time": "2022-03-25T10:28:30Z"}, {"author": "Massimiliano Pala", "text": "prameters?
", "time": "2022-03-25T10:28:35Z"}, {"author": "Russ Housley", "text": "As you will see in the next few talks, each algorithm and parameter set will get a separate OID. Thus, parameters are always absent. The OID tells all of that.
", "time": "2022-03-25T10:29:57Z"}, {"author": "Mike Ounsworth", "text": "but if a legacy system nether supports a PQ algorithm, nor does it support that size (ex.: pub key buffers cap at 200,000 kb), then so what?
", "time": "2022-03-25T10:30:12Z"}, {"author": "Mike Ounsworth", "text": "... if you've gotta patch it to add PQ crypto lib support, then you can patch the buffer limits at the same time.
", "time": "2022-03-25T10:30:56Z"}, {"author": "Sean Turner", "text": "That's the CAT pic extension
", "time": "2022-03-25T10:31:12Z"}, {"author": "Roman Danyliw", "text": "OIDs for greasing for certificates?
", "time": "2022-03-25T10:31:25Z"}, {"author": "Sean Turner", "text": "3709 put the cat pic in ;)
", "time": "2022-03-25T10:31:40Z"}, {"author": "dkg", "text": "i'm out of the queue because that was my question: are we talking about private keys or public keys. sounds like he's focusing on private keys
", "time": "2022-03-25T10:31:59Z"}, {"author": "Bas Westerbaan", "text": "related to private key question on a different rfc: https://github.com/seanturner/draft-turner-lamps-nist-pqc-kem-certificates/issues/1
", "time": "2022-03-25T10:32:25Z"}, {"author": "Massimiliano Pala", "text": "That is what I feared - exactly as reported, when I implemented our own code I would have really liked that we could use OID + SecLevel as parameters ... so, I did wrap the current approach and it really helped the practical aspects of working with the keys (especially for ease of use/display for the final user). It is unfortunate we will have to type so much more in our code... hehehehe... when we will add hash-n-sign to the mix... prepare your copy&paste capabilities....
", "time": "2022-03-25T10:33:53Z"}, {"author": "Sean Turner", "text": "@dkg: Will send an email, but I think your example I-Ds looks good WRT the KU selections.
", "time": "2022-03-25T10:34:24Z"}, {"author": "Bas Westerbaan", "text": "I wouldn't call it private-key compression, but rather deterministic key regeneration
", "time": "2022-03-25T10:34:24Z"}, {"author": "Sean Turner", "text": "@bas nice!
", "time": "2022-03-25T10:34:39Z"}, {"author": "Tim Hollebeek", "text": "sounds like a synonym for lossless compression
", "time": "2022-03-25T10:34:57Z"}, {"author": "Tim Hollebeek", "text": "which is a property that's essential in this case anyway :)
", "time": "2022-03-25T10:35:20Z"}, {"author": "Bas Westerbaan", "text": "That's really bad. The Kyber and Dilithium AES variants are not as safe as the claimed level!
", "time": "2022-03-25T10:35:35Z"}, {"author": "John Gray", "text": "We did a research project a couple years ago and added Megabytes of data into certificate and watched some stuff blow up, but surprisingly a lot of things continued to work... https://www.inderscience.com/info/inarticle.php?artid=117887
", "time": "2022-03-25T10:35:43Z"}, {"author": "Yoav Nir", "text": "A lot of things copied their x509 library from some library like OpenSSL. There's not all that many different x509 implementations out there.
", "time": "2022-03-25T10:37:03Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "> a lot of things copied their x509 library from ... OpenSSL
\"they chose poorly\"
", "time": "2022-03-25T10:37:31Z"}, {"author": "Yoav Nir", "text": "Using OpenSSL >>> rolling your own
", "time": "2022-03-25T10:38:06Z"}, {"author": "Mike Ounsworth", "text": "@dkg (self-correction) I think he mentioned that it's not the endpoint-agent itself that's the problem, it's the transport layers to get the keys to the endpoint agent.
", "time": "2022-03-25T10:38:23Z"}, {"author": "Russ Housley", "text": "We have 20 minutes left in the meeting. Need to let the speaker get to their key point. Then, it is clear that we will need an virtual interim meeting
", "time": "2022-03-25T10:40:04Z"}, {"author": "Sean Turner", "text": "@Russ +1
", "time": "2022-03-25T10:40:17Z"}, {"author": "Rich Salz", "text": "IBM has a huge deployed base in the financial biz, and they want a way to pass around long keys.
", "time": "2022-03-25T10:40:51Z"}, {"author": "Rich Salz", "text": "Like, do you want your CCard company to be quantum-safe? :)
", "time": "2022-03-25T10:41:15Z"}, {"author": "Mike Ounsworth", "text": "@dkg in the paper my colleague John Gray posted, see Table 3 on p. 10: we found that Firefox and OpenSSL have buffer issues; but easily fixed with a recompile. https://www.inderscience.com/info/inarticle.php?artid=117887
", "time": "2022-03-25T10:41:27Z"}, {"author": "Massimiliano Pala", "text": "There are many protocols where there are packet size limitations that are hard to change (maybe implemented within chipsets) - compression might help this use-case, I guess.
", "time": "2022-03-25T10:41:56Z"}, {"author": "dkg", "text": "Mike: right, and they'll need a recompile to incorporate the new algorithms anyway, think
", "time": "2022-03-25T10:41:58Z"}, {"author": "Christian Veenman", "text": "So if I understand correctly it's basically: Compressing keys so that these legacy platforms can handle the size vs having these legacy platforms fixing the max private key size issue
", "time": "2022-03-25T10:42:22Z"}, {"author": "dkg", "text": "(unless you're talking about, for example, a libnss upgrade behind the scenes that firefox is unaware of, but i think most firefox implementations ship with their own copy of libnss)
", "time": "2022-03-25T10:42:37Z"}, {"author": "Christian Veenman", "text": "Or am I wrong?
", "time": "2022-03-25T10:42:37Z"}, {"author": "Mike Ounsworth", "text": "I guess the bigger issue is, for example, if the app DB that needs to hold the keys does not have wide enough columns.
", "time": "2022-03-25T10:42:51Z"}, {"author": "dkg", "text": "Christian -- that's what it sounds like to me.
", "time": "2022-03-25T10:43:03Z"}, {"author": "Massimiliano Pala", "text": "Basically, buying time before you need to redesign your system.
", "time": "2022-03-25T10:43:11Z"}, {"author": "Rich Salz", "text": "\"One does not simply redesign a mainframe\"
", "time": "2022-03-25T10:43:30Z"}, {"author": "dkg", "text": "sounds like inserting a bunch of complexity into the entire interoperable ecosystem for the sake of not fiddling with the legacy bits
", "time": "2022-03-25T10:43:35Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "What was that line from earlier...\"there is nothing more permanent
than a temporary solution\"?
", "time": "2022-03-25T10:43:37Z"}, {"author": "Yoav Nir", "text": "Mainframes are for the most part running updated software. There's a lot more Windows XP or 7 in production than there are mainframes with z/OS 1.x
", "time": "2022-03-25T10:43:38Z"}, {"author": "Deb Cooley", "text": "+1 Rich
", "time": "2022-03-25T10:43:38Z"}, {"author": "John Gray", "text": "We have been experimenting with PQ keys and composites and there are some certificate combinations that aren't actually that bad (4-6kb certs). So we haven't needed to use additional compression as many schemes (like SPHINCS) for instance, already employ compression where possible to make keys as small as possible.
", "time": "2022-03-25T10:43:58Z"}, {"author": "Roman Danyliw", "text": "It seems like it might be an argument about how much of the overall system you might need to change. The design I'm hearing is that the specific sub-system doing the crypto operations can be updated for PQC. However, the sub-system that transports key is different, and this work would mitigate the need to change it
", "time": "2022-03-25T10:44:06Z"}, {"author": "dkg", "text": "Yoav: there were *always* more windows XP systems than mainframes with z/OS
", "time": "2022-03-25T10:44:17Z"}, {"author": "Yoav Nir", "text": ":-)
", "time": "2022-03-25T10:44:28Z"}, {"author": "Thom Wiggers", "text": "AFAIK none of the finalists have compressed key formats by the way\u2026
", "time": "2022-03-25T10:45:09Z"}, {"author": "Yoav Nir", "text": "I meant proportions. A typical mainframe has 1-3 system programmers \"taking care of it\". The typical PC got installed some time long ago
", "time": "2022-03-25T10:45:11Z"}, {"author": "dkg", "text": "good luck getting your windows XP system to run dilithium via the core crypto stack \ud83d\ude1b
", "time": "2022-03-25T10:45:40Z"}, {"author": "Thom Wiggers", "text": "You can store precomputed data in private keys but that\u2019s implementation hacks
", "time": "2022-03-25T10:45:51Z"}, {"author": "Bas Westerbaan", "text": "(That's done in RSA private keys.)
", "time": "2022-03-25T10:46:22Z"}, {"author": "Thom Wiggers", "text": "(Fair)
", "time": "2022-03-25T10:47:12Z"}, {"author": "Russ Housley", "text": "@Thom: I do not agree with the ASN.1 in the draft, but it shows a trade-off in size by sending/not sending values that can be computed. Size / compute trade-off.
", "time": "2022-03-25T10:47:14Z"}, {"author": "Deb Cooley", "text": "why is this draft here? and not CFRG? or even working w/ NIST?
", "time": "2022-03-25T10:47:51Z"}, {"author": "Mike Ounsworth", "text": "So, is the very high-level to allow PQC priv keys to be a set of RNG seeds needed to regenerate the priv key, rather than the full priv key data?
", "time": "2022-03-25T10:48:12Z"}, {"author": "Scott Fluhrer", "text": "It's here because it's mostly about how to represent keys in certs
", "time": "2022-03-25T10:48:20Z"}, {"author": "Mike Ounsworth", "text": "+1 Deb
", "time": "2022-03-25T10:48:22Z"}, {"author": "Sean Turner", "text": "@Scott: I thought this was just about privates
", "time": "2022-03-25T10:48:42Z"}, {"author": "Bas Westerbaan", "text": "Mike: +1. Although you could make more trade-offs of course, eg https://github.com/seanturner/draft-turner-lamps-nist-pqc-kem-certificates/issues/1#issuecomment-1061823452
", "time": "2022-03-25T10:48:48Z"}, {"author": "MichaelRichardson", "text": "dkg, imagine that some of the infrastructure is just about how to backup the contents of TEE.
", "time": "2022-03-25T10:50:06Z"}, {"author": "Mike Ounsworth", "text": "+1 dkg: standardizing \"lossless priv key regeneration\" sounds easy-ish to do in proprietary code, hard to do in public standard.
", "time": "2022-03-25T10:50:32Z"}, {"author": "MichaelRichardson", "text": "As Dan said a moment ago, this is about the doors and elevators being too small to get the HSM in/out of the data center.
", "time": "2022-03-25T10:50:44Z"}, {"author": "MichaelRichardson", "text": "But, I think that your point is generally well taken. And stateful interfaces are gonna mess with a lot of operational stuff.
", "time": "2022-03-25T10:51:11Z"}, {"author": "dkg", "text": "John Gray: thanks for doing that legwork!
", "time": "2022-03-25T10:51:48Z"}, {"author": "Bas Westerbaan", "text": "that's the risk early adopters take of course.
", "time": "2022-03-25T10:53:25Z"}, {"author": "Rich Salz", "text": "we did PKCS8 for private keys (yeah okay after RSA/PKP did). And we did key formats for 25519 (used to be what, SECG-1 or something)? Seems appropriate for IETF, esp since NIST sent them here.
", "time": "2022-03-25T10:53:39Z"}, {"author": "Florence D", "text": "I think it would be really useful to hear more about the challenges Michael's been running into. There seems to be disagreement about if there's a problem here, or if there will be once NIST announce their algorithms. Perhaps a ten minute presentation in LAMPS isn't the best place to get to the bottom of this. I'm not sure what is (interim? separate paper?)
", "time": "2022-03-25T10:53:59Z"}, {"author": "Sean Turner", "text": "@Rich and this is intended for informational so like sure
", "time": "2022-03-25T10:54:08Z"}, {"author": "Alexey Melnikov", "text": "Florence D: or whether the proposed solution is the right one
", "time": "2022-03-25T10:54:37Z"}, {"author": "dkg", "text": "i agree that stateful signatures are a different scope, but i'm observing that the \"doors and elevators\" will need to be redesigned for that use case as well
", "time": "2022-03-25T10:54:51Z"}, {"author": "Florence D", "text": "Alexey: That too of course, but laying out the problem is the first step and it's hard to do that and propose a solution in so short a time
", "time": "2022-03-25T10:55:15Z"}, {"author": "Alexey Melnikov", "text": "Florence D: agreed
", "time": "2022-03-25T10:55:28Z"}, {"author": "Yoav Nir", "text": "So this is a draft that says \"these here are the OIDs\". Except the OIDs are still TBD. So the draft is essentially empty now.
", "time": "2022-03-25T10:56:15Z"}, {"author": "dkg", "text": "but the solution might just be \"the constraints on your private key distribution channels should be at least *this* big\"
", "time": "2022-03-25T10:56:20Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "It's more like \"the interpretation of OID <TBD> in PKIX\"
", "time": "2022-03-25T10:56:41Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "\"interpretation and use\", I guess
", "time": "2022-03-25T10:57:02Z"}, {"author": "Rich Salz", "text": "@dkg: but if you can effectively widen the channels by compression, why wouldn't you want to do that interoperably?
", "time": "2022-03-25T10:57:25Z"}, {"author": "dkg", "text": "Rich: if everyone implements it, yes. if it means that some keys are uninterpretable by some systems, then you're actually harming interop
", "time": "2022-03-25T10:58:15Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "\"What do we want?\"
\"WG adoption!\"
\"When do we want it?\"
\"Now!\"
", "time": "2022-03-25T10:58:32Z"}, {"author": "dkg", "text": "+1 to avoiding parameters
", "time": "2022-03-25T10:58:40Z"}, {"author": "Yoav Nir", "text": "But how are those octets in the octet string going to be compresssed?
", "time": "2022-03-25T10:58:57Z"}, {"author": "Rich Salz", "text": "@dkg: we're not the protocol police, to quote a trope.
", "time": "2022-03-25T10:58:59Z"}, {"author": "Mike Ounsworth", "text": "How do I speakL?
", "time": "2022-03-25T10:58:59Z"}, {"author": "Yoav Nir", "text": "click the mic icon
", "time": "2022-03-25T10:59:12Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "local mute
", "time": "2022-03-25T10:59:13Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "meetecho thinks you are sending
", "time": "2022-03-25T10:59:20Z"}, {"author": "Rich Salz", "text": "@yoav: i think that's the point -- specifying how.
", "time": "2022-03-25T10:59:24Z"}, {"author": "Quynh Dang", "text": "looks nice.
", "time": "2022-03-25T10:59:28Z"}, {"author": "Alexey Melnikov", "text": "Mike: or use chat, we can relay
", "time": "2022-03-25T10:59:56Z"}, {"author": "Sean Turner", "text": "to be clear Panos has swayed me to the one alg per I-D.
", "time": "2022-03-25T11:00:05Z"}, {"author": "Mike Ounsworth", "text": "I'll type
", "time": "2022-03-25T11:00:16Z"}, {"author": "John Gray", "text": "I was going to ask about Signatures as well. Should there be one for that.
", "time": "2022-03-25T11:00:46Z"}, {"author": "Mike Ounsworth", "text": "@Sean: note that there are some important security considerations around KEMs: I think you draft needs to limit the shared secret length for each KEM
", "time": "2022-03-25T11:00:47Z"}, {"author": "Rich Salz", "text": "bye all
", "time": "2022-03-25T11:00:47Z"}, {"author": "Yoav Nir", "text": "Interim should be after the announcement
", "time": "2022-03-25T11:00:55Z"}, {"author": "Tim Hollebeek", "text": "thanks everyone for some great discussion!
", "time": "2022-03-25T11:00:58Z"}, {"author": "Bas Westerbaan", "text": "thank you all!
", "time": "2022-03-25T11:00:59Z"}, {"author": "dkg", "text": "thanks all
", "time": "2022-03-25T11:01:01Z"}, {"author": "Massimiliano Pala", "text": "bye all! Thank you!
", "time": "2022-03-25T11:01:03Z"}, {"author": "Quynh Dang", "text": "Thank you all.
", "time": "2022-03-25T11:01:04Z"}, {"author": "Bas Westerbaan", "text": "thank you, Sean
", "time": "2022-03-25T11:01:04Z"}, {"author": "Alexey Melnikov", "text": "Thank you
", "time": "2022-03-25T11:01:08Z"}, {"author": "Jan Klau\u00dfner", "text": "Thanks and bye!
", "time": "2022-03-25T11:01:17Z"}, {"author": "justus", "text": "thanks
", "time": "2022-03-25T11:01:21Z"}, {"author": "Massimiliano Pala", "text": "Looking forward to the interim :)
", "time": "2022-03-25T11:01:24Z"}, {"author": "John Gray", "text": "Thanks everyone
", "time": "2022-03-25T11:01:32Z"}, {"author": "Sean Turner", "text": "@MikeO: noted
", "time": "2022-03-25T11:01:33Z"}]