I believe this plan would have poor side effects. For example, if Apple
ships clients with a broken ECDSA implementation [0], a server cannot
detect detect if a connecting client is an Apple product and avoid the use
of ECDSA in that subset of connections. Instead, ECDSA suddenly becomes
unsafe
On 08/15/2013 03:21 AM, Gervase Markham wrote:
On 15/08/13 01:19, Robert Relyea wrote:
On 08/09/2013 02:57 AM, Gervase Markham wrote:
Can an NSS hacker please tell me, in the fashion of the attempt by the
IE representative below, what types of certificate NSS accepts for
making SSL
On 15/08/13 19:01, Robert Relyea wrote:
That's an instrumentation issue. It was true back in 1995/6 when the
code was added I don't know how true it is today. My guess is the
biggest compatibility issue is self-issued certs, not CA issued certs...
but then again most of those are
Time_Stamp == EKU_Time_Stamp // 597-601
Technically this is EXT_KEY_USAGE_TIME_STAMP || EKU_TIME_STAMP.
What is the difference between these two? Looking at the wording, they
seem identical - EKU stands for EXT_KEY_USAGE...
One is the bit set in the Netscape
I have opened an issue on bugzilla, with patch attached:
https://bugzilla.mozilla.org/show_bug.cgi?id=905848
On Aug 14, 2013, at 6:05 PM, Daniel Jackoway dani...@matasano.com wrote:
Ok, I'll get a patch on bugzilla soon.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
5 matches
Mail list logo
