Extensible kadm5 policies

[Nico Williams]

The kadm5 API has two principal data structures by which to represent
objects in the KDB: principal entries, and policies.  Principal
entries are extensible via the TL_DATA typed-hole.  Policy entries are
not at all extensible, not in the API.

We need policy extensions for a variety of purposes:

 - to specify allowed enctypes for long-term keys (for change
password/keys operations)
 - to specify allowed enctypes independently of what long-term keys
the principal has
(these two can probably be combined)

 - to specify allowed session key enctypes (because even if a
principal is not allowed to have weak long-term keys, there may be
services they have to access that don't support strong enctypes)

The above are of immediate interest to me, but there's more:

 - some principal attributes, such as whether a principal is allowed
to be a service, should come from policies

 - for an imaginary self-service PKINIT enrollment or key rollover
protocol we might need policy on allowable key algorithms and
certificate naming, validation path, ...

There's probably others that I'm not thinking of right now.

In July I negotiated an extensible policy proposal with Love for
Heimdal.  The same exact proposal should apply to MIT (since the two
projects use the same kadm5 API and Heimdal supports large parts of
the kadm5 RPC protocol on the server side).  The proposal is as
follows:

1) Treat policies as principals named with a well-known naming
convention to avoid collisions;
2) Map all policy elements onto exiting principal elements or else add
new TL DATA for them;
3) Allow a policy name (in kadm5) of "policy1,policy2" to mean that
both "policy1" and "policy2" apply in that order;
4) Deprecate kadm5_policy_ent_t;
5) Replace kadm5_policy_ent_t with an extensible variant;
6) Add new kadm5 functions that would be, effectively wrappers around
kadm5_create/modify/get/delete_principal() by which to deal with
extended policies.

Of the above points only (1) and (2) are truly necessary; (5) and (6)
are sugar, while (3) would just be nice, and (4) goes without saying.

Nico
--