Subject: [IPsec] New Version Notification for draft-kivinen-ipsecme-oob-pubkey-01.txt

From: Tero Kivinen <[email-masked]>
Date: Tue, 16 Oct 2012 15:50:48 +0300

I updated the draft-kivinen-ipsecme-oob-pubkey document, the new
version includes some examples in the appendix, including the actual
bits on the wire examples.

One thing that needs to be decided before this document is ready:
"What shall we do with the old "Raw RSA Key" format?"

The current draft keeps it, and RECOMMENDs this new format for all
types of raw keys, and does the negotiation using the standard IKEv2
CERTREQ payloads. This means there is two ways of doing exactly same
thing, i.e. sending Raw RSA keys in IKEv2. 

Another option would be to change this document to be Standard track
document, mark it as Updating 5996, and say that using old "Raw RSA
Key" format is NOT RECOMMENDED. This would mean there is only one way
of sending Raw RSA keys keys in IKEv2, i.e. the new way.

Third option would say that this new format is only used for non-RSA
keys, and for Raw RSA keys, you always MUST use the old format. I do
not like this last option as it would require minimal implementations
to implement both formats, as with both of the above options the
minimal implementation can just decide that it only supports this one
format and uses it for everything.

I would like to get feedback from the WG, which way should we go
forward?

----------------------------------------------------------------------

From: [email-masked]
Subject: New Version Notification for draft-kivinen-ipsecme-oob-pubkey-01.txt
Date: Tue, 16 Oct 2012 05:40:09 -0700

A new version of I-D, draft-kivinen-ipsecme-oob-pubkey-01.txt
has been successfully submitted by Tero Kivinen and posted to the
IETF repository.

Filename:	 draft-kivinen-ipsecme-oob-pubkey
Revision:	 01
Title:		 More Raw Public Keys for IKEv2
Creation date:	 2012-10-16
WG ID:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-kivinen-ipsecme-oob-pubkey-01.txt
Status:          http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey
Htmlized:        http://tools.ietf.org/html/draft-kivinen-ipsecme-oob-pubkey-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-kivinen-ipsecme-oob-pubkey-01

Abstract:
   The Internet Key Exchange Version 2 (IKEv2) protocol currently only
   supports raw RSA keys.  In some environments it is useful to make use
   of other types of public keys, such as those based on Elliptic Curve
   Cryptography.  This documents adds support for other types of raw
   public keys to IKEv2.
-- 
[email-masked]

---

From: Sean Turner <[email-masked]>
Date: Thu, 18 Oct 2012 13:36:14 -0400

Tero,

Gotta ask: Should this draft update RFC 5996?  On the one hand, it's 
optional and existing implementations don't need to support it.  On the 
other hand, if you're really trying to deprecate the old RSA raw key 
format shouldn't it update the base doc?

Could add an informative reference to RFC 5480 in App A for the 04 byte 
to indicate it's uncompressed.  But, it's not absolutely necessary.

spt

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 19 Oct 2012 13:50:02 +0300

> format shouldn't it update the base doc?

If we want to deprecate the old raw RSA keys, then I think this
document needs to be standard track, and it needs to update RFC 5996.
If we just add new format for raw public keys, and both old raw RSA
certificate format and this new format then I think it can be
informational and there is no need for this document to "Update" the
RFC5996. Our previous additions to the IKEv2 have not updated the base
spec (redirect, resumption, IPv6 address configuration, password
authentication, high availability, childless etc). The EAP only
authentication do update RFC5996.

So the answer really depends on which way the WG wants this document
to go...

> to indicate it's uncompressed.  But, it's not absolutely necessary.

Done.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 19 Oct 2012 15:47:44 +0200

Personally, I think it would be less confusing for everyone involved if 
this document is Standards Track (and "updates 5996").

Whether we deprecate the old format depends IMO on the level of 
implementation/use of the old format. I would like to hear from people 
who care about the old format (i.e. who have it in products, and do not 
intend to move quickly to the more general solution if it is 
standardized). If we don't hear any screams, then I definitely support 
deprecating it.

Thanks,
     Yaron

---

From: Paul Wouters <[email-masked]>
Date: Sun, 21 Oct 2012 12:05:18 -0400 (EDT)

On Fri, 19 Oct 2012, Yaron Sheffer wrote:

> Personally, I think it would be less confusing for everyone involved if this 
> document is Standards Track (and "updates 5996").

Sure.

> implementation/use of the old format. I would like to hear from people who 
> care about the old format (i.e. who have it in products, and do not intend to 
> move quickly to the more general solution if it is standardized). If we don't 
> hear any screams, then I definitely support deprecating it.

Fine with me,

Paul