Project review: policy extensions

Greg Hudson ghudson at MIT.EDU
Mon Jul 23 23:48:20 EDT 2012


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.

* 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.


More information about the krbdev mailing list