Re: Disposition of the IKEv2 ID_KEY_ID type

["Mohan Parthasarathy" <mohanp@sbcglobal.net>]

> 
> Discussion on this topic has died down, so here is my attempt to try to
> summarize the discussion.   The main concern seems to be due to the
> phrase "an account name" in the following text from the ikev2 draft:
> 
>       ID_KEY_ID                           11
> 
>             An opaque octet stream which may be used to pass an account
>             name or to pass vendor-specific information necessary to do
>             certain proprietary types of identification.
> 
> Specifically, the pandora's box which gets opened once "an account name"
> is added is the dreaded internationalization question.  It seems one
> simple way of addressing this situation is to simply to revert to the
> IKEv1 wording, which would simply involve deleting the phrase "to pass
> an account name or" from the specification.  This would leave ID_KEY_ID
> as being nothing more than a private use field that can be used between
> consenting clients and servers to pass a vendor- or site- specific
> identification.
> 
> If we were to do this, which would make the use of ID_KEY_ID
> unambiguous, it raises the next question: should we create a new
> identity type that contains an account name, with some kind of tight
> specification about the use of UTF-8 or whatever.  Noting that we
> already have support for an X.500 General Name, which does have
> internationalization support in it already, I am going to suggest that
> we do *not* try to define some kind of new account name identity type at
> this time.
> 
> If there is a desire for such a new identity type, it will always be
> possible to define a new type in another RFC.  But given that IKEv2 is
> currently in last call, it doesn't seem like it's the time now to try to
> add new identity types....
> 
> Is this an outcome that most people on the list could live with?
> 
I am fine with this. 

But note that this discussion came out of an issue that was
raised against 2401bis. Steve later clarified that contents of ID_KEY_ID
would be added (clarified) as another selector in 2401bis. Perhaps, you were planning
to summarize under a different subject ?

-mohan

> - Ted