RE: libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)
Wan-Teh wrote: > Yes, that was the reason for the portability layer > (which uses the pkix_pl prefix in the source code). > One of the intended customers was the IPsec code > in the kernel, so the main libpkix library did not > even depend on the Standard C Library. > > Each environment would need its portability layer > for libpkix, for example, pkix_pl_nss, pkix_pl_openssl, > pkix_pl_kernel/ipsec. Only pkix_pl_nss was implemented. Yeah, that's what Yassir said also. He thought it was pretty funny that you're going to get rid of the HTTP certstore and non-blocking I/O. Apparently, we only put those in at the request of the NSS team! I guess requirements have a way of changing over the years... I have cc'd Yassir on this email so that you can have his latest email address. With his permission! Thanks, Steve > -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 Wan-Teh Chang > Sent: Friday, January 13, 2012 11:01 AM > To: mozilla's crypto code discussion list > Subject: Re: libpkix maintenance plan (was Re: What exactly are the > benefits of libpkix over the old certificate path validation library?) > > On Fri, Jan 13, 2012 at 7:38 AM, Stephen Hanna > wrote: > > 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. > > Hi Steve, > > Yes, that was the reason for the portability layer > (which uses the pkix_pl prefix in the source code). > One of the intended customers was the IPsec code > in the kernel, so the main libpkix library did not > even depend on the Standard C Library. > > Each environment would need its portability layer > for libpkix, for example, pkix_pl_nss, pkix_pl_openssl, > pkix_pl_kernel/ipsec. Only pkix_pl_nss was implemented. > > Wan-Teh > -- > 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
RE: libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)
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
RE: Path building in Thunderbird
Yes, that's exactly right. Sorry that I wasn't clear. I have a friend who's receiving signed emails from various people but he can't verify the signatures in Thunderbird because the certificate chain in the message doesn't quite reach back to any of his trust anchors. The missing certs are available online and could be fetched with AIA to build a complete path from his trust anchors to the signing certificate but Thunderbird doesn't seem to do that (which I call "path building"). I think libpkix was integrated into NSS 3.12 and path building is (or at least was) a feature of libpkix. Of course, integrating libpkix doesn't mean that every libpkix feature is enabled in NSS. And enabling those features in Thunderbird is another step beyond. I just figured that I would ask if there's some hidden configuration setting to enable path building or something. Thanks, Steve > -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 Nelson B Bolyard > Sent: Friday, February 18, 2011 1:38 PM > To: mozilla's crypto code discussion list > Subject: Re: Path building in Thunderbird > > On 2011-02-18 10:22 PDT, Wan-Teh Chang wrote: > > On Thu, Feb 17, 2011 at 7:10 AM, Stephen Hanna > wrote: > >> Does Thunderbird support certification path building? If so, how > >> is it enabled and configured? > > > > Hi Steve, > > > > I am confused by your question. An S/MIME client obviously must > > support certification path building by default. Did I miss > something? > > Wan-Teh, I suspect Steve is referring to active building of paths by > fetching missing certs from URIs in certs' AIA extensions. > > Steve, Have I surmised correctly? > > -- > /Nelson Bolyard > -- > 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
Path building in Thunderbird
Does Thunderbird support certification path building? If so, how is it enabled and configured? Thanks, Steve Hanna -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
