[IPsec] Which option to pick on draft-kivinen-ipsecme-oob-pubkey-02.txt

Tero Kivinen <kivinen@iki.fi> Tue, 06 November 2012 19:02 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9877821F8ADA for <ipsec@ietfa.amsl.com>; Tue, 6 Nov 2012 11:02:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fsXBsuO5XyTQ for <ipsec@ietfa.amsl.com>; Tue, 6 Nov 2012 11:02:05 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8565C21F8AB9 for <ipsec@ietf.org>; Tue, 6 Nov 2012 11:02:04 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost []) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA6J1xB1011011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipsec@ietf.org>; Tue, 6 Nov 2012 21:01:59 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA6J1x7L000162; Tue, 6 Nov 2012 21:01:59 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20633.24231.244628.939482@fireball.kivinen.iki.fi>
Date: Tue, 06 Nov 2012 21:01:59 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 15 min
X-Total-Time: 17 min
Subject: [IPsec] Which option to pick on draft-kivinen-ipsecme-oob-pubkey-02.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2012 19:02:05 -0000

My draft draft-kivinen-ipsecme-oob-pubkey-02.txt defines new way to
send any type of raw public keys inside IKEv2. RFC5996 only allows
sending RSA raw public keys. This means after this we would have two
ways to do send RSA raw public keys, old RFC5996 and new format define
din my draft. 

In yesterdays IPsecME meeting I asked following question about what to
do with the Raw RSA Public Key Type:

1) Make this new format completely optional

	Leave old RFC 5996 format as is, both this new format and the
	old format can be used. In that case this document can be
	informational, and it does not need to updated RFC5996.

2) Make this new format recommended, but keep old format

	Leave old RFC 5996 format as is, but make this new format as
	preferred format, i.e. add text which says SHOULD use this new
	format if it is supported, and SHOULD NOT for old format. Old
	format can be used for backward compatibility. In this case
	this document should be standard track, and update RFC5996.

3) Obsolete old format

	Make old RFC 5996 format as MUST NOT, and officially obsolete
	it. This means all implementations should switch to new format
	as soon as possible. This document must be standard track, and
	update RFC5996.

In the discussion we did not found out that there would have been wide
use for the old RFC 5996 defined RSA raw public key, so feeling was
that it would be possible to obsolete the old format. It was
considered a bad idea to keep two ways of doing same thing.

So now I want to know if anybody have anything against if we do just
that, i.e. pick the 3rd option and obsolete the old RSA raw public key

The another question is whether this document needs to be WG document
or not. As it seems to be that we are updating the RFC5996 and
obsoleting stuff from it, there seemed to be some people who felt that
this should be WG document. Send your comments about this too. 

Please send your comments here in the list during the next two weeks
(I will be traveling during the next two weeks, and plan to make
necessary changes (if any) to the draft after I get back to home).