Re: libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)

2012-01-25 Thread Sean Leonard
I ended up writing a lot of text in response to this post, so, I am breaking up the response into three mini-responses. Part I On 1/18/2012 4:23 PM, Brian Smith wrote: Sean Leonard wrote: The most glaring problem however is that when validation fails, such as in the case of a revoked

Re: libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)

2012-01-25 Thread Sean Leonard
Part II On 1/18/2012 4:23 PM, Brian Smith wrote: Sean Leonard wrote: and no log information. Firefox has also been bitten by this and this is one of the things blocking the switch to libpkix as the default mechanism in Firefox. However, sometime soon I may just propose that we change to

Re: libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)

2012-01-25 Thread Sean Leonard
Part III On 1/18/2012 4:23 PM, Brian Smith wrote: Sean Leonard wrote: We do not currently use HTTP or LDAP certificate stores with respect to libpkix/the functionality that is exposed by CERT_PKIXVerifyCert. That being said, it is conceivable that others could use this feature, and we

Re: libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)

2012-01-25 Thread Ryan Sleevi
Sean, The Path Building logic/requirements/concerned you described is best described within RFC 4158, which has been mentioned previously. As Brian mentioned in the past, this was 'lumped in' with the description of RFC 5280, but it's really its own thing. libpkix reflects the union of RFC

Re: libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)

2012-01-25 Thread Sean Leonard
Ryan, I agree; while I did not mention RFC 4158, it is a good reference. I echo your hope that someday, CERT_PKIXVerifyCert/libpkix will provide additional diagnostic information. Some of my own observations: - while a scoring method is useful (and certainly, an objective method is best),

Re: libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)

2012-01-18 Thread Brian Smith
Sean Leonard wrote: The most glaring problem however is that when validation fails, such as in the case of a revoked certificate, the API returns no certificate chains My understanding is that when you are doing certificate path building, and you have to account for multiple possibilities

Re: libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)

2012-01-13 Thread Gervase Markham
On 13/01/12 00:01, Brian Smith wrote: Ryan seems to be a great addition to the team. Welcome, Ryan! Ryan - could you take a moment to introduce yourself? (Apologies if I missed an earlier introduction.) * We will drop the idea of supporting non-NSS certificate library APIs, and we

RE: libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)

2012-01-13 Thread Stephen Hanna
Let me just jump in and say that I'm also glad to see libpkix being used and useful. I was the leader of the team at Sun Labs that created libpkix (and the Java CertPath libraries before them). Actually, it's an exaggeration to say we created libpkix. We started the work on it and then it took

libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)

2012-01-12 Thread Brian Smith
We (me, Kai, Bob, Wan-Teh, Ryan, Elio, Kai) had a meeting today to discuss the issues raised in this thread. We came to the following conclusions: Ryan seems to be a great addition to the team. Welcome, Ryan! Gecko (Firefox and Thunderbird) will make the switch to libpkix. See Ryan's comments