[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
- [SPKM] One more solution path Nicolas Williams