[17177] in Kerberos_V5_Development
Re: String attributes feature (project review)
daemon@ATHENA.MIT.EDU (Simo Sorce)
Tue Sep 20 11:17:52 2011
From: Simo Sorce <simo@redhat.com>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <CAK3OfOixe7Ux07uk4OTf34rBrV7uVRt5isD9fAakqf_McSaHbg@mail.gmail.com>
Date: Tue, 20 Sep 2011 11:17:46 -0400
Message-ID: <1316531866.2684.523.camel@willson.li.ssimo.org>
Mime-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Tue, 2011-09-20 at 09:28 -0500, Nico Williams wrote:
> I believe that building an extension data keyed by text feature over
> TL data is a great idea.
>
> I'm less sure about the idea that the data must be text as well, but
> it's certainly most expedient. The alternative would be to make
> kadmin pluggable, but that'd also mean distributing plugins to the
> kadmin clients...
>
> A few comments:
>
> a) the key should be all US-ASCII;
What's the point of limiting it to US-ASCII when UTF-8 is a standard and
allows proper internationalization ?
> b) the key namespace needs more guidance/definition (e.g.,
> feature@domainname, a la SSHv2);
I would say that a vendor prefix makes for a better name space (and let
displaying code to more easily order alphabetically and get all vendor
related keys together with ease).
Something like:
mit_otp_name = value
rh_otp_name = value
rsa_otp_name = value
etc...
> c) should any type information be included for the data part?
type is "string" so far ?
> d) how should binary data be encoded for storage as text data? There
> are many options, but it'd be nice if there was a single common
> recommendation (e.g., base64) and utility functions for it.
Yes, I agree we should recommend base64 in case someone needs to store
arbitrary data that is not valid utf-8
Simo.
--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
