Subject: [SPKM] One more solution path

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Nov 2006 13:52:17 -0600

No WG, no design team to make a decision, just this:

    The first proposal in this space that makes it past the IESG as
    Proposed Standard is the only one that does.

    If more than one proposal makes it to the IESG before the IESG
    approves of one, then the IESG will decide which one to progress to
    Proposed Standard (unless the IESG feels generous, I suppose).

It sounded like Mike wants something that re-uses RFC4121 per-msg tokens
to make kernel-land implementations trivial.  I agree.  I too would like
to drop the idea of using DTLS record messages for per-msg tokens (I
had that option in my proposal only to satisfy any purists).

It also sounds like Larry wants something that re-uses technology that's
already at his disposal, that being either PKINIT or TLS.

And I'm willing to go with any of SSiLKeY/PKU2U/GSS-TLS.  I prefer
GSS-TLS (with RFC4121 per-msg tokens) and believe it will be easier for
Mike and Larry to implement GSS-TLS than it will be to implement their
alternatives, but I'm very much open to being convinced that either
SSiLKEY or PKU2U will do.

So it sounds like Mike, Larry and I can work on a proposal that isn't
SPKM.

I.e., there are really only TWO proposals here: SPKM-3+ and not-SPKM-3.
The not-SPKM-3 proposals being aimed at re-using existing specs and code
as much as possible.

Cheers,

Nico
-- 

_______________________________________________
SPKM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/spkm