[SPKM] One more solution path

Nicolas Williams <Nicolas.Williams@sun.com> Mon, 06 November 2006 19:52 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhAW9-0004tw-1B; Mon, 06 Nov 2006 14:52:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhAW7-0004tj-Cb for spkm@ietf.org; Mon, 06 Nov 2006 14:52:23 -0500
Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhAW3-0007Tl-WF for spkm@ietf.org; Mon, 06 Nov 2006 14:52:23 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA6JqJD9026663 for <spkm@ietf.org>; Mon, 6 Nov 2006 12:52:19 -0700 (MST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kA6JqIMB003805 for <spkm@ietf.org>; Mon, 6 Nov 2006 12:52:19 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kA6JqIc4027162 for <spkm@ietf.org>; Mon, 6 Nov 2006 13:52:18 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA6JqHHp027161 for spkm@ietf.org; Mon, 6 Nov 2006 13:52:17 -0600 (CST)
Date: Mon, 06 Nov 2006 13:52:17 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: spkm@ietf.org
Message-ID: <20061106195216.GL25646@binky.Central.Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Subject: [SPKM] One more solution path
X-BeenThere: spkm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Low Infrastructure Public Key GSS mechanism <spkm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/spkm>, <mailto:spkm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/spkm>
List-Post: <mailto:spkm@ietf.org>
List-Help: <mailto:spkm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/spkm>, <mailto:spkm-request@ietf.org?subject=subscribe>
Errors-To: spkm-bounces@ietf.org

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
SPKM@ietf.org
https://www1.ietf.org/mailman/listinfo/spkm