[kmf-discuss] PROPOSAL: certificate to name mapping

[Jan Pechanec]

On Fri, 22 Feb 2008, Wyllys Ingersoll wrote:

>> 	we should probably even omit "yes"/"no" part completely. In the policy
>> file, it would be like this, for example:
>>
>> <cert-to-name-mapping
>> 	mapper-name="email" 	mapper-cfg="ignorecase,ignoredomain">
>>  
>
> Just to be clear - this  new "cert-to-name-mapping" configuration info would be
> attached to
> a policy and defined in the kmfpolicy.xml file?  This implies that we also have
> to update
> kmfcfg to support adding this to a policy. 

	exactly. I think that applications will be configured through the 
policy files only by the administrator, or as in SunSSH example, they will 
be allowed to provide a policy file. It would be very convenient if all the 
info were in the policy database.

> The mapper-cfg value will have to be pretty wide-open, though we should limit
> it to
> a fixed set of characters and a max size (256 characters?).    The consumer of
> the mapper-cfg
> will be the mapper itself, so we cannot really know what will be put there
> aside from our what our own modules will require.

	that's what I'm thinking. I was thinking that we could have a fixed 
set of words but there will always be a mapper that would need another one. 
So, I guess we would end up with 3rd party mappers overloading existing 
words with different meaning. Let this string be opaque to KMF aside from a 
defined char set and length.

>> 	every mapper could (I hope) provide just one function, that would be
>> used from this KMF API call:
>>
>> 	kmf_map_cert_to_name(KMF_HANDLE_T, KMF_DATA *cert);
>>  
>
> What about the reverse - should the mapper also provide a way to find
> all of the certs for a particular user?  I guess one could construct
> that function in KMF by just calling kmf_map_cert_to_name for each
> cert returned by "kmf_find_cert" and matching to the desired name, so
> maybe the mapper doesn't need to provide this.

	hmm, I can't see a real situation where I would need that. Did you 
have such a situation in mind? If not, I would rather suggest not to have 
this function until it is needed.

> The name object returned should probably be a generic KMF_DATA block
> and not just a single "char *".  I can envision a mapper that
> returns some sort of structure of data (struct passwd, for example)
> instead of just a single name string.

	this is a good point. Since the mapper can put NUL terminated string 
there the caller can directly work with Data so yes, that's a good idea.

> I think it sounds reasonable so far, we need to think about the details. 

	I will send more detailed version on Monday so that we can discuss 
further.

> Also, what mappers would we provide initially?

	I'll go through the previous discussions and suggest a set of 
mappers and their interfaces.

	J.

-- 
Jan Pechanec