[Freeipa-devel] Re: Encoding of Kerberos principal

[Simo Sorce]

On Wed, 2009-07-08 at 10:35 -0400, Don Davis wrote:
> 
> unfortunately, the kerberos spec relies heavily on the ASN.1 spec, 
> which was & is screwed-up on the subject of i8n, just as ASN.1 is 
> screwed up in other ways.  if you need a more-precise/standard
> answer, 
> i'd suggest you read:
>   * pp.52-54 of rfc4120:  http://www.ietf.org/rfc/rfc4120.txt
>   * skim the wikipedia description of iso-2022, which is the
>     legacy i8n mechanism, predating unicode & utf8, that krb
>     implementations are supposed to support correctly:
>     http://en.wikipedia.org/wiki/ISO/IEC_2022
>   * skim iso-8859 (iso latin), too.  this is the modern standard
>     for most of the commercially-important alphabetic languages
>     (but not asia), and it's arguably what you wish krb would 
>     support well:  http://en.wikipedia.org/wiki/ISO/IEC_8859
> 
> for interoperability, there's no substitute for testing.  further, 
> i think we need to decide early which foreign character-sets we 
> can put off worrying about, based on which languages our paying 
> customers use.  the prioritized list i've used elsewhere is:
>    Europe > Japan > Korea > China > Russia > India > Middle East,
> but redhat's customer-base is probably different.

I think the best course of action, at the moment, is to consider using
only utf-8 when we generate something and treat as blobs names coming
from outside the framework (with getters that tentatively try to return
a Unicode string).

Using anything but utf-8 is doomed to fail in spectacular ways.

If during testing we will find some other consistent pattern we will try
to find a fix for the specific case assuming it is detectable or will
recommend the user to fix whatever is using absurd encodings.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York