Subject: pkinit and internationalization

From: Sam Hartman <[email-masked]>
Date: Fri, 11 Oct 2002 23:55:15 -0400

Hi.  As we start looking at documents to last-call, I'd like to make
sure we don't produce protocols that work with clarifications but
require revisions for extensions.

In general, I believe that anything we release that references
clarifications should be something we expect to continue to work under
extensions as well.  unfortunately, that means we do need to consider
some extensions issues--especially internationalization--as we last
call documents now.

I suspect that pkinit will be easy to deal with.  I think what we want
to have happen is for implementations of clarifications to send utf8
strings restricted to the ia5string character set.  In practice some
people including Microsoft will actually send non-normalized utf8 and
have the same advantages and disadvantages as they have sending utf8
with Kerberos.

Then, when people start moving towards extensions, everyone sends utf8
using the same normalization rules as Kerberos.

Really none of that should require a protocol change between
extensions and clarifications; just send the same kinds of strings
your Kerberos implementation sends and all will be well.  Since pkinit
lives within normal KDC requests, you should even get interop with old
clients/kdcs for free in an extensions world.

But I'm a bit concerned about how we explain this is what we want to
have happen.  Presumably the pkinit authors want their draft to be
last-called soon, not to have to add a reference to the stringprep
profile and wait on that document. I don't know how to make the text
be clear that you should do the same string processing as Kerberos
currently requires.  This is particularly difficult because we cannot
refer to the current version of Kerberos only an explicit version.

But also we should make sure there are not any issues that will
prevent this approach from working.

It would be useful if pkinit authors could read both of Jeff Altman's
internationalization drafts (the stringprep profile and
info-gen-ascii) and be prepared to discuss the following issues:

1) Are there  any strings we cannot normalize?  An example of this
   would be a hash of a string provided in some cert or other object
   that did not also provide the string.  This issue would mostly come
   up with keys entered directly by users.  I believe the answer is
   that there are no such strings in pkinit but it's important to make
   sure  because we have a lot of work if there are.

2)  Are there cases where we're going to have to give
    explicit instructions   about normalization?  For example are
    there any strings  from non-Kerberos entities that cannot be
    normalized because they are in signed data, but instead must be
    normalized both by the client and KDC?  I suspect yes there are
    several of these in certs.

3) Are there any strings that should not be normalized?  I can't think
   of any such  but there might be copies of items from certs where
   having the string be bit-for-bit identical is more important than
   normalization.

4)  Are there any strings that are stored in the database?
    Identifying these strings will matter because the handling of
    unspecified codepoints is different for stored strings than for
    query strings.