[kmf-discuss] PROPOSAL: certificate to name mapping

[Jan Pechanec]

	hi, I put together some thoughts on the mapping stuff we discussed 
some time ago. I think we have 2 issues to solve - interface to KMF and what 
mappers to provide. I would like to suggest the interface to KMF now.

	I think that the mechanism should be pluggable. We don't know what 
mappings might be needed in specific scenarios so why not to give our users 
the freedom to write their own (instead of saying "no, we won't consider 
this mapping, you are out of luck" we can say "sorry, we won't ship but you 
are free to write your own"). And what is important from KMF point of view 
it would be significantly simpler. We would ship basic mappers for now, and 
possibly more in the future.

	I'm using "name", not "username", because certificate mapping would 
be also used for cert to hostname mapping, for example. Now the API - the 
1st function would be optional:

	kmf_map_cert_to_name_init(KMF_HANDLE_T, KMF_ATTRIBUTE *);

	- for initializing the mapping if the mapping is not defined in the 
policy file or if we want to override. It would dlopen() the mapper module. 
Attributes:

		- mapper name (would look for, say, kmf_mapper_<name>.so)
		- directory (if .so not in, say, /etc/security/kmf)
		- full mapper path (if one want to use, say, /tmp/xxx.so)
		- mapper specific configuration in a string, see below.

	about mapper configuration - we can hardly come up with the complete 
set of various keywords that could be individually set using kmfcfg(1). By 
keyword I mean "ignorecase", "ignoredomain", "mapperfile", etc. So, why not 
to use one attribute that would cover the configuration? The value of 
mapper-cfg would be specific to the module, while common keywords would be 
expectable:

	mapper-cfg="ignorecase=yes,ignoredomain=yes,debug=yes"

	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">

	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);

	this would use the mapping set by kmf_map_cert_to_name_init() or 
default mapping from the policy file. Otherwise, the function would fail.


	the mapper function itself could be using KMF calls but would not 
read the policy at all; it would get all needed data through function 
arguments. Remember we could be overriding the policy settings.

	if this would be OK, we could specify what mappers we would want to 
ship with it. We could even use pkcs11_pam stuff for now, it would be opaque 
to the user. I think that usually mapper-cfg wouldn't be used at all if we 
provide reasonable defaults (ignorecase for most of the mappers, for 
example, so "dontignorecase" would be acceptable by the module). Also, I 
would prefer more simpler mapper modules than few complex ones.

	what do you think?

	J.

-- 
Jan Pechanec