RE: RADEXT WG re-charter

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Glen Zorn writes...

> 'Frankly, my dear, I don't give a damn.' 

Cute...

> It's been nearly 4 years (!) since draft-zorn-radius-keywrap-00.txt
> was posted ... for at least 3 years there have been at 2 (or more)
> independent, interoperable implementations that were FIPS-certified.

Given that there are implementations of this key-wrap scheme, presumably
using VSAs, it might be well to publish an Information RFC, describing the
actual implementations, using those VSAs.

> But wait!  Let's spend a little (lot) more time conjecturing about
> another way, a way to solve "the general problem" (AKA "boiling the
> ocean" if it's a proposal we don't care for).  Well, gosh, no thanks,
> but you guys go ahead & have fun!

RADEXT has a chartered work item to address crypto-agility.  We have
requirements for this wok, and we now have an ID capturing those
requirements.  We don't have a requirement to specifically address key-wrap,
as a separate problem.  My questions is whether RADEXT really needs to
create two drafts to satisfy the crypto-agility work item, one for key-wrap
and one for general purpose encrypted attributes.  The fact that solutions,
and drafts, exist to address key-wrap and encrypted attributes separately is
a point in favor of retaining the separation.  I'm just questioning whether
that's a sufficient basis on which to decide that we need such separation of
concerns.

If the consensus us of the WG is that we should proceed with separate
documents for key-wrap and general crypto-agility, we can propose doing that
in our revised charter.  It would be nice, however, to have a reason beyond
the existence of (4 year old) drafts that are structured that way.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>