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

Tero Kivinen <kivinen@iki.fi> Thu, 29 November 2012 13:51 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F7321F89E5 for <ipsec@ietfa.amsl.com>; Thu, 29 Nov 2012 05:51:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WszYgHZjtB3L for <ipsec@ietfa.amsl.com>; Thu, 29 Nov 2012 05:51:36 -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 A394B21F89A7 for <ipsec@ietf.org>; Thu, 29 Nov 2012 05:51:34 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qATDpQ5x014968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2012 15:51:26 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qATDpNeo025637; Thu, 29 Nov 2012 15:51:23 +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: <20663.26715.668188.141385@fireball.kivinen.iki.fi>
Date: Thu, 29 Nov 2012 15:51:23 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
In-Reply-To: <20633.24231.244628.939482@fireball.kivinen.iki.fi>
References: <20633.24231.244628.939482@fireball.kivinen.iki.fi>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 14 min
X-Total-Time: 50 min
Cc: Sean Turner <turners@ieca.com>
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: Thu, 29 Nov 2012 13:51:37 -0000

Tero Kivinen writes:
> 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. 
> 
> 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
> format.

As there as not been any objections to this change, I will change my
draft to say that RFC 5996 format is MUST NOT, and obsolete the old
RSA public key format. The new draft is already posted as
draft-kivinen-ipsecme-oob-pubkey-03.txt.

http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey/

Diff:

http://www.ietf.org/rfcdiff?url1=draft-kivinen-ipsecme-oob-pubkey-02&difftype=--html&submit=Go!&url2=draft-kivinen-ipsecme-oob-pubkey-03

> 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. 

Only comment to this in the list was from Michael supporting of making
this to WG document (especially if it can fit to charter).

Yaron said in the meeting that he was unhappy this being individual
since it obsoletes old format.

So now we need a comment from the ADs and/or chairs whether they feel
that this fits our current charter (maintain the IPsec standard and to
facilitate discussion of clarifications, improvements, and extensions
to IPsec, mostly to IKEv2) or do we need to update the charter.

I have feeling that as this updates RFC5996 we should modify the
charter, and accept this as WG item, but that will add some delay, as
I think this document should be ready now, and as we are obsoleting
things it best to get this out as soon as possible... On the other
hand it might be faster to do charter update, than wait for anybody in
the list to say anything about this issue :-)
-- 
kivinen@iki.fi