Currently we require every principal entry in the KDB to have at least 
one long-term key, and we always offer encrypted timestamp or challenge 
as one of the choices for preauthentication.  This is suboptimal if the 
principal should only be allowed to preauthenticate with PKINIT or some 
other mechanism which does not involve the long-term key.

The administrator can, of course, give the principal one or more random 
keys, which means encrypted timestamp or challenge won't work.  But 
lying to the client this way makes it difficult to present good 
diagnostics about configuration issues with PKINIT.  The client tries 
PKINIT first and sees an error, but thinks it should also try encrypted 
timestamp or challenge instead of failing out.

This problem could be solved in two ways.  We could make it possible for 
a principal to have zero long-term keys, and only offer encrypted 
timestamp or challenge if the principal has keys.  This would be an 
architectural challenge, requiring analysis of each part of our code 
which interacts with key data.

Alternatively, we could give administrative control over which 
preauthentication mechanisms are allowed for each principal.