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]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
