[Freeipa-devel] Re: Encoding of Kerberos principal
Simo Sorce
ssorce at redhat.com
Wed Jul 8 14:48:21 UTC 2009
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
More information about the Freeipa-devel
mailing list