Geoffrey Noakes wrote:
>
> The *only* change we are asking of Mozilla is to change "Verified by:
> VeriSign, Inc." in the hover-over box to "Verified by Norton":
In Firefox, we show the name of the organization that issued the intermediate
certificate (the subject O= field of the intermediate ce
Eddy Nigg wrote:
> On 02/09/2012 12:18 AM, From Nelson B Bolyard:
> BTW, this proposal wouldn't be a problem if it would cover, lets say
> the top 500 sites and leave the rest to the CAs. There would be
> probably also the highest gains.
Effectively, we would be making the most popular servers on
Ashok Subash wrote:
> Hi Brian,
>
> We have made some progress. We could statically build nss and link on
> our platform.
Do you mean statically link NSS into Firefox? If so, there are several gotchas
that need to be taken into account. See Wan-Teh's patch at
https://bugzilla.mozilla.org/show_b
Thanks Wan-Teh.
- Original Message -
> From: "Wan-Teh Chang"
> To: "mozilla's crypto code discussion list"
>
> Sent: Thursday, January 19, 2012 9:57:29 AM
> Subject: Re: Review of changes to the HTTP spec
>
> On Thu, Jan 19, 2012 at 1:43
Eitan Adler wrote:
> Brian Smith wrote:
> > If the system NSS isn't new enough, then Firefox's local version of
> > NSS would be used.
>
> From a packager point of view, please don't automagically detect
> these things. If the system NSS is supported provide
I think that we should start some documentation (e.g. a wiki) that documents
the differences between our implementation and other browsers' implementations,
along with a justification for the difference and/or a link to a bug about
resolving the difference.
Examples of differences, off the top
HTTPbis seems to be in its final stages. Although it is supposed to be a
somewhat minor revision, quite significant changes have been made to the spec.
We should review the changes and make sure we provide our feedback before it is
too late. In particular, if there is some change that we think w
Mike Hommey wrote:
> But linux users are not necessarily up-to-date with the latest NSS. I
> seriously doubt the number of users with the very last system nss
> exceeds 10% of the linux user base except in exceptional "good
> timing" cases (like when ubuntu is released with the latest version),
> b
Mike Hommey wrote:
> > In the long run, for performance reasons, we should probably prefer
> > the system NSS libraries to our own, whenever the system NSS
> > libraries are available and are the right version, because at
> > least some of them are likely to already have been loaded into RAM
> > by
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
Benjamin Smedberg wrote:
> I have no particular opinion about whether this is a good idea for
> NSS. I do think that we should not do this for NSPR unless we
> decide to remove support for binary XPCOM components in Firefox
> (per the ongoing discussion in dev.planning). Many of our XPCOM
> code pa
Mike Hommey wrote:
> Please note that this is going to be a problem on systems that have
> system nspr and nss libraries that other system libraries use.
I am intending to avoid changing how NSS is linked on Linux, at least at the
beginning. My priorities are are Android and Windows first, then M
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
Ashok Subash wrote:
> We'll go with your suggestion of using NSS after size reduction for
> this project for our security requirements. But right now we cannot
> upgrade to latest firefox due to the current schedule and resources
> we have for this project. We will follow the guidelines listed in
>
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 a
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 se
Robert Relyea wrote:
> On 01/04/2012 09:04 AM, Anders Rundgren wrote:
> >> There is a capi module in the NSS source tree, but it purposefully
> >> does not surface removable CAPI modules under the assumption that
> >> such devices already have PKCS #11 modules.
While it may be true that they have
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 persisten
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
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
> >
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
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
Ashok Subash wrote:
> Firefox 3.6
:( Beware that you will not get any more security updates for the Firefox 3.6
codebase from Mozilla soon. (We are still sometimes finding security bugs in
Firefox 3.6 that won't ever be fixed in 3.6.x, only in Firefox 12+).
> Currently due to footprint issue we
Matej Kurpel wrote:
> On 22. 12. 2011 10:36, Imen Ibn Hotab wrote:
> > I`m developing pkcs#11 module for Firefox.
> I was developing a PKCS#11 module as well.
Just out of curiosity, what do your PKCS#11 modules do?
Would it make things easier for either of you if Firefox and Thunderbird
support
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
Robert Relyea wrote:
> That being said, I suspect that we currently don't distinguish between
> these two, and wind up with a false success on expected client auth
> failure cases when the server is down. In practice that's not too much
> of a problem because several of the other tests in the suite
helpcrypto helpcrypto wrote:
> and, has anyone achieved to compile it using mingw?
> im always having many issues with that...
MozillaBuild is pretty much mingw.
Please post the errors you receive during your build and I will try to help you
decipher them.
Cheers,
Brian
--
dev-tech-crypto mail
I am modifying tstclnt to test my patch for bug 542832. With my patch, tstclnt
always succeeds or fails like it did before, but in some of the failure cases
it exits with exit code 1 when the testcase expects it to exit with exit code
254, and sometimes it exits with exit code 254 when the testc
I just emailed the mailing list about it: bug 693228. It is a crashing bug in
NSS_Init.
- Original Message -
> From: "Julien Pierre"
> To: "Brian Smith"
> Cc: "mozilla's crypto code discussion list"
>
> Sent: Tuesday, October 18, 201
Hi,
Mozilla wants to commit the beginnings of our SPDY implementation into
mozilla-central sooner than I expected, and sooner than we probably want to do
another NSS release--ideally some time next week. Our SPDY implementation will
depend on the following changes. Two of them are almost done a
There is one known regression. Also, the BEAST workaround is an incompatible
change for some applications. Otherwise, I expect it to be drop-in compatible.
- Brian
- Original Message -
> From: "Julien Pierre"
> To: "Brian Smith"
> Cc: "mozilla's
Will we release a special update to NSS 3.13 to fix the regression bug 693228,
or will we wait until the next release?
Thanks,
Brian
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
NSS release announcements are made on the Mozilla dev-tech-crypto mailing list:
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/28c9fd2d65f7bd55#
- Brian
- Original Message -
> From: "Julien Pierre"
> To: "Brian Smith"
&g
Walter Goulet wrote:
> > > I'm wondering if anyone has recently built a version of NSS on
> > > Windows per the instructions on the NSS build pages
> > > (http://www.mozilla.org/
> > > projects/security/pki/nss/nss-3.7.7/nss-3.7.7-build.html)? I've
> > > run
> > > into problems building NSS using
Are we going to stop maintaining NSS 3.12 after the 3.13 release? People have
asked if we were going to backport bug 665814 to 3.12, specifically. My
understanding is that Bob proposed that the 3.13 release will mark the end of
3.12 maintenance. This is why we (Mozilla) upgraded to 3.13 instead
Pontus Ericson wrote:
> If anyone has any directions/recommendations on where in the NSS
> library I should focus to implement changes to the retrieval and
> association of certificates I would be grateful. Also if there is
> any interest in the project I could answer any questions.
Do you have a
Douglas Stebila wrote:
> The same attack applies to NSS. A while back I submitted a bug and
> patch for NSS, but it has been languishing in Bugzilla without any
> attention. While the use of ECC in deployed TLS environments is quite
> low, it's still probably a good idea to get the code patched. Pe
Mozilla would like to expose a secure PRNG (basically, a wrapper around
PK11_GenerateRandom) to JavaScript content:
https://bugzilla.mozilla.org/show_bug.cgi?id=440046
There is some agreement that we should maintain separate PRNG state for each
origin (roughly: domain name), and that all those s
- Original Message -
> From: "Matej Kurpel"
> > On 22 juil, 14:41, helpcrypto helpcrypto
> > wrote:
> > at this time, i had just to make some test about the AES_CBC or
> > AES_ECB like time to encrypt, time to decrypt,how memory used, how
> > cpu used for just a simple operation . for tis
florent ainardi wrote:
> does anyone can help me starting coding in c the nss library ?
> i had to encrypt and decrypt data
> can you tell me the list of function i had to call to do that
> and tell me the order i suppose that there is a initialization of
> context, generate key, set mode, set algo
radek102 radel wrote:
> When I try building NSS 3.12.9 on Windows 7, I have some strange
> error:
> make: *** No rule to make target `../../nsprpub/configure`, needed by
> `../../nsprpub/WINNT6.1_OPT.OBJ/config.status`. Stop
>
> I'm using mozilla_build. When I compile nss 3.12.9 with nspr 4.8.7
>
ron wrote:
> i just tried compiling nss while running a linux-3.0rc5 kernel, which
> fails with:
>
> for there are no major changes between linux-2.6.39 and linux-3.0
> copying Linux2.6.mk to Linux3.0.mk did the trick, now everything
> compiles fine again.
>
> hope this is the right plcae to post
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/generateCRMFRequest
> as well but have on
ucas.
>
> On May 18, 2011, at 15:17, Jean-Marc Desperrier
> wrote:
>
> > Brian Smith wrote:
> >> See https://twitter.com/#!/scarybeasts/status/69138114794360832:
> >> "Chrome 13 dev channel now blocks certain types of mixed content by
> >> default
See https://twitter.com/#!/scarybeasts/status/69138114794360832: "Chrome 13 dev
channel now blocks certain types of mixed content by default (script, CSS,
plug-ins). Let me know of any significant breakages."
See https://ie.microsoft.com/testdrive/browser/mixedcontent/assets/woodgrove.htm
IE9: h
Are there any users of NSS on Windows CE? Does anybody object to removing the
Windows CE support from NSS? If not, Windows CE support is likely to be removed
sometime soon.
- Brian
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-cryp
"Jean-Marc Desperrier" wrote:
> I don't see it as a substitute for PKI, only as a substitute for
> user/password.
If you want SRP but don't need TLS-SRP then you could implement SRP outside of
NSS and then build the UI support around that non-NSS support as a HTTP
> > 1. The user's username is
Jean-Marc Desperrier wrote:
> But Curl, that supports secret keys from version 7.21.4, with GnuTLS
> only at the moment but is pushing hard to get in in Openssl also,
> apparently has simply given up about having TSP-SRP support when
> compiled with NSS.
>
> I see in an old doc that Johnathan was c
"Jean-Marc Desperrier" wrote:
> Brian Smith wrote:
> > The kind of improvement you described above will be made to resolve
> > Bug 443386 and/or Bug 638966.
>
> I think Bug 638966 is slightly different, it's about permanently
> storing the secret key
Ridley wrote:
> Presence both of a pair of cross-certificates in the Authorities
> certificarte store results looping rather than traversing to a root
> certificate.
See https://bugzilla.mozilla.org/show_bug.cgi?id=634074.
- Brian
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
Ritmo2k wrote:
> I took a look at
> http://www.mozilla.org/projects/security/pki/nss/tools/index.html
> but it wasn’t obvious to me if this was even possible using those
> tools.
In theory you could write a script that exports all the CA certificates from
the Windows certificate store and then us
"Ritmo2k" wrote:
> Anyone know if its possible to configure Firefox to implicitly trust
> all certificate authorities installed in the Windows Trusted Root
> Certification Authorities Store?
Firefox does not support this yet. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=454036
https://bugzil
"Jean-Marc Desperrier" wrote:
> I notice the committed code extracts the generated shared symmetric
> key up to the javascript level, so takes no real advantage from
> having generated it inside NSS (I'd expect it instead to leave
> the AES256 key inside NSS and just get back the handle to it to
>
passfree wrote:
> Speaking of firefox, I know it is not meant to be used as a server but
> it does provide server sockets through nsIServerSocket interface. So,
> could these initialisation routines be included in future versions of
> FF? If not, is it possible to detect somehow if they have been i
(Note that this is to: dev-tech-crypto)
Short Version: We are looking at taking a private patch for one Firefox beta
cycle in mozilla-central to export the MPI functions from FreeBL on all
platforms in our private copy of NSS. Then, we could push the next NSS 3.12
release to the week after Amer
I have been told that some things about my message were not so clear
so I will try to clarify them by responding to myself below. In
particular, there is some confusion about what has been decided and
what is being explored.
Brian Smith wrote:
> 1. Create a supported configuration of NSPR+NSS
Hi,
I am unsure what you are asking. It might be better to write your question in
English and also in a second language (Vietnamese) if you are not a native
English speaker. I can probably find somebody to translate the second language.
Are you trying to add a new PKCS#11 module to Firefox so t
Ludovic Hirlimann wrote:
> I'd like to uplift my knowledge with regards to crypto, certs and
> S/Mime the idea is to be able to figure out bugs that are entered
> into bugzilla, when certs are incorects etc ...) . So I'm looking
> for a book that would explain all the things that I don't know
> abo
"Matej Kurpel" wrote:
> I am implementing a PKCS#11 module. Today I tried to send encrypted
> e-mail to my second gmail account, and it works perfectly (in fact,
> nothing is needed from my token to support this). However, when the
> message arrives and I try to read it, Thunderbird calls C_UnwrapK
Nelson B Bolyard wrote:
> [...]
> I'm talking about putting JBAKE (or whatever it is) into the base product.
> [...]
Is there something specific about J-PAKE that you think is bad or worse than
some alternative? Are you objecting to J-PAKE because you do not trust the
proofs of security given
"Jean-Marc Desperrier" wrote:
> The reference I gave before shows that there is now a widely accepted
> opinion that SRP does not infringe on patent more than J-PAKE (even if
> there was indeed that doubt a few years ago).
>
> A patent that covers SRP might be found, but it does not appear toda
Nelson B Bolyard wrote:
> Brian Smith wrote:
> I personally would like to find a way to avoid calling these internal
> functions from within Firefox--especially since there's no way to
> detect incompatibilities at compile-time and because the interface to
> these functions
"Jean-Marc Desperrier" wrote:
> Why are you choosing J-PAKE instead of SRP ?
The J-PAKE authors claim they developed J-PAKE to avoid patents that cover
other algorithms, and they claim they won't patent it. I don't know if either
claim is true or not.
> http://rdist.root.org/2010/09/08/clench-
> Brian Smith wrote:
> > (Because of Firefox Sync, we are now always going to have crypto
> > features that won't work in FIPS mode.)
> Sigh, ignoring FIPS mode in a feature, is usually a red flag. It means
> you are handling CSP's where you really shouldn't be.
See https://bugzilla.mozilla.org/show_bug.cgi?id=601645.
The following internal functions and data structures in FreeBL that would be
used Firefox 4.0 Sync's J-PAKE implementation through JSCtypes (a mechanism for
calling native code through Javascript).
I personally would like to find a way t
> I am using NSS on linux as a part of a bigger project. To implement
> similar functionality on windows I used windows system APIs. If you
> have any working example pl. share with me.
That's OK. Post a complete, minimal program that runs on Linux.
--
dev-tech-crypto mailing list
dev-tech-crypt
I will try to help you if you can wrap the code below in a complete program
that I can compile and run using Visual Studio 2010.
- Original Message -
From: "PeachUser"
To: dev-tech-crypto@lists.mozilla.org
Sent: Tuesday, October 19, 2010 8:06:33 AM
Subject: Re: problem Importing certific
[I cannot participate in any legal discussions now. Please don't ask
me questions about legal stuff.]
We (Mozilla) are are exploring some approaches to statically link NSS
into Firefox to reduce dynamic linkage overhead caused by the NSS shared
libraries and to allow for whole-program optimiz
On 10/11/2010 7:02 PM, Mountie Lee wrote:
Hi.
I'm mountie lee from paygate, seoul.
I have some question for firefox browser sandbox security.
I'm not sure this mailling list is suitable for my subject.
If not, recommend me the new group
I recommend posting on dev-security:
https://lists.mozill
Wan-Teh Chang wrote:
> I propose that we remove SSL 2.0 support from the NSS trunk (NSS 3.13).
Would this include support for SSLv2->v3 upgrade hellos?
> SSL 2.0 is an old and insecure protocol. No products should be using SSL
2.0
> today.
Can you share any information you have about how commo
Hanno Böck wrote:
> May I make a provocative enhancement proposal? Just remove SSLv3 altogether
> with it.
>
> The reason are bugs like this:
> https://bugzilla.mozilla.org/show_bug.cgi?id=450280
>
> I think this is unfixable as long as one wants to support SSLv3 (see comment
> #15),
> though wh
In accepting patches to implement TLS 1.2 and/or AES-GCM cipher suites, is a
(potentially-)FIPS-140-compliant implementation required? Or, would it be
acceptable in the short-term to have an implementation that is known to be
non-compliant and thus disabled in FIPS mode?
The main issue regardin
Konstantin Andreev wrote:
> On 08/03/10 19:13, Brian Smith wrote:
> > I think I found a problem with the GCM interface that seems
> > to make it impossible to use the PKCS#11 interface in a
FIPS-140-compliant
> > manner. In particular, NIST SP800-38D requires that the I
Nelson B Bolyard wrote:
> It's all about making it difficult enough that people start to ask "why is
this
> obviously more difficult than the casual developer thinks it must be?"
Thank you. That makes a lot of sense. My understanding is that there doesn't
really need to be a difference in the way
When NSS Softoken is in FIPS mode, it refuses to create keys with
C_CreateObject. The same method works fine in regular (non-FIPS) mode. But,
it is possible to achieve the exact same effects using either any of the
procedures outlined below. So, what is the motivation for prohibiting the
key creati
Martin Paljak wrote:
> FYI, OpenSC project [1] has a "fork" of the PKCS#11 headers [2].
Yes, I read the discussion about that and it also seems iffy. If Mozilla
already has explicit permission to distribute them under the LGPL/GPL/MPL
then that works much better.
> At the same time, isn't GCM onl
I read a rumor that Mozilla received explicit permission from RSA labs to
distribute the PKCS#11 header files under the Mozilla tri-license. Does
anybody know anything about that, and how I can verify it?
I noticed that the header files are out of date. They do not include the
AES-GCM mechanism
>From arcfour.c:
http://mxr.mozilla.org/mozilla/source/security/nss/lib/freebl/arcfour.c#390
My guess is that valgrind is considering malloc(5) to allocate 5 bytes, when
really it allocates 8 bytes at least (because of alignment).
Regards,
Brian
> -Original Message-
> From: dev-tech-cry
101 - 178 of 178 matches
Mail list logo
