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
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
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
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
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),
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
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
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
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
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 it's
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
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
(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 - but that
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
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 all
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
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.
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
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
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 to HTTP.
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
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
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
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 a
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 be able
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 are
On Wed, Jan 4, 2012 at 3:51 PM, Brian Smith bsm...@mozilla.com 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
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
Snip
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
29 matches
Mail list logo
