Disposition of the IKEv2 ID_KEY_ID type

["Theodore Ts'o" <tytso@mit.edu>]

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?

						- Ted