Re: choosing principal names

Harry Coin <[email protected]>
Newsgroups gmane.comp.encryption.kerberos.heimdal.general
Message-ID <[email protected]>
On 10/5/2011 1:28 PM, Nico Williams wrote:
> On Wed, Oct 5, 2011 at 1:11 PM, Harry Coin<[email protected]>  wrote:
>> On 10/5/2011 12:56 PM, Nico Williams wrote:
>>> On Wed, Oct 5, 2011 at 11:55 AM, Love Hörnquist Åstrand<[email protected]>
>>>   wrote:
>>>> I think there should be very little kerberos programmers, there should be
>>>> more gss programmers.
>>> +1
>> Hear the sound of the can getting kicked down the road.    It is this group
>> that defines the concept 'principal', it is this group that has written into
>> its libraries uid sensitive default filenames, it is this group that has a
>> toe in the water of every OS pond.
> Absolutely an incorrect conclusion on your part.  The GSS-API
> specifically addresses standard naming conventions.
>
> Nico
> --
>
Thanks for that work in your RFC, helpful to gssapi.   Helpful if 
kerberos has no scope outside gssapi and they are to be thought of as a 
unit and maintained together.

What's a good idea for a system mount nfs client's principal name?  
Root?  Host?  The name of the package calling mount running as root?  
What if the package is itself a net service?    Is root to be understood 
as a person with uid:0 and host meaning 'whatever daemons we haven't 
gotten around to giving their own names'?

What's the suggested principal name format an application developer 
should deploy in a package with a client side and multi-homed server 
side that doesn't use gssapi-- that must coexist nicely with systems 
that do?

Note Rune and others admonish having name space collisions = bad.  It 
would do well to offer guidance along the lines aforementioned because 
not all application, daemon and api users read everything about what all 
their peers are planning.

Not imposed or enshrined in code, but guidance.

Cheers!
Harry
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.