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 off. Lots of other people have worked on it since then, probably putting in many more hours than we did in creating it.
I'm mainly a lurker on this list since I don't do much with PKI any more. I moved on to a new job more than seven years ago, working on security integration standards like TNC and NEA. But if I can help answer an occasional question, I'd be glad to do that. I'm having lunch today with Yassir Elley, who did most of the coding for the first version of libpkix. He works on the same team as I do now, at Juniper. We'll mull over this question and see if we can recall why we included those layers of abstraction APIs. I suspect it was because we wanted this to be a PKIX-compliant library that could be used by any project for any purpose in any environment. That's also why it ended up being a bit bloated. Maybe you could say it was a bit of a "second system effect", following CertPath as it did. I apologize for whatever weaknesses we put into libpkix but I'm glad to see that it's useful. Feel free to adapt it as you see fit. Thanks, Steve Hanna > -----Original Message----- > From: dev-tech-crypto-bounces+shanna=funk....@lists.mozilla.org > [mailto:dev-tech-crypto-bounces+shanna=funk....@lists.mozilla.org] On > Behalf Of Gervase Markham > Sent: Friday, January 13, 2012 6:01 AM > To: mozilla-dev-tech-cry...@lists.mozilla.org > Cc: Brian Smith > Subject: Re: libpkix maintenance plan (was Re: What exactly are the > benefits of libpkix over the old certificate path validation library?) > > 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 will remove the abstraction layers > > over NSS's certhigh library. That means dropping the idea > > of using libpkix in OpenSSL or in any OS kernel, for > > example. > > For my info: has anyone ever expressed interest in doing that, or did > it > just seem like a useful capability to have in case someone needed it? > > Thanks for this summary - it's great to hear that the NSS team are of > one mind :-)) > > Gerv > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
