Thank you for the update Mike, I'm happy about the turnaround here. S pozdravem, *Filip Skokan*
On Mon, 17 Feb 2025 at 16:45, Michael Jones <[email protected]> wrote: > The appendix is being removed, in part, because Deb communicated that some > of the algorithms listed are not ones that she’d recommend use of. I plan > to have an updated draft addressing Deb’s comments out in the next few days. > > > > Cheers, > > -- Mike > > > > *From:* Filip Skokan <[email protected]> > *Sent:* Monday, February 17, 2025 7:42 AM > *To:* Deb Cooley <[email protected]> > *Cc:* [email protected]; > [email protected] > *Subject:* Re: [jose] Comments on > draft-ietf-jose-fully-specified-algorithms > > > > 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]
