[Monotone-devel] Do we really need to IDN-encode cert names, keypair ids, and database variable domains?

[Zack Weinberg]

We have a small piece of GNU libidn embedded in monotone, and it
appears that the only thing we use it for is to put a handful of
things in the database in IDN encoding: cert names, keypair ids, and
database variable domains.  [It also gives us a slightly nicer
interface to iconv() but there is no reason we couldn't keep that one
function, or reimplement it ourselves.]  I am wondering if this is
actually necessary -- why not just store them in UTF-8?  As far as I
can tell, nothing actually depends on them being punycoded: the
revision cert names and db_var domains that have meaning to the
program are all pure ASCII, and key IDs are treated as opaque (but
comparable) strings.

There are, however, a couple of potential problems with a conversion.
First, keypair ids and cert names do go over the wire; assuming that a
database exists with one of these in it for which the IDNA
transformation is not a no-op, that's a flag day.  I *think* it's just
a case of having to increment the epoch on any branch carrying certs
whose names or signer ids changed; I don't think we would have to
re-issue those certs.  (Because, as far as I can tell, the signer id
is not part of the data signed.)

Second, part of what IDNA conversion does for us is the "nameprep"
operation, which converts the string to NFKC plus places some other
constraints.  I have argued strenuously for Unicode normalization in
other contexts, but in this case I don't really see it as necessary;
if a hypothetical user tries to refer to their public key by two
different but unified-under-NFKC strings, it just won't work; nothing
terrible will happen.  (I could be wrong.)

Thoughts?  I should emphasise that I'm not suggesting this for the
release Richard wants to make Thursday.  That would be entirely too
risky.  Also, as a data point, neither the Monotone nor the Pidgin
databases contain any strings that would be changed by this proposal.

zw