Jan Pechanec wrote: > On Fri, 14 Dec 2007, Jan Pechanec wrote: > > hi, could you please take a look at this? If there are not enough > loops right now it's ok I just don't want this to get lost. Thanks! J. >
Yes, sorry. We talked about this in our iTeam meeting yesterday. We would like to improve our validation checking to go further along the chain. Full PKIX support is very complex and is not trivial to implement. It involves a lot more than just walking the chain and checking signatures. >> hi, I'm following up one of my previous mails. I mentioned that I >> would like KMF to know how to implement certificate path validation as >> specified by PKIX (RFC 3280). >> >> so, what does it mean? SSH server or client, when it gets the >> client's (or server's, respectively) certificate, it can also send >> certificates that are part of the validation path. Basically, the 1st one is >> the server's/client's one which is mandatory, and the last one is issued by >> the trusted anchor. It's section 6.1 in RFC 3280. >> >> the goal is to verify that certificate n+1 is issuer of certificate >> n, and that all certificates were valid, and that no certificate was >> revoked. I might be able to get away with certificate path of length 1 in an >> initial design since I suspect that most users won't have longer >> certification path, but I don't think I could get away with that for long. >> I think we can walk the chain and verify signatures and issuer/subject names, and do basic CRL/OCSP checking along the way (preferably cached) without too much trouble, we already have the code in place to do it for a simple pair. >> there is one more thing - part of the SSH packet with certificates, >> there are also OCSP responses for a subset of certificates (could be for all >> of them, or for none). My impression is that it's for efficiency, it's >> easier for server to have such responses ready and send them to clients for >> the time period of OSCP response(s) validity so that each client doesn't >> have to contact the responder. >> >> btw, the SSH draft (there is no RFC yet) is here (section 4.1 is the >> section that defines the format of the SSH message): >> >> http://www3.ietf.org/proceedings/06mar/IDs/draft-ietf-secsh-x509-03.txt >> >> do you think there is a way who KMF could be extended so that I >> could call a function similar to kmf_verify_cert() that could get a list of >> certificates that are part of the validation path, possibly with OCSP >> responses that would be used when needed according to the policy? I mean >> that if policy enforces OCSP usage, it would contact the respoder only if >> the OCSP response wasn't given as an input? >> Can you clarify - what are the inputs you would like to pass in and what are the outputs? Caching OCSP responses is difficult because KMF is not a daemon process and keeps very little state information between calls. CRL caching is not as hard because CRLs are already saved as files and so KMF can easily go look to see if that file already exists and if it is still valid before downloading a new one. OCSP is not so easily cached because the OCSP response is generally not kept around on disk after it is used once. -Wyllys
