Re: Signature Algorithm: sha1WithRSAEncryption in /etc/pki/tls/cert.pem

There’s a lot going on here. 1) The discussion about /etc/pki/tls/cert.pem and ca-certificates belongs with your distro 2) Assuming your distro ships the Mozilla Root Store, which few do correctly and successfully, the discussion about root certificates belongs with mozilla.dev.security.policy

Re: Accessing Firefox key store for signing

On Sat, May 25, 2019 at 2:03 AM Nisar Hassan wrote: > Dear Team, > > > > Is there any way we can digitally sign the transaction in a web app by > using > the certificate stored at Firefox's key store. > > Best Regards, > > Nisar Hassan > > Professional Service Engineer (PKI Department) > >

Re: deactivate Web Cryptography API

On Sat, May 25, 2019 at 2:03 AM wrote: > Hello, > > we are using Firefox. But we want to deactivate the API "Web Cryptography > API". We are using an addon for this case -> "WEB API MANAGER". Our target > is to deactivate this setting without using an addon. > > Is there any possibility for our

Re: Specifying allowed parameter encodings in Mozilla policy

On Monday, May 22, 2017 at 3:58:21 AM UTC-4, Gervase Markham wrote: > On 19/05/17 17:02, Ryan Sleevi wrote: > > I support both of those requirements, so that we can avoid it on a > > 'problematic practices' side :) > > But you think this should be a policy requireme

Re: Specifying allowed parameter encodings in Mozilla policy

I support both of those requirements, so that we can avoid it on a 'problematic practices' side :) There's a webcompat aspect for deprecation - but requiring RFC-compliant encoding (PKCS#1 v1.5) or 'not stupid' encoding (PSS) is a good thing for the Web :) On Fri, May 19, 2017 at 9:57 AM,

Google's past discussions with Symantec

(Wearing a Google Hat, if only to share what has transpired) Symantec has recently shared in https://www.symantec.com/connect/blogs/symantec-ca-proposal , as well as https://groups.google.com/d/msg/mozilla.dev.security.policy/LRvzF2ZPyeM/OpvBXviOAQAJ , a plan for what they believe is an

Re: SSL_BYPASS_PKCS11

On Tue, Mar 7, 2017 at 3:28 PM, Rob Crittenden wrote: > SSL_BYPASS_PKCS11 is marked as deprecated in ssl.h. What are the plans > on removing it? > > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.28_release_notes

Re: RFC7512 PKCS#11 URI support

On Tuesday, April 5, 2016, Hubert Kario <hka...@redhat.com> wrote: > On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote: > > On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse <dw...@infradead.org > <javascript:;>> > wrote: > > > Do you even have a way

Re: RFC7512 PKCS#11 URI support

On Mon, Apr 4, 2016 at 4:09 PM, David Woodhouse wrote: > I'm perfectly happy to entertain the notion of adding new functions for > PK11_FindCertsFromURI() (et al.), but I was looking for *real* > information about whether it was actually necessary. Which you don't > seem to

Re: RFC7512 PKCS#11 URI support

On Mon, Apr 4, 2016 at 3:53 PM, David Woodhouse wrote: > Of course it's an API change. But as noted, it's an API *addition*, in > that it makes something work that didn't before. > > The criterion for such additions should be "if it isn't a *bad* thing > for that to start

Re: RFC7512 PKCS#11 URI support

On Mon, Apr 4, 2016 at 3:45 PM, David Woodhouse wrote: > That won't change. Unless you explicitly use a new function that > provides a URI instead of a nickname, of course. > > You will *only* get a URI from direct user input, in a situation where > a user could already feed

Re: RFC7512 PKCS#11 URI support

On Mon, Apr 4, 2016 at 12:39 PM, David Woodhouse wrote: > > We usually reserve the term "breaks the API" for when something *used* > to work, and now doesn't. Not when a previously-failing call now > actually does something useful. No, sorry David, that's not how we've done

Re: RFC7512 PKCS#11 URI support

On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse wrote: > I don't see it. I still don't see *any* way for you to get a PKCS#11 > URI anywhere in the memory space of your application, unless you > specifically ask for one with a new API — or unless you take untrusted > input

Re: RFC7512 PKCS#11 URI support

On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse wrote: > Do you even have a way for a nickname to be entered in text form, such > that you could "maliciously" be given a PKCS#11 URI instead of the > normal "token:nickname" form? Perhaps a user could edit a config file? > Or

Re: RFC7512 PKCS#11 URI support

On Monday, April 4, 2016, David Woodhouse wrote: > > I didn't call you a liar. I simply said that I can't see how the > statement you made could be anything but false. There are plenty of > reasons that could be the case — including my own ignorance — which > don't involve

Re: RFC7512 PKCS#11 URI support

On Apr 4, 2016 7:15 AM, "David Woodhouse" wrote: > > Ryan? > > Unless you are able to provide an explanation of how this would "break > Chrome's use of the API", I shall continue to assume that your > statement was false, and design accordingly. > > I certainly can't see how

Re: RFC7512 PKCS#11 URI support

On Thursday, March 17, 2016, John Dennis <jden...@redhat.com> wrote: > On 03/17/2016 10:52 AM, Ryan Sleevi wrote: > >> On a technical front, Chrome and Firefox, as browsers, have been >> removing support for the notion of generic URIs, and investing in >

Re: RFC7512 PKCS#11 URI support

On Thursday, March 17, 2016, David Woodhouse wrote: > > It is a fundamental part of all the major Linux desktop distributions, > and thus fairly much ubiquitous there. This is a loaded statement, but I still believe this is overstated. But I don't want to get into a "whose

Re: SHA-1 with 'notAfter >= 2017-1-1'

On Tue, January 19, 2016 2:56 pm, s...@gmx.ch wrote: > Hi > > We're already having some discussions about SHA-1, but I'll split this > up into a new thread. > > The initial goal of bug 942515 was to mark certs as insecure, that are > valid 'notBefore >= 2016-01-01' (means issued to use in

[ANNOUNCE] NSS 3.19.2 Release

The NSS Development Team announces the release of NSS 3.19.2 Network Security Services (NSS) is a patch release for NSS 3.19. No new functionality is introduced in this release. This release addresses a backwards compatibility issue with the NSS 3.19.1 release. Notable Changes: * In NSS 3.19.1,

Re: PKCS#11 platform integration

On Tue, May 12, 2015 9:44 am, Peter Bowen wrote: How about an even simpler solution? Don't have p11-kit load the PKCS#11 modules, just provide a list of paths and let the application pass those to NSS. That way the application can choose to transparently load modules without user

Re: PKCS#11 platform integration

On Mon, May 11, 2015 4:09 am, David Woodhouse wrote: I completely agree that Chrome should only ever load the modules which are configured to be loaded into Chrome. I'm surprised you feel the need to mention that. Because you still don't understand, despite how many ways I'm trying to say

Re: PKCS#11 platform integration

On Sun, May 10, 2015 12:57 pm, David Woodhouse wrote: On Sun, 2015-05-10 at 12:47 -0700, Ryan Sleevi wrote: If the user requests NSS to load a module. It should load that module. And that module only. Period. The canonical per-user way to request an application to load a module

Re: PKCS#11 platform integration

On Sat, May 9, 2015 3:30 pm, David Woodhouse wrote: On Fri, 2015-05-08 at 15:07 -0700, Ryan Sleevi wrote: Yes, it should. You'll introduce your users to a host of security issues if you ignore them (especially for situations like Chrome). For example, if you did what you propose to do

Re: PKCS#11 platform integration

On Sat, May 9, 2015 3:30 pm, David Woodhouse wrote: No, you should be able to do it w/o patching NSS. OK... how? If the Shared System Database wasn't such an utter failure, not even being used by Firefox itself, then just installing it there would have been a nice idea. But *nothing*

Re: PKCS#11 platform integration

On Sun, May 10, 2015 12:31 pm, David Woodhouse wrote: You don't need to expose it to the sandbox to use PKCS#11 in the web browser. That's not how modern sandboxed browsers work. That sounds like a bit of a failure of the sandboxing to me. Just so I understand what you're saying...

Re: PKCS#11 platform integration

On Fri, May 8, 2015 5:38 am, David Woodhouse wrote: These days it does. Modern systems ship with p11-kit², which exists precisely to fill that gap and provide a standard discoverable configuration for installed PKCS#11 modules. Your citation ( http://p11-glue.freedesktop.org/p11-kit.html )

Re: [bulk] PKCS#11 platform integration

On Fri, May 8, 2015 6:09 am, David Woodhouse wrote: On Linux distributions it *is* the platform's mechanism of choice for configuring PKCS#11 tokens. NSS needs to support it if it wants to integrate with the platform properly. I'm sorry to continually push back on this, but you continue to

Re: NSS support for RFC7512 PKCS#11 URIs

On Tue, May 5, 2015 8:55 am, David Woodhouse wrote: I'm talking about the serial numbers of the certs issued *by* the two My CAs. Good to have that clarification :) Different CAs (in as much as different public keys), but with the same DER-encoded subject name (not necessarily the same

Re: NSS support for RFC7512 PKCS#11 URIs

On Mon, May 4, 2015 1:25 pm, David Woodhouse wrote: Surely that's not unique? Using the above example, surely the first certificate issued by the 2010 instance of 'My CA', and the first certificate issued by the 2015 instance, are both going to have identical CKA_ISSUER and

Re: Remove Legacy TLS Ciphersuites from Initial Handshake by Default

On Mon, March 16, 2015 1:06 pm, Erwann Abalea wrote: Phase RSA1024 out? I vote for it. Where's the ballot? :) This is a browser-side change. No ballot required (the only issue *should* be non-BR compliant certificates issued before the BR effective date)

Re: Remove Legacy TLS Ciphersuites from Initial Handshake by Default

On Mon, March 16, 2015 10:24 am, Erwann Abalea wrote: Le lundi 16 mars 2015 10:29:08 UTC+1, Kurt Roeckx a écrit : On 2015-03-14 01:23, kim@safe-mail.net wrote: Is there an agreed timeline for deprecation of the technologies listed in the initial posting? We should be proactive in this

Re: Separating Firefox crypto code into removable parts

On Sat, March 7, 2015 12:20 pm, kim.da...@safe-mail.net wrote: Looking for comments about feasibility of breaking-up Firefox TLS/SSL-handling code into easily-removable sections. I want to fully separate NSS code from code that handles: 1) MD5 signature handling 2) SHA1 signature

Re: Interested in reviving PSS support in NSS

On Sun, February 15, 2015 3:07 pm, Hanno Böck wrote: Unfortunately the code never got fully merged. Right now the state is that code for the basic functions exists in freebl, but all upper layer code is not merged. I think if I remember correctly the code currently in freebl will also not

Re: Reducing NSS's allocation rate

On Tue, November 11, 2014 10:26 am, Nicholas Nethercote wrote: On Mon, Nov 10, 2014 at 7:06 PM, Ryan Sleevi ryan-mozdevtechcry...@sleevi.com wrote: Not to be a pain and discourage someone from hacking on NSS My patches are in the following bugs: https://bugzilla.mozilla.org

Re: Reducing NSS's allocation rate

On Mon, November 10, 2014 6:51 pm, Nicholas Nethercote wrote: Hi, I've been doing some heap allocation profiling and found that during basic usage NSS accounts for 1/3 of all of Firefox's cumulative (*not* live) heap allocations. We're talking gigabytes of allocations in short browsing

Re: SSLKEYLOGFILE always enabled

On Wed, July 16, 2014 11:42 pm, Falcon Darkstar Momot wrote: When it comes to key material, it's an outstanding idea to err on the side of caution. Does anyone actually require this feature in a non-debug build? If not, then it's completely unreasonable to leave it in such builds, even

Re: SSLKEYLOGFILE always enabled

On Tue, July 15, 2014 1:11 pm, Tom Ritter wrote: Is having it in by default useful enough to outweigh the risk? When the Dual_EC_DRBG news stories were blowing it, it was revealed that you could switch to it by just changing the Windows Registry. It's a Windows-supported backdoor - no

Re: SSLKEYLOGFILE always enabled

On Tue, July 15, 2014 1:11 pm, Tom Ritter wrote: Is having it in by default useful enough to outweigh the risk? When the Dual_EC_DRBG news stories were blowing it, it was revealed that you could switch to it by just changing the Windows Registry. It's a Windows-supported backdoor - no

Re: Chrome: From NSS to OpenSSL

On Mon, February 3, 2014 4:30 am, David Woodhouse wrote: On Mon, 2014-02-03 at 12:13 +, Alan Braggins wrote: Having support for PKCS#11 tokens at all is a pro, even if one irrelevant to the vast majority of users. That gets less true as we start to use PKCS#11 a little more. It

Re: Chrome: From NSS to OpenSSL

On Fri, January 31, 2014 9:18 am, Alan Braggins wrote: On 31/01/14 10:24, Julien Pierre wrote: On 1/27/2014 10:28, Kathleen Wilson wrote: Draft Design Doc posted by Ryan Sleevi regarding Chrome migrating from NSS to OpenSSL: https://docs.google.com/document/d

Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

On Thu, January 2, 2014 1:25 pm, Julien Vehent wrote: Hi Aaron, On 2014-01-02 16:10, Aaron Zauner wrote: Hi Kurt, On 02 Jan 2014, at 21:51, Kurt Roeckx k...@roeckx.be wrote: On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote: I *think* they want to prefer CAMELLIA to

Re: Firefox's confusing saga in HTTPS warnings

On Mon, November 25, 2013 12:06 am, ianG wrote: For some reason, news.google.com has been captured by *.opendns.com and turned into a site warning. OK, so I imagine there is a story about this somewhere, maybe it's just my ISP... But, imagine my surprise when I tried it on chrome and I

Re: oddball, old cipher suite in firefox client hello

On Fri, November 1, 2013 5:30 pm, Wan-Teh Chang wrote: On Fri, Nov 1, 2013 at 1:28 AM, Jeff Hodges j...@somethingsimilar.com wrote: I dug through the NSS codebase and found where it was defined in lib/ssl/sslproto.h as: /* New non-experimental openly spec'ed versions of those

Re: Removal of generateCRMFRequest

On Fri, September 27, 2013 10:29 am, Eddy Nigg wrote: On 09/27/2013 08:12 PM, From Brian Smith: My question is not so much Is anybody using this functionality but rather What really terrible things, if any, would happen if we removed them? We might have to look for alternatives because

Re: Removal of generateCRMFRequest

On Fri, September 27, 2013 1:35 pm, Eddy Nigg wrote: On 09/27/2013 08:52 PM, From Ryan Sleevi: How do you deal with this in other browsers? Well, I don't...so far :-) However I'm aware of similar capabilities with IE. What are the specific features that you need? Detection

Re: Removal of generateCRMFRequest

On Fri, September 27, 2013 2:22 pm, Eddy Nigg wrote: On 09/27/2013 11:52 PM, From Ryan Sleevi: Let me try it differently: What actions do you take on this information? Terminating a current session or triggering authentication to a new session. When you define session, what do you mean

Re: Removal of generateCRMFRequest

On Fri, September 27, 2013 3:46 pm, Eddy Nigg wrote: On 09/28/2013 12:45 AM, From Ryan Sleevi: NSS already performs checking that the given smart card used to authenticate is present whenever encrypting or decrypting data. This includes cached session resumption as well. Not SSL session

Re: Removal of generateCRMFRequest

On Fri, September 27, 2013 4:09 pm, Eddy Nigg wrote: On 09/28/2013 01:59 AM, From Ryan Sleevi: If your site requires a client certificate, and you know that a client certificate is stored in a smart card, then you also know that when using Firefox, and the smart card is removed, Firefox

Re: Removal of generateCRMFRequest

On Fri, September 27, 2013 4:09 pm, Eddy Nigg wrote: On 09/28/2013 01:59 AM, From Ryan Sleevi: If your site requires a client certificate, and you know that a client certificate is stored in a smart card, then you also know that when using Firefox, and the smart card is removed, Firefox

Re: Removal of generateCRMFRequest

On Fri, September 27, 2013 5:51 pm, Robert Relyea wrote: On 09/27/2013 05:01 PM, Ryan Sleevi wrote: On Fri, September 27, 2013 4:09 pm, Eddy Nigg wrote: On 09/28/2013 01:59 AM, From Ryan Sleevi: If your site requires a client certificate, and you know that a client certificate

[ANNOUNCE] NSS 3.15.2 Release

The NSS team has released Network Security Services (NSS) 3.15.2, which is a minor release. The HG tag is NSS_3_15_2_RTM. NSS 3.15.2 requires NSPR 4.10 or newer. Detailed release notes are available at https://developer.mozilla.org/en-US/docs/NSS/NSS_3.15.2_release_notes and reproduced below.

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

On Fri, August 16, 2013 6:36 am, Rob Stradling wrote: On 15/08/13 18:15, Chris Richardson wrote: 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

Re: Where is NSS used?

On Mon, July 8, 2013 12:00 pm, Rick Andrews wrote: I need to remove some 1024-bit roots from Firefox’s trust store, but I realize that these trusted roots are part of the NSS library, and that the NSS library is used by lots of other software, not just Firefox. Removing these roots may

[ANNOUNCE] NSS 3.14.3 Release

The NSS Development Team is pleased to announce the release of NSS 3.14.3. The official release notes are available at https://developer.mozilla.org/en-US/docs/NSS/NSS_3.14.3_release_notes , and are reproduced at the end of this message. This release includes mitigations for recently discussed

Re: Web Crypto API(s) and what Mozilla wants / needs

On Thu, February 14, 2013 10:43 am, Robert Relyea wrote: On 02/14/2013 07:54 AM, David Dahl wrote: - Original Message - From: Gervase Markhamg...@mozilla.org To: mozilla-dev-tech-cry...@lists.mozilla.org Cc: Eric Rescorlae...@mozilla.com, Brian Smithbsm...@mozilla.com, Brendan

Re: Web Crypto API(s) and what Mozilla wants / needs

On Thu, February 14, 2013 11:55 am, John Dennis wrote: On 02/14/2013 02:34 PM, Ryan Sleevi wrote: On Thu, February 14, 2013 10:43 am, Robert Relyea wrote: On 02/14/2013 07:54 AM, David Dahl wrote: - Original Message - From: Gervase Markhamg...@mozilla.org To: mozilla-dev-tech

Re: Proposing: Interactive Domain Verification Approval

On Mon, December 31, 2012 10:23 am, Kai Engert wrote: On Mon, 2012-12-31 at 16:26 +0100, Kai Engert wrote: I propose to more actively involve users into the process of accepting certificates for domains. I propose the following in addition: Each CA certificate shall have a single

NSS 3.14.1 release notes

The NSS Team is pleased to announce the NSS 3.14.1 release. Please read the NSS 3.14.1 release notes at: https://developer.mozilla.org/en-US/docs/NSS/NSS_3.14.1_release_notes Cheers, Ryan -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org

Re: duplicate SSL record in different TCP packets from a Google Drive client

On Mon, November 5, 2012 10:12 am, Peter Djalaliev wrote: Hello, There seems to be a possible problem with the SSL implementation used in Google Drive on MacOS 10.8.2. I seems that this SSL implementation is NSS - please let me know if you know that Google Drive uses a different SSL

Re: NSS 3.13.x ... releasenotes?

On Mon, October 29, 2012 8:32 am, Bernhard Thalmayr wrote: Hi all, sorry for this post, but I was not able to find the releasenotes for NSS version 3.13.x neither using Google nor querying the archive http://www.mozilla.org/projects/security/pki/nss/release_notes.html does not show

Re: NSS 3.13.x ... releasenotes?

release. Which version of NSPR are you using? Am 10/29/12 4:45 PM, schrieb Ryan Sleevi: On Mon, October 29, 2012 8:32 am, Bernhard Thalmayr wrote: Hi all, sorry for this post, but I was not able to find the releasenotes for NSS version 3.13.x neither using Google nor querying

Re: libnss x86 DRNG

On Mon, October 1, 2012 3:08 pm, Michael Demeter wrote: Hello, I work in the Open Source Technology group at Intel in the security group. I have been tasked with contacting the maintainer of libnss to start discussions about the possibility of Intel submitting patches to enable the new

Re: Building and running NSS for Android.

On Tue, July 10, 2012 12:32 pm, Robert Relyea wrote: On 07/09/2012 02:03 PM, Anders Rundgren wrote: Ian, Pardon me if I was a bit terse in my response. What I meant was simple that Operating Systems manage critical resources but only occasionally keys. That is, access to persistent

Re: libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)

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

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

(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

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

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

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

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

RE: Question about pathlen extension checked

My reading of RFC 3280/5280 and from implementation experience with NSS, CryptoAPI, OpenSSL, and other implementations is that no, that is not correct. CA:TRUE with a pathlen:0 is conformant to RFCs 3280/5280. The most common cause for this would be for a CA certifying an intermediate, but that

RE: Question about pathlen extension checked

On 09/18/2011 03:15 AM, Ralph Holz (TUM) wrote: Hi, does NSS check the pathlength extension in an issuing certificate? yes. I am particularly wondering if pathlen:0 is honoured. According to the spec, which means no limit. NSS limits the size of the total chain to prevent loop

RE: Certificate login in Firefox - how does it work?

-Original Message- From: dev-tech-crypto-bounces+ryan- mozdevtechcrypto=sleevi@lists.mozilla.org [mailto:dev-tech-crypto- bounces+ryan-mozdevtechcrypto=sleevi@lists.mozilla.org] On Behalf Of Matej Kurpel Sent: Sunday, November 28, 2010 11:24 AM To: mozilla's crypto code

RE: Certificate login in Firefox - how does it work?

On 2010-11-26 13:20 PDT, ryan-mozdevtechcry...@sleevi.com wrote: [snip] And to save you a bit of trouble/pain: for CryptoAPI, you cannot simply sign raw data - you can only sign previously hashed data. I understand this to mean that you cannot write a pure PKCS#11 - CryptoAPI mapper,

RE: Fwd: Hi, I have three questions about embed bank CA cert in Firefox

-Original Message- From: dev-tech-crypto-bounces+ryan- mozdevtechcrypto=sleevi@lists.mozilla.org [mailto:dev-tech-crypto- bounces+ryan-mozdevtechcrypto=sleevi@lists.mozilla.org] On Behalf Of Gervase Markham Sent: Wednesday, July 21, 2010 1:22 PM To:

RE: Restricting SSL cert issuance within specified domain

That's great news! Is there a corresponding bug number or other way I can track the progress to see which version of NSS it gets into? https://bugzilla.mozilla.org/show_bug.cgi?id=394919 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org