[ ] I think we're converging on a consensus solution with LAMPS mailing list discussions, the parallel openpgp-pqc draft, and CFRG KEM Combiners DT (Mike Ounsworth is a member).
[ ] The goal is to get this "within a stone's throw" of ready so that we can finish it up and get it into WGLC shortly after FIPS 203 (ML-KEM) is final.
[ ] We're close.
[ ] Go through changelog
[ ] Go through open issues:
[ ] #29: The unnecessary OCTET STRING wrapping
[ ] Discuss Pros / Cons of including the tradPK in the combiner.
[ ] Why KDF = SHA3 and without a SHA2 option?
[ ] We are aware of the feedback (Deb, Joe) that some implementations will not have easy access to SHA-3 at the layer that is implementing the combiner. We have chosen SHA3 because that aligns security analysis with X-Wing and openpgp-pqc. We could also add HMAC-SHA2 variants, but that will 2x the numbers of algs that we're registering (note: you can't just replace SHA3 with SHA2 without losing security properties; it has to be HMAC-SHA2).
[ ] binary compatibility with X-Wing b/c of LAMPS-specific domSep. Good? Bad?
[ ] Despite making breaking changes, we did not rev the OIDs; but we are unaware of any working implementations yet (hackathon), so we think this is ok.
[ ] We have included a USE IN CMS section, but traditionally LAMPS likes to specify the algorithms, and the CMS conventions in separate documents. Do you want us to split them?
tradPKin the combiner.KDF = SHA3and without a SHA2 option?