Project review: policy extensions
nico at cryptonector.com
Tue Jul 24 01:53:26 EDT 2012
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.
More information about the krbdev