[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