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,
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
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
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
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
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
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
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
> 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
-
> 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
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
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
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
13 matches
Mail list logo
