+1 It's possible to sign a message with an S/MIME ECC cert, not encrypt it
with an ECC key though. Is there no plan to support elliptic curve
cryptography any time soon?
--
View this message in context:
http://mozilla.6506.n7.nabble.com/ECC-S-MIME-encryption-on-Thunderbird-tp353283p361985
Should Thunderbird allow encrypting of S/MIME email using an ECC
certificate? I can successfully sign and receive signed messages that
use an ECC certificate, but attempts to use the same certificate for
encryption get a pop-up window (during save or attempting to send) with
Unable to save
On Tue, 23 Sep 2014 06:57:14 -0700 (PDT), Mjbusch wrote:
> When will NSS support ECC AES256GCM SHA384? Currently the only browser that
> supports this cipher suite is the latest IE browser.
>
NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=923089
PSM: https://bugzilla.mo
When will NSS support ECC AES256GCM SHA384? Currently the only browser that
supports this cipher suite is the latest IE browser.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On Monday, June 9, 2014 4:27:56 PM UTC-7, Rick Andrews wrote:
> AFAIK, Symantec and other CAs have added ECC roots to Mozilla's root store
> using NIST curves. Are any other ECC curves supported by Mozilla, in case one
> wanted to use a different curve? Is the list of supported
Le mercredi 11 juin 2014 11:58:24 UTC+2, cod3 ang3l a écrit :
> On Tue, 2014-06-10 at 18:47 +0200, Kurt Roeckx wrote:
>
> > I would also like to see Ed25519, but there is no standard on how
> > to do that yet.
>
> I added patch for Curve25519 to
> https://bugzilla.mozilla.org/show_bug.cgi?id=9571
On Tue, 2014-06-10 at 18:47 +0200, Kurt Roeckx wrote:
> I would also like to see Ed25519, but there is no standard on how
> to do that yet.
I added patch for Curve25519 to
https://bugzilla.mozilla.org/show_bug.cgi?id=957105
Is patch good?
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.moz
On 11/06/14 03:00, Julien Pierre wrote:
> However, Mozilla and others typically don't support the full set and
> build with the following file :
>
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/ecl/ecl-curve.h&rev=1.7&root=/cvsroot
Is this because there are potenti
illa and others typically don't support the full set and
build with the following file :
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/ecl/ecl-curve.h&rev=1.7&root=/cvsroot
Julien
On 6/9/2014 16:27, Rick Andrews wrote:
AFAIK, Symantec and other CAs ha
On 06/10/2014 09:47 AM, Kurt Roeckx wrote:
> On Mon, Jun 09, 2014 at 04:27:56PM -0700, Rick Andrews wrote:
>> AFAIK, Symantec and other CAs have added ECC roots to Mozilla's root store
>> using NIST curves. Are any other ECC curves supported by Mozilla, in case
>> one
On Mon, Jun 09, 2014 at 04:27:56PM -0700, Rick Andrews wrote:
> AFAIK, Symantec and other CAs have added ECC roots to Mozilla's root store
> using NIST curves. Are any other ECC curves supported by Mozilla, in case one
> wanted to use a different curve? Is the list of supported
AFAIK, Symantec and other CAs have added ECC roots to Mozilla's root store
using NIST curves. Are any other ECC curves supported by Mozilla, in case one
wanted to use a different curve? Is the list of supported algorithms and key
sizes published somewhere?
--
dev-tech-crypto mailing lis
AFAIK, Symantec and other CAs have added ECC roots to Mozilla's root store
using NIST curves. If a CA wanted to add a root using a different curve, we
would need to know what other curves were supported by Mozilla. Is this info
published anywhere?
--
dev-tech-crypto mailing list
dev
ts to call C_CreateObject to create an ECC public key on the device
which fails. Firefox returns sec_error_bad_signature to the user in this
case stating "Peer's certificate has an invalid signature."
Perhaps I misunderstand the meaning of those state and flag values and that
read only/write pro
> attempts to call C_CreateObject to create an ECC public key on the device
> which fails. Firefox returns sec_error_bad_signature to the user in this
> case stating "Peer's certificate has an invalid signature."
RO only affects Token objects.
>
> Perhaps I misundersta
Another bit of oddness. I can put the PKCS#11 device into "read only" mode
where it only supports CKS_RO_PUBLIC_SESSION and CKS_RO_USER_FUNCTIONS
states and asserts the CKF_WRITE_PROTECTED flag. In this state Firefox
attempts to call C_CreateObject to create an ECC public key on the de
--
View this message in context:
http://mozilla.6506.n7.nabble.com/ECC-FIPS-Mode-and-PKCS-11-devices-tp316591p316600.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo
On 05/30/2014 07:47 AM, Jonathan Schulze-Hewett wrote:
> To whom it may concern,
>
> I have a PKCS#11 device that supports ECC operations. In particular
> C_GetMechanismList includes the following items:
>
> CKM_ECDH1_DERIVE
> CKM_ECDH1_COFACTOR_DERIVE
> CKM_EC_KEY_PAIR
To whom it may concern,
I have a PKCS#11 device that supports ECC operations. In particular
C_GetMechanismList includes the following items:
CKM_ECDH1_DERIVE
CKM_ECDH1_COFACTOR_DERIVE
CKM_EC_KEY_PAIR_GEN
CKM_ECDSA
The module is added to Firefox using nsIPKCS11::addModule with 0 for both the
d_all BUILD_OPT=1 USE_64=1 NSS_ENABLE_ECC=1
NSDISTMODE=1" command. You see i set "NSS_ENABLE_ECC" parameter.
After i run "certutil -G -k ec -q nistp256 -d ." command and nssgenerated ecc
key successfull.
But if i try to generated key with sunpkcs11 it gives message "
On 29/11/11 17:34, Brian Smith wrote:
What I said/meant is that inquiries regarding legal issues should be
made to Mozilla Legal instead of the technical areas of bugzilla or
the technical mailing lists. I do not know if anybody has contacted
our legal team or if there is a reason to. I just know
Jean-Marc Desperrier wrote:
> Brian reported there that this should be investigated by the legal
> group, but I'm worried nothing happened since then.
What I said/meant is that inquiries regarding legal issues should be made to
Mozilla Legal instead of the technical areas of bugzilla or the techn
Scott Thomas a écrit :
but the keys are not generated.
i have checked that ECC support from mozilla was removed, can any body
confirm it or tell the way how to enable it, ?
https://bugzilla.mozilla.org/show_bug.cgi?id=367577
Ideas / thoughts ??
Well as you've seen in the bug, it's
Bonjour,
I am using the keygen element for client end key generation in
firefox. RSA is working fine but ECC is having problems.
In code when i use RSA
Proper RSA keys are generated
In code when i use ECC
but the keys are not generated.
i have checked that ECC support from mozilla was
ntributors have chosen to believe that all uses of ECC, except
the uses defined in the RFCs for TLS and IPSec, are potentially patent
infringing. Consequently, the "Basic ECC" builds that are used in all
Mozilla clients, use ECC only in the TLS protocol itself, and in cert
signature v
Fei Fong wrote:
> I am able to generate ECC encryption keys using: reqtype = 'ec-ex'
> However, it fails when I try to generate ECC signature keys using
> reqtype = 'ec-sign'
>
> I tried the other options for ECC given in
> https://developer.mozilla.org/en/
I am using the following function to test generating key pairs in
Firefox 5.0:
crmf_result = crypto.generateCRMFRequest(
"CN=X",
"bla1",
"bla2",
null,
"gen_ready();",
256, "curve=nistp256", reqtype);
}
I am able to generate ECC en
On Wed, 20 Jan 2010, Kaspar Brand wrote:
On 20.01.2010 02:11, Wan-Teh Chang wrote:
With the nss-3.12.5-with-nspr-4.8.2.tar.gz tarball that you downloaded from Mozilla, you
have to build "Extended ECC" using the complicated procedure described in
http://pki.fedoraprojec
On 20.01.2010 02:11, Wan-Teh Chang wrote:
> With the nss-3.12.5-with-nspr-4.8.2.tar.gz tarball that you
> downloaded from Mozilla, you have to build "Extended ECC"
> using the complicated procedure described in
> http://pki.fedoraproject.org/wiki/ECC_Capable_NSS, and
>
On Wed, 20 Jan 2010, Wan-Teh Chang wrote:
2010/1/18 Kai Chan :
With the nss-3.12.5-with-nspr-4.8.2.tar.gz tarball that you downloaded from Mozilla, you
have to build "Extended ECC" using the complicated procedure described in
http://pki.fedoraproject.org/wiki/ECC_Capable_NSS, and y
2010/1/18 Kai Chan :
> When building with both "NSS_ENABLE_ECC" and "NSS_ECC_MORE_THAN_SUITE_B"
> enabled, the build fails because of lib/freebl/ecl/ecl-curve.h:
> #ifdef NSS_ECC_MORE_THAN_SUITE_B
> #error This source file is for Basic ECC only .
> #e
Hi,
I'm building the 3.12.5 with NSPR .tgz from Mozilla FTP on a Fedora system.
Yeah, I noticed this was a problem before, but I was fine with just NISTP256
to 521 except you're saying the previous command won't work in Basic ECC
mode. Wait, you said RPM, as in not building f
On 1/15/2010 4:21 PM, Kai Chan wrote:
certutil -R -s "CN=ectest, O=ectest, L=ectest, ST=ectest, C=US" -p
"123-456-7890" -o ectest.req -d . -k ec -q nistp256 -Z SHA256
That command works for me. Are you trying this on a Red Hat or Fedora
system? If so, compiling NSS with
When building with both "NSS_ENABLE_ECC" and "NSS_ECC_MORE_THAN_SUITE_B"
enabled, the build fails because of lib/freebl/ecl/ecl-curve.h:
#ifdef NSS_ECC_MORE_THAN_SUITE_B
#error This source file is for Basic ECC only .
#endif
I guess this is the extent softoken ca
Hi,
I take it "Extended ECC" is the additional option of
"NSS_ECC_MORE_THAN_SUITE_B"? I tried NSS 3.12.5 with NSPR 8.2 with only
that option and "NSS_ENABLE_ECC", so it's using softoken. Unfortunately,
still getting the same error. Here's the command a
Kai,
In NSS builds marked as "Basic ECC", ECC may be
used only for TLS/SSL. So it's possible that certutil cannot
generate CSRs when the "Basic ECC" version of NSS
is used.
In NSS builds marked as "Extended ECC", certutil
should be able to generate CSRs. If
Yes, it's pointing to the ECC-enabled NSS. I am able to generate EC keys
using:
certutil -G -d . -k ec -q nistp256
However, no luck with EC certificate requests with and without specifying
the hash.
Thanks,
Kai
On Thu, Jan 14, 2010 at 7:46 PM, Kyle Hamilton wrote:
> Are you cert
Are you certain that certutil is using the version of the NSS library
that has ECC support compiled in? Most *nixes have a command called
'ldd' or such that will print the list of dynamic libraries that an
executable depends on, as well as what files the system is using to
match them
Correction: certutil -R -s "CN=ectest, O=ectest, L=ectest, ST=ectest, C=US"
-p "123-456-7890" -o ectest.req -d . -k ec -q nistp256 -Z SHA256
During the parameter parsing in certutil_main() in cmd/certutil/certutil.c,
the '-Z' option should call SECU_StringToSignatureAlgTag() in
cmd/lib/secutil.c a
Thank you both for your responses. Yes, you are correct. I've compiled NSS
with "NSS_ENABLE_ECC" and I can make EC keys, but am having problems with
CSRs. Perhaps I'm doing something wrong with this certutil command:
certutil -R -s "CN=ectest, O=ectest, L=ectest, ST=ectest, C=US" -p
"123-456-78
On 01/14/2010 01:36 PM, Kai Chan wrote:
> Hi,
>
> NSS has ECDSA with SHA1 enabled in SEC_DERSignData() in secsign.c (
> http://mxr.mozilla.org/security/source/security/nss/lib/cryptohi/secsign.c),
> but will ECDSA with SHA256 and higher be supported in the future? Or is
> this something as simple
2010/1/14 Kai Chan :
> Hi,
>
> NSS has ECDSA with SHA1 enabled in SEC_DERSignData() in secsign.c
> (http://mxr.mozilla.org/security/source/security/nss/lib/cryptohi/secsign.c),
> but will ECDSA with SHA256 and higher be supported in the future? Or is
> this something as simple as adding to the swi
Hi,
NSS has ECDSA with SHA1 enabled in SEC_DERSignData() in secsign.c (
http://mxr.mozilla.org/security/source/security/nss/lib/cryptohi/secsign.c),
but will ECDSA with SHA256 and higher be supported in the future? Or is
this something as simple as adding to the switch statement, since the other
if no one else does.
On 2009-Dec-18, at 10:51 PM, Konstantin Andreev wrote:
I have noticed, the following method is used in the ECC sign/verify routines to
derive 'e' integer from a digest:
( begin cite )
/* In the definition of EC signing, digests are truncated
* t
I have noticed, the following method is used in the ECC sign/verify routines
> to derive 'e' integer from a digest:
>
> ( begin cite )
>/* In the definition of EC signing, digests are truncated
> * to the length of n in bits.
> * (see SEC 1 "E
Hello.
I have noticed, the following method is used in the ECC sign/verify routines to
derive 'e' integer from a digest:
( begin cite )
/* In the definition of EC signing, digests are truncated
* to the length of n in bits.
* (see SEC 1 "Elliptic Curve
I downloaded "nss-3.12.3.99.3-1.el5_3.2.src.rpm" from redhat.com and am
trying to build an ECC-enabled RHEL5 rpm with a modified spec file. I
uncomment in "/usr/src/redhat/SPEC/nss.spec:
NSS_ENABLE_ECC=1
export NSS_ENABLE_ECC
just before "# first, build freebl and soft
Hello.
Almost everywhere across NSS the ECC-specific executable code is compiled
conditionally:
#ifndef NSS_ENABLE_ECC
/* ECC-specific executable code ... */
#endif
... but not everywhere. For example,
seckey_ExtractPublicKey() @ cryptohi/seckey.c
http://bonsai.mozilla.org
On 2009-11-19 13:07 PST, Kai Chan wrote:
> Ah, noobtastic...
A new word for my vocabulary! :)
> Thank you for reminding me to check shared library dependencies.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Ah, noobtastic... Thank you for reminding me to check shared library
dependencies.
On Thu, Nov 19, 2009 at 3:30 PM, Wan-Teh Chang wrote:
> 2009/11/19 Kai Chan :
> > Hi,
> >
> > I'm using NSS 3.12.4 with NSPR 4.8 release. I want to generate keys and
> > ce
2009/11/19 Kai Chan :
> Hi,
>
> I'm using NSS 3.12.4 with NSPR 4.8 release. I want to generate keys and
> certs with the basic supported ECC curves (nistp256, nistp384, nistp521)
> included when NSS is compiled with the "NSS_ENABLE_ECC" flag. However, when
>
an wrote:
>
> > I'm using NSS 3.12.4 with NSPR 4.8 release. I want to generate keys and
> > certs with the basic supported ECC curves (nistp256, nistp384, nistp521)
> > included when NSS is compiled with the "NSS_ENABLE_ECC" flag. However,
> > when I try
On 2009-11-19 10:17 PST, Kai Chan wrote:
> I'm using NSS 3.12.4 with NSPR 4.8 release. I want to generate keys and
> certs with the basic supported ECC curves (nistp256, nistp384, nistp521)
> included when NSS is compiled with the "NSS_ENABLE_ECC" flag. However,
> w
Hi,
I'm using NSS 3.12.4 with NSPR 4.8 release. I want to generate keys and
certs with the basic supported ECC curves (nistp256, nistp384, nistp521)
included when NSS is compiled with the "NSS_ENABLE_ECC" flag. However, when
I try using certutil to generate certificates using
correct, I was thinking of Entrust and CRLDP. As far as I
can tell the inclusion of ECC into NSS was based on NSS implementing
non-patented ECC techniques.
Certicom have said that their desire is "to facilitate the wide-scale adoption
and proliferation of Elliptic Curve Cryptography (ECC) techno
facilitate the wide-scale adoption
and proliferation of Elliptic Curve Cryptography (ECC) technology" and that
they "will, upon request, provide a nonexclusive, royalty free patent license,
to manufacturers to permit end users (including both client and server sides),
to u
On Tuesday 03 November 2009 14:29:43 Rob Stradling wrote:
> On Tuesday 03 November 2009 13:42:14 David Stutzman wrote:
>
> Hi David.
>
> Gentoo's NSS package supports ECC because I asked them to enable it:
> http://bugs.gentoo.org/247221
>
> I don't think it
rypto algorithm
Reasons:
software patents and US Laws (?)
I think these reasons are out of date and not applicable.
Re patents, Entrust freely licensed enough of their ECC-relevant patents
to permit it to be implemented in NSS (though IIRC Entrust retains
rights to certain ECC-related patent, which
Rob Stradling wrote:
A question for the NSS devs:
Is there any reason why NSS couldn't be changed to assume "NSS_ENABLE_ECC=1"
by default?
Yes...
http://fedoraproject.org/wiki/User:Peter/Disabled_applications
Disabled features:
Elliptic Curve crypto algorithm
Reasons:
software paten
On Tuesday 03 November 2009 13:42:14 David Stutzman wrote:
> Some linux distributions distribute NSS built without ECC support, like
> Fedora. Red Hat, on the other hand, distributes NSS sort of how Java
> 1.6 is. It "suppports" ECC but itself has no ECC implementation and
Kashyap Chamarthy wrote:
certutil -G -k ec -q nistp256 -d .
Generating key. This may take a few moments...
certutil: unable to generate key(s)
: security library failure.
I guess, you need a third party ECC module?
I must admit that I am a bit puzzled by the current
ogress meter
> is full. DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
>
>
> Continue typing until the progress meter is full:
>
> ||
>
> Finished. Press enter to continue:
>
>
> Generating key. This
Hi,
I'm using NSS 3.12.4 with NSPR 4.8 release from the Mozilla FTP site on
Fedora 10. I'm interested in generating keys and certs with the basic NIST
curves (nistp256, nistp384, nistp521) included in the softoken
implementation when NSS is compiled with the "NSS_ENABLE_ECC" flag. I would
greatl
ptohi/secsign.c#92
> :
>
> -( begin @ SGN_NewContext )-
> #ifndef NSS_ECC_MORE_THAN_SUITE_B
> if (key->keyType == ecKey) {
> PORT_SetError(SEC_ERROR_INVALID_ALGORITHM);
> return 0;
> }
> #endif
> -( end )---
>
> This disables EC
if (key->keyType == ecKey) {
PORT_SetError(SEC_ERROR_INVALID_ALGORITHM);
return 0;
}
#endif
-( end )---
This disables ECC at NSS level. Users, which own 3rd-party PKCS#11 tokens with
licenced ECC, must build custom NSS with tricky process.
But, ... what's
On 17 мар, 21:46, ps_mitrofa...@mail.ru wrote:
> Hi! I've got a question.
> All NSS ECC algorithms for computation of public&private/derived
> secret key staff use '04' as first byte (base point, public key,
> derived secret). For what?
So... It's so :)
Hi! I've got a question.
All NSS ECC algorithms for computation of public&private/derived
secret key staff use '04' as first byte (base point, public key,
derived secret). For what?
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.or
Nelson B Bolyard wrote:
tstclnt is able to support protocols in which the client speaks first,
and protocols in which the server speaks first. By default, it supports
protocols in which the server speaks first. To make it support protocols
in which the client speaks first, use the -f command li
ackward binary compatibility, NSS does not
enable any new cipher suites that have been added to NSS since NSS 3.0.
That means that none of the new ECC cipher suites are enabled unless you
explicitly enable them. That's equally true of 3.11.x and 3.12.x.
Your tstclnt command lacks the option tha
I'm scratching my head here...I'm trying to connect to an SSL server
with a full EC chain using a JSS SSLSocket.
Using NSS 3.12.2 libs taken from my Firefox 3.0.6 install I get:
org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed:
(-5978) Network file descriptor is not connected.
ps_mitrofa...@mail.ru wrote:
Freebl3.dll works fine )
err. I highly suggest you do not go that route. NSS does not guarrentee
the freebl3 interface as a stable interface. Your app may break when new
versions of NSS are installed.
Let me make this perfectly, crystal-clear. Freebl3.dll is a
Freebl3.dll works fine )
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
ps_mitrofa...@mail.ru wrote:
Hi. I've got a problem.
I need to use NSS freebl3.dll ECC-functions (for ECDH).
The first and most obvious question... Why?
freebl3.dll is a private NSS DLL. NSS does not support applications
using it's functions directly, and doing so would be a good w
Hi. I've got a problem.
I need to use NSS freebl3.dll ECC-functions (for ECDH). This DLL has
only one export function FREEBLVector *FREEBL_GetVector(void).
So, to use freebl3.dll ECC-functions I wrote somth like this:
vec= FREEBL_GetVector(void).;(this works fine).
And after that I should
[EMAIL PROTECTED] wrote, On 2008-12-08 07:00:
> I see, that NSS has many crypto algorithms. I'm trying to make crypto
> plugin for IPSec. I need to use ECC algorithms (ECDSA, ECDH). So. Are
> the NSS ECC algorithms compatible with IPSec (I mean key strength)?
In ECC, key strength is
I see, that NSS has many crypto algorithms. I'm trying to make crypto
plugin for IPSec. I need to use ECC algorithms (ECDSA, ECDH). So. Are
the NSS ECC algorithms compatible with IPSec (I mean key strength)?
Thanks for any help.
___
dev-tech-c
Frank Hecker:
> Eddy Nigg wrote:
>> Frank, where is the lack of consensus exactly?
>
> IIRC the reason I changed the wording to "potentially problematic" was
> that some of the practices weren't necessarily "problematic" in all
> contexts, at least IMO. Thus, for example, distributing private keys
Eddy Nigg wrote:
> Frank Hecker:
>> Yes, I'll do that. (Incidentally, I'm now calling it the "potentially
>> problematic practices" list, because there's a lack of consensus on the
>> extent to which some of these practices are problems in general.)
>
> Frank, where is the lack of consensus exactl
Frank Hecker:
>
> Yes, I'll do that. (Incidentally, I'm now calling it the "potentially
> problematic practices" list, because there's a lack of consensus on the
> extent to which some of these practices are problems in general.)
>
Frank, where is the lack of consensus exactly? Are you referring t
Frank Hecker wrote:
> Robin Alden wrote:
>> Frank, would you consider these practices of issuing certificates to
>> hostnames* and also of issuing to non-internet routable IP addresses as
>> being something to add to your problematic practices list?
>
> Yes, I'll do that.
Done:
https://wiki.moz
Robin Alden:
>> I think an IP address is almost on the same level as a domain name, but
>> even here there can be problems. For example if you are willing to
>> validate dynamic assigned IP addresses, than this can be actively
>> exploited obviously. An assigned IP may belong to somebody else withi
Frank Hecker wrote:
> Frank Hecker wrote:
>> I am now opening the first public discussion period for a request from
>> Comodo to add the Comodo ECC Certification Authority root certificate
>> to Mozilla and enable it for EV use. This is bug 421946, and Kathleen
>>
stname to an external
> server. Although not subject to the same threat of attacks on DNS we would
> also include non-internet routable IP addresses as being of increased risk.
> We therefore give a commitment that we will not issue any certificates which
> are signed by, or benefit fro
On Wed, Aug 6, 2008 at 1:11 PM, Eddy Nigg <[EMAIL PROTECTED]> wrote:
>
> In other words, Comodo would issue multiple certificates for the very
> same domain name? You could have multiple valid certificates for
> www.mozilla.com?
Technically, there is absolutely nothing wrong with this. Multiple
I
> -Original Message-
> From: Eddy Nigg
> Sent: Wednesday, August 06, 2008 9:12 PM
> To: dev-tech-crypto@lists.mozilla.org
> Subject: Re: Comodo ECC CA inclusion/EV request
>
> Robin Alden:
> > Eddy Nigg said:
> >> In http://www.mozilla.org/proje
On Fri, Aug 8, 2008 at 1:12 PM, Nelson B Bolyard <[EMAIL PROTECTED]> wrote:
> mozilla wrote, On 2008-08-08 12:31:
>> Some have groused that the ordering of cipher suites has an bias against
>> FIPS. For example, Camelia and RC4 seem to be prefered over AES. Is the
>> rationale for the ordering docu
On Fri, Aug 8, 2008 at 12:18 PM, mozilla <[EMAIL PROTECTED]> wrote:
>
> Still not working in Fedora 8.
The NSS libraries that come with Fedora or Red Hat Enterprise Linux
do not implement ECC.
You can download the Linux version of Firefox from www.mozilla.com
directly. The Firefo
ith the same symmetric key size, preference was given
- to ephemeral key establishment algorithms (ECDHE, DHE) over static ones
- to ECC over RSA, and RSA over DSS (as signature algs)
- to performance (explains RC4)
- to ciphers preferred only in one nation, over those generally desired.
Regarding tha
Some have groused that the ordering of cipher suites has an bias against
FIPS. For example, Camelia and RC4 seem to be prefered over AES. Is the
rationale for the ordering documented or explained somewhere? My guess is
that speed was a consideration.
cipher_suites[34] = {
Teh Chang wrote, On 2008-07-25 12:03:
>> On Fri, Jul 25, 2008 at 6:59 AM, mozilla <[EMAIL PROTECTED]> wrote:
>>> I expected FF3.0.1 to do TLS with the specific ECC ciphersuite that you
>>> identify. However, my FF3 is not offering the ECC suites in its client
>
There is no LD_LIBRARY_PATH defined in the shell environment variable set.
Again, I did not disable anything.
"Wan-Teh Chang" <> wrote in message
news:[EMAIL PROTECTED]
> On Fri, Jul 25, 2008 at 2:49 PM, Nelson B Bolyard <[EMAIL PROTECTED]>
> wrote:
>>
>> I suspect that it MAY be the case that t
> wrote in message
news:[EMAIL PROTECTED]
> On Fri, Jul 25, 2008 at 6:59 AM, mozilla <[EMAIL PROTECTED]> wrote:
>> I expected FF3.0.1 to do TLS with the specific ECC ciphersuite that you
>> identify. However, my FF3 is not offering the ECC suites in its client
>> hello
Jean-Marc Desperrier:
>
> That part is of course much more dubious. But if you consider hostname
> only servers to be acceptable, there's little ground to say multiple
> subscrivers can't have one with the same name. Even if you'd decide to
> try to enforce that, there's no way to restrein another
Eddy Nigg a écrit :
> [...]
> In other words, Comodo would issue multiple certificates for the very
> same domain name? You could have multiple valid certificates for
> www.mozilla.com?
It's an actually useful option. You may want the multiple servers that
will answer for www.mozilla.com to not s
Robin Alden:
> Eddy Nigg said:
>> In http://www.mozilla.org/projects/security/certs/policy/ section 7
>> explicitly states:
>>
>> "for a certificate to be used for SSL-enabled servers, the CA takes
>> reasonable measures to verify that the entity submitting the certificate
>> signing request has re
the "Problematic Practices"!
A fair point. My comment was based on the fact that Comodo isn't
currently issuing DV certs under the ECC root, and there's no firm
schedule for when they might do so. However you are correct that Comodo
reserves the right to do so under the sc
Eddy Nigg said:-
> Robin Alden:
> > f) refers to an SSL product which is limited in such a way that it isn't
> > generally usable on the public internet. We offer no warranty on the
> > product, and the main part of the domain validation is to ensure that
> the
> > domain name in the certificate i
Robin Alden:
> f) refers to an SSL product which is limited in such a way that it isn't
> generally usable on the public internet. We offer no warranty on the
> product, and the main part of the domain validation is to ensure that the
> domain name in the certificate is not a valid internet name o
Frank Hecker:
> Eddy Nigg wrote:
>> As per your comment in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=421946#c17 you state that
>> no problematic
>> practices associated with this CA, but I found that in section 2.4.1
>> domain validated wild cards are issued, which is listed in
>> http://
Robin Alden:
> f) refers to an SSL product which is limited in such a way that it isn't
> generally usable on the public internet. We offer no warranty on the
> product, and the main part of the domain validation is to ensure that the
> domain name in the certificate is not a valid internet name o
1 - 100 of 159 matches
Mail list logo
