[kmf-discuss] kmf_validate_cert changes

[Jan Pechanec]

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?

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

-- 
Jan Pechanec