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

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

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

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 ce

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-18 Thread Sean Leonard
Hi All, I'm the lead developer of Gmail S/MIME, and its successor, Penango, which is bringing /end-to-end/ cross-platform S/MIME secure e-mail to webmail and web-based messaging everywhere. It seems that this thread has brought out its fair share or lurkers so I thought I would add some persp

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

2012-01-13 Thread Julien Pierre
Steve, On 1/13/2012 10:46, Stephen Hanna wrote: 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 changi

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

2012-01-13 Thread Ryan Sleevi
> 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.) Sure Gerv. Don't worry, there were no missed introductions, though I have been l

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

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

2012-01-13 Thread Wan-Teh Chang
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 l

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
h-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 main

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

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 a

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-05 Thread Jean-Marc Desperrier
Robert Relyea a écrit : On 01/04/2012 05:56 PM, Brian Smith wrote: > Robert Relyea wrote: >> On 01/04/2012 04:18 PM, Brian Smith wrote: >> In the cases where you fetch the intermediates, the old code will not >> work! [...] I'm talking about fetching intermediates themselves because they

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-05 Thread Brian Smith
Jean-Marc Desperrier wrote: > Brian Smith a écrit : > > 3. libpkix can enforce certificate policies (e.g. requiring EV > > policy OIDs). Can the non-libpkix validation? > > EV policy have been defined in a way that means they could be > supported by a code that handles an extremely tiny part of al

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-05 Thread Ryan Sleevi
> On 01/04/2012 03:51 PM, Brian Smith wrote: > > Ryan Sleevi wrote: > >> IIRC, libpkix is an RFC 3280 and RFC 4158 conforming implementation, > >> while non-libpkix is not. That isn't to say the primitives don't exist > >> - > >> they do, and libpkix uses them - but that the non-libpkix path doesn

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-05 Thread Ryan Sleevi
(resending from the correct address) > On 01/04/2012 03:51 PM, Brian Smith wrote: > > Ryan Sleevi wrote: > >> IIRC, libpkix is an RFC 3280 and RFC 4158 conforming implementation, > >> while non-libpkix is not. That isn't to say the primitives don't exist > >> - > >> they do, and libpkix uses them

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-05 Thread Ryan Sleevi
> Brian Smith a écrit : > > 3. libpkix can enforce certificate policies (e.g. requiring EV policy > > OIDs). Can the non-libpkix validation? > > EV policy have been defined in a way that means they could be supported > by a code that handles an extremely tiny part of all what's possible > with

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-05 Thread Jean-Marc Desperrier
Brian Smith a écrit : 3. libpkix can enforce certificate policies (e.g. requiring EV policy OIDs). Can the non-libpkix validation? EV policy have been defined in a way that means they could be supported by a code that handles an extremely tiny part of all what's possible with RFC5280 certific

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-05 Thread Jean-Marc Desperrier
Robert Relyea a écrit : 7. libpkix can actually fetch CRL's on the fly. The old code can only use CRL's that have been manually downloaded. We have hacks in PSM to periodically load CRL's, which work for certain enterprises, but not with the internet. PSM's periodic CRL download's certainly qui

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-05 Thread Robert Relyea
On 01/04/2012 05:56 PM, Brian Smith wrote: > Robert Relyea wrote: >> On 01/04/2012 04:18 PM, Brian Smith wrote: >> Are you actually fetching intermediates? >> >> In the cases where you fetch the intermediates, the old code will not >> work! We don't fetch the intermediate if we already have it, or

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-04 Thread Wan-Teh Chang
On Wed, Jan 4, 2012 at 3:51 PM, Brian Smith wrote: > > But, it is a little distressing that Google Chrome seems to avoid libpkix > whenever possible, ... This is not true. In fact, Google Chrome is an early adopter of libpkix, and works very hard to fix or work around the bugs in libpkix. (Goog

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-04 Thread Brian Smith
Robert Relyea wrote: > On 01/04/2012 04:18 PM, Brian Smith wrote: > Are you actually fetching intermediates? > > In the cases where you fetch the intermediates, the old code will not > work! We don't fetch the intermediate if we already have it, or it's > already sent in the SSL chain. > > If you

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-04 Thread Robert Relyea
On 01/04/2012 04:18 PM, Brian Smith wrote: > Brian Smith wrote: >> Robert Relyea wrote: >> When I browse with libpkix enabled (which also enables the >> intermediate fetching), connecting to HTTPS websites (like >> mail.mozilla.com) > ... is much slower, at least when the browser starts up. We may

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-04 Thread Robert Relyea
On 01/04/2012 03:51 PM, Brian Smith wrote: > I am concerned that the libpkix code is hard to maintain and that > there are very few people available to maintain it. If we have a group > of people who are committed to making it work, then Mozilla relying on > libpkix is probably workable. But, it is

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-04 Thread Robert Relyea
On 01/04/2012 03:51 PM, Brian Smith wrote: > Ryan Sleevi wrote: >> IIRC, libpkix is an RFC 3280 and RFC 4158 conforming implementation, >> while non-libpkix is not. That isn't to say the primitives don't exist - >> they do, and libpkix uses them - but that the non-libpkix path doesn't use >> them p

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-04 Thread Brian Smith
Brian Smith wrote: > Robert Relyea wrote: > When I browse with libpkix enabled (which also enables the > intermediate fetching), connecting to HTTPS websites (like > mail.mozilla.com) ... is much slower, at least when the browser starts up. We may be able to fix this with persistent caching of in

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-04 Thread Brian Smith
Robert Relyea wrote: > 7. libpkix can actually fetch CRL's on the fly. The old code can only > use CRL's that have been manually downloaded. We have hacks in PSM to > periodically load CRL's, which work for certain enterprises, but not > with the internet. I am not too concerned with the fetching

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-04 Thread Brian Smith
Gervase Markham wrote: > On 04/01/12 00:59, Brian Smith wrote: > > 5. libpkix has better AIA/CRL fetching: 5.a. libpkix can fetch > > revocation information for every cert in a chain. The non-libpkix > > validation cannot (right?). 5.b. libpkix can (in theory) fetch > > using > > LDAP in addition t

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-04 Thread Brian Smith
Ryan Sleevi wrote: > IIRC, libpkix is an RFC 3280 and RFC 4158 conforming implementation, > while non-libpkix is not. That isn't to say the primitives don't exist - > they do, and libpkix uses them - but that the non-libpkix path doesn't use > them presently, and some may be non-trivial work to imp

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-04 Thread Robert Relyea
On 01/03/2012 04:59 PM, Brian Smith wrote: > 1. libpkix can handle cross-signed certificates correctly, without getting > stuck in loops. Non-libpkix validation cannot. > > 2. libpkix can accept parameters that control each individual validation, > whereas non-libpkix validation relies on global

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-04 Thread Gervase Markham
On 04/01/12 00:59, Brian Smith wrote: > 5. libpkix has better AIA/CRL fetching: 5.a. libpkix can fetch > revocation information for every cert in a chain. The non-libpkix > validation cannot (right?). 5.b. libpkix can (in theory) fetch using > LDAP in addition to HTTP. non-libpkix validation cannot

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-03 Thread Ryan Sleevi
> Are there any other benefits? IIRC, libpkix is an RFC 3280 and RFC 4158 conforming implementation, while non-libpkix is not. That isn't to say the primitives don't exist - they do, and libpkix uses them - but that the non-libpkix path doesn't use them presently, and some may be non-trivial wor

What exactly are the benefits of libpkix over the old certificate path validation library?

2012-01-03 Thread Brian Smith
1. libpkix can handle cross-signed certificates correctly, without getting stuck in loops. Non-libpkix validation cannot. 2. libpkix can accept parameters that control each individual validation, whereas non-libpkix validation relies on global settings. 2.a. libpkix can control OCSP/CRL/cert fet