Project review: policy extensions

[Nico Williams]

On Mon, Jul 23, 2012 at 10:48 PM, Greg Hudson <ghudson at mit.edu> wrote:
> Here are two thing I have noticed and discussed with Nico about his
> work, which other people might have opinions on:
>
> * There is no first-class field for policy string attributes, which
> means when they get implemented, they will get layered on top of tl-data
> just like they are in principal entries.  Nico's reasoning is that we
> already have the code written to do that layering, so it's better to
> reuse than code than to create marshalling code for a first-class field.

One bad side-effect of this is that the total sum of key/value strings
for policies must be limited to 32KB, just as with principals.  If we
ever need to we can... burn this API in a big pyre and build a new
one, or perhaps continue with the barnacle accumulation approach and
just add fragmentation for TL data.

> * The new keygen_enctypes field, which is conceptually a key-salt tuple,
> is represented in the policy structure as a string (in
> krb5_string_to_keysalts format).  That's also how it's represented on
> the wire, in both KDB back ends, and in the dump file.  Nico's reasoning
> is that this involves less marshalling code than it would take it if
> were represented as an array of krb5_key_salt_tuple.

Yes.  I don't want to add more code than I have to.  To some extent
I'm removing code because of refactoring -- a good thing, IMO.  Here
we already have library functions for marshalling/unmarshalling
key/salt tuples, and it seems perfectly reasonable to want to reuse it
:)

On a side note, Greg and I agreed off-list to rename this field from
keygen_enctypes to allowed_keysalts.

Nico
--