FWIW the sentiment about Appendix A removal is not a first occurrence, it has come up before in both WGLC reviews, e.g. most recently in the 2nd WGLC <https://mailarchive.ietf.org/arch/msg/jose/fFC3MICb0IZGhxaBt3BXaStimu0/>. In either occurrence this has not swayed the author's determination to keep it, it has merely resulted in minor adjustments here and there.
For the record I would still rather see it removed but in its current state it's not a hill I'm willing to die on anymore. S pozdravem, *Filip Skokan* On Thu, 9 Jan 2025 at 14:52, Deb Cooley <[email protected]> wrote: > Thanks to the authors for writing this draft. Below are my comments to be > addressed before submitting this draft to IETF Last Call: > > General: Parts of this draft are very useful, but we need to make sure > that we aren't 'burying the lead' ( > https://www.merriam-webster.com/wordplay/bury-the-lede-versus-lead). > Hopefully my comments will help in that regard. > > Section 1, definitions: Both 'fully specified' and 'polymorphic' are > defined. They aren't the terms I would have used, necessarily. > Polymorphic, I would have said was 'under specified'. [I'm not asking for a > change here.] > > Section 3: The section is long, rambling, and appears to be > informational. Perhaps constructing 1-2 examples from this section and > Appendix A would be more clear and concise? One example where the shared > secret (the output of the asymmetric key establishment) is processed (KDF) > to become the content encryption key, and another where the shared secret > is processed to become a key encryption key which then encrypts the > sender-generated content encryption key (allowing for more than one > recipient). > > I understand that there is a desire to improve the information for the > designated experts for these registries. That information should be in > this section, perhaps some version of the last couple of paragraphs from > Section 3.2.2 and 3.2.3. > > Appendix A: I don't like the fact that there are items in the tables that > we would not want an implementer to use without a lot of thought and > consideration (any asymmetric static-static key establishment, for > example). I'd rather see this Appendix removed. > > Deb Cooley > Sec AD > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
