[kmf-discuss] proposal - new kmf_policy attribute

Wyllys Ingersoll wyllys.ingersoll at sun.com
Fri Feb 1 05:03:03 PST 2008


Jan Pechanec wrote:
> On Thu, 31 Jan 2008, Hai-May Chao wrote:
>
>   
>> This looks good to me. I just have some comments.
>>
>> As TA certificate is used by kmf_validate_cert() API,
>> with the additional TA location parameter in the KMF policy,
>> will that impose changes to be made to kmf_validate_cert()
>> API? Will the TA location in the policy override the
>> existing related attributes in kmf_validate_cert() API?
>>     
>
> 	hi Hai-May, I would agree with that. I can imagine that one may want 
> to copy the policy file and that the only thing that is different on the 
> other system could be the location of the TA certificate.
>
> 	so, how I see it those attributes could be optional if already 
> specified in the policy file, mandatory (for respective keystore types) if 
> not present in policy file, and if present in the kmf_validate_cert() then 
> always overriding the policy setting.
>   

I agree, parameters to kmf_validate_cert take precedance over the policy.

>
>   
>>               [crl-basefilename=basefilename]
>>               [crl-directory=directory]
>>
>> This also may help to be more aligned with the two KMF
>> attributes that kmf_validate_cert() uses:
>> KMF_DIRPATH_ATTR and KMF_SUBJECT_NAME_ATTR.
>>     
>
> 	I would also agree here. It's better if a user don't have to 
> remember the differences for particular functions.
>   

I think that 'crl-basefilename' and 'crl-directory' should just be 
condensed into
a single 'crl-pathname' which requires a fully qualified path.  I 
dislike having
to enter the directory and the filename separately, I wish we had not 
done that
in the first place.

I could do that for all of the policy items that refer to dir/file to be 
consistent.

-Wyllys



More information about the kmf-discuss mailing list