[kmf-discuss] kmf_validate_cert changes

[Wyllys Ingersoll]

Jan Pechanec wrote:
> On Thu, 10 Jan 2008, Wyllys Ingersoll wrote:
>
> 	hi Wyllys,
>
> 	thanks for starting that.
>
>   
>> The cert data must be non-null.  If the ocsp_resp data is NULL, then
>> kmf_validate_cert
>> will go fetch an OCSP response as usual (see above).
>>
>> The list of pairs MUST be in order, meaning, the cert at index 0 is the subject
>> cert,
>> the cert at index 1 is the issuer of the one at index 0, etc etc.  The last
>> cert in
>> the list is the trust anchor.
>>     
>
> 	why to mandatorily include the trust anchor? Isn't it explicit that 
> the last certificate in the chain must be validated by the trust anchor if 
> requested so by the policy? And if it can't be from various reasons then the 
> verification failed?
>
> 	example: an app gets certificates and possibly responses. If the 
> policy specifies the anchor, and if the list doesn't end with that trust 
> anchor it's still a list that can be successfully verified if the last 
> certificate was signed by that trust anchor's private key. And the app at 
> least don't have to check whether the anchor is there or not. I would make 
> it optional - if policy has a trusted anchor and the chain doesn't end with 
> it, it will be implicitly added there. Would that be OK?
>   

Yes, that would be OK.   The last cert need not be the TA.  If it is not 
a self-signed cert,
KMF will go look for the TA based on the policy, just as it does today.


>> kmf_set_attr_at_index(attrlist, numattr++, KMF_CERT_RESP_LIST_ATTR, certchain,
>> sizeof (certchain));
>> kmf_set_attr_at_index(attrlist, numattr++, KMF_CERT_RESP_LIST_LEN_ATTR, &len,
>> sizeof (len));
>> ...
>>
>> rv = kmf_validate_cert(handle, numattr, attrlist);
>> ===
>>     
>
> 	I agree. Unfortunately, I got no replies from IETF mailing list 
> where I opened the issue and where I suggested to use cert-response pairs, 
> not two separate lists as specified in the last draft. However, that's not 
> relevant here and I agree that the propose change, including the sorteness 
> of pairs, is a clean and a good one, better than two separate lists.
>
> 	J.
>
>   
OK, hopefully they will respond.  For our purposes, we will specify that 
the list be ordered
and that certs should be paired with their corresponding OCSP response 
whenever possible.

-Wyllys