518787 - Add GOST crypto algorithm support in NSS

Status: RESOLVED WONTFIX

(NSS :: Libraries, enhancement)

Description

[Konstantin Andreev]

User-Agent:       Mozilla/5.0 (X11; U; SunOS i86pc; ru; rv:1.9.1b2) Gecko/20090209 Firefox/3.1b2
Build Identifier: 

"GOST" is an acronym which means "Russian Federation National Standard". Among other, GOSTs specify a set of cryptoalgorithms, which mandated for use in government organizations and "working for government" organizations.

At the moment, a few commercial, closed-source, generic-purpose software packages with GOST crypto are available, mainly for Windows platform. Some specific, non-standard packages available for Unix platforms.

There is a big demand in support of the GOST algorithms by open-source, verifiable, industry-standard library and applications.

Let support the GOST cryptoalgorithms in Mozilla.

Reproducible: Always

Comment 1

[Konstantin Andreev]

Attachment: Patch allows to import and verify GOST X.509 certificates.

Comment 2

[Konstantin Andreev]

Attachment: GOST X.509 test root certificate.

Comment 3

[Konstantin Andreev]

Attachment: GOST X.509 test individual certificate.

Comment 4

[Konstantin Andreev]

I have passed the 1st milestone in adding GOST cryptoalgorithms to Mozilla. This patch allows import and verification of the GOST X.509 certificates into the NSS softoken.

User perspective:
  - import GOST X.509 root, then individual certificates via PSM GUI. Certificates are accepted and verified.

Standards support perspective:
  - pkcs#11 v2.30: CKM_GOSTR3410, CKM_GOSTR3411 mechanisms
  - RFC4491: complete for non-legacy GOST R 34.10-2001 part.
  - RFC4357: what applicable for X.509 verification.

This patch has been tested at Sun Solaris 10: x86 (little-endian) and Sparc (big-endian). NSS/NSPR/Thunderbird were built by Sun Studio compilers (Sun Ceres C,C++ 5.10 2009/03/06).

Here are two test GOST X.509 certificates for experiments.

Please, review.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

I confirm that this is an enhancement request.  :)

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Konstantin, 
Is there some product that uses NSS, whose developers have agreed to either
a) develop a modification to their product to make it use GOST, once GOST 
is in NSS, or 
b) to accept a patch to their product to make it use GOST, once GOST is in 
NSS?

Is it your intention to get GOST into Firefox and/or Thunderbird?
If so, have you filed Requests For Enhancement (RFEs) on those products?
Have the developers of those products indicated their willingness to do that?

I ask these questions because, before we go to all the work to include GOST
in NSS, we want to be sure it will actually be used.

Comment 7

[Konstantin Andreev]

The final goal is a GOST crypto in Thunderbird.

-- as minimum: S/MIME with GOST to secure mail itself.
-- as maximum: TLS with GOST to secure servers' connections.

I havn't filed RFE for Thunderbird yet. I believe there should be foundation in NSS before I could do this. I can file the RFE if you advice. Should I ?

I do not expect Thunderbird developers will implement GOST support. But I cherish the hope they will accept a patch for this.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Yes, please do file the Thunderbird RFE, and have that discussion with the 
Thunderbird folks.  I would not _assume_ that they will accept that patch.
They have not yet accepted the patches attached to bug 380624 and bug 386313.

Is email the only market for GOST?  
If Firefox supported GOST, would there be web sites that would use it?

Comment 9

[Konstantin Andreev]

> Yes, please do file the Thunderbird RFE, and have that discussion with the Thunderbird folks.

I have filed bug 519432, waiting for feedback.

> I would not _assume_ that they will accept that patch. They have not yet accepted the patches attached to bug 380624 and bug 386313.

Too bad... I have read these discussions, - it seems the Thunderbird development is a bit stagnated.

Anyway, I need to provide the GOST in Thunderbird to my customers regardless of whether Thunderbird folks will accept/freeze/reject a GOST patch. I intend to make it publicly available.

> Is email the only market for GOST? 
GOST for email (== Thunderbird) is what is most asked on the forums. 

> If Firefox supported GOST, would there be web sites that would use it?

I do not pay much attention to this issue, but certainly there are web sites that use GOST. 

E.g. CryptoPro (r) is selling CSP with GOST support for TLS (http://www.cryptopro.ru/cryptopro/products/csp/tls.htm), and there are people asking for support for IIS on their forums (http://www.cryptopro.ru/cryptopro/forum2/Default.aspx?g=posts&t=1542)

CryptoCom (r) is selling closed-source GOST engine for openssl (http://www.cryptocom.ru/cryptopacket.html), and provides patches for Apache mod_ssl.

Comment 10

[Jo Hermans]

bug 520830 mentions that <https://cert.taxcom.ru/ui/> uses GOST

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 402797 [details] [diff] [review]
Patch allows to import and verify GOST X.509 certificates.

Bob, 
Is lib/util/pkcs11t.h frozen for FIPS? 

Konstantin,
First, I apologize for taking so long to begin this review. 
Thanks for submitting CVS diffs against the CVS trunk HEAD.  

As you may know, there is some controversy about adding GOST to NSS's 
"softoken" PKCS#11 module.  I personally do not oppose adding it there, 
but the need to freeze the code that implements the FIPS-validated 
algorithms does present some problems, and it would help a lot if new 
non-FIPS algorithms could be added to a different PKCS#11 module.  

It will help us to get this through the process if you break this patch 
down into a number of smaller patches.  I suggest you produce 4 patches, 
divided along these lines;

1) patch to nss/lib/util
2) patch to nss/lib/freebl and nss/lib/softoken
3) patch to the rest of nss/lib/*
4) patch to nss/cmd and nss/test

We may be able to give positive review approval to some of these while 
others are still being decided.  

We cannot accept the patches that implement the new algorithms without 
enhancements to the test scripts to test the new algorithms.  That means 

- blapitest must be enhanced to test the new freebl functions
- the PKCS#11 test programs must be enhanced to test new PKCS#11 mechanisms
- the test scripts that invoke those test programs must be enhanced to 
invoke those programs in such a way that they test the new algorithms.

and at the higher layers

- the SSL test scripts must be enhanced to test the new SSL cipher suites,
- the CMS (SMIME) test programs (e.g. cmsutil) may (probably must) be 
enhanced.
- the SMIME test scripts will need to be enhanced

Now here are some comments about the part of the present patch that affects
nss/lib/util

1) The file utilrename.h and its #defines are used ONLY for functions that
have previously existed in some other NSS shared library and are moved to 
libnssutil.  For new functions that are created initially in libnssutil,
we do not use the renaming scheme.  That means that we do not add the 
_Util suffix to the function names exported from libnssutil for them.

2) Regarding the new macro BITLEN_TO_OCTETLEN, to avoid namespace 
pollution, let's give it an NSS_ prefix.  I'd also suggest a shorter
name such as NSS_BITS_TO_BYTES or NSS_BITS_TO_OCTETS.

Comment 12

[Konstantin Andreev]

Hello, Nelson.

Thank you for review. 

This patch is "1st milestone" patch, thereby incomplete and expected to have many issues. The whole work should be pretty big, so it's very important to get some feedback in advance, to catch the issues early.

Concerning lib/util/pkcs11t.h: if it's frozen, I can workaround, but is it frozen forever ? The algorithms in question do not benefit from FIPS validation, we can add them to NSS release which is not FIPS-validated yet.

Comment 13

[Robert Relyea]

It won't be frozen forever, we do have a branch we are collecting changes that will go in when we validate again, but the time frame is at least 12-18 months (we just "finished" our last validation).

We don't release from that branch. This is why I was encouraging not depending on adding code to softoken, though it is clearly more difficult for GOST than other algorithms, since GOST includes assymetric algorithms which keys that should be stored in the softoken DB.

bob

Comment 14

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I understand the desire for GOST in NSS and in products like Thunderbird and Firefox.

Is the Russian government insisting on only allowing GOST (like Korea does with SEED), or does the Russian government also allow other algorithms like AES (like Japan does)? Does it depend on use (e.g. government vs. banking vs. other civilian uses)? IMO, we should see an authoritative reference stating the regulations one way or the other, plus the deadlines given by GOST for moving to these algorithms (if any), so we can prioritize GOST support. There are a lot of Firefox users in Russia already, and that leads me to believe that Russian websites are allowed to use security technologies already built into Firefox.

Comment 15

[Konstantin Andreev]

(In reply to comment #14)
> I understand the desire for GOST in NSS and in products like Thunderbird and
> Firefox.
> 
> Is the Russian government insisting on only allowing GOST (like Korea does with
> SEED), or does the Russian government also allow other algorithms like AES
> (like Japan does)? Does it depend on use (e.g. government vs. banking vs. other civilian uses)? 

In Russia, the use of the GOST algorithms is one of the preconditions for your electronic signature could take a legal effect.

The ordinal civilian is allowed to use any crypto at his will. But, say, his non-GOST electronic signature is repudiable and isn't eligible for court examination.

Conversely, any entity, whose activity has a legal effect (bank, pension fund, tax inspectorate, proprietary organization or civilian) and involves crypto operations, is mandated to use crypto facilities, certified by Federal Security Service. These facilities, of course, can use only GOST algorithms.

> IMO, we should see an authoritative reference stating the
> regulations one way or the other,

The authoritative references, I can find, are all in Russian. If you are interested in, please, confirm.

> plus the deadlines given by GOST for moving
> to these algorithms (if any), so we can prioritize GOST support. There are a
> lot of Firefox users in Russia already, and that leads me to believe that
> Russian websites are allowed to use security technologies already built into
> Firefox.

Unfortunately, the GOST algorithms are mostly available in commercial software:

  - some CryptoAPI CSP @ MS Windows
  - two or, maybe, three proprietary builds of Mozilla (vendor-specific PCKS#11 and patched higher levels of NSS) for Linux @ X86.
  
(the only free alternative is openssl >= 1.0, but I am not sure either web-browser or e-mail client using it).

The decent web-site won't require you to buy Windows and buy 3rd party CSP before visiting it :) Thus, Russian web-sites use American crypto where visiting shouldn't have a legal effect.

Sadly, some Russian web-sites use American crypto where they shouldn't. Thus, some banks use American crypto to protect Internet-banking, because customers strongly dislike buying 3rd party CSP.

I suppose, it is unfair, that electronic transaction with even government organization requires commercial software, without free alternative. So, the project for adding GOST in NSS was initiated.

Thanks NSS team, - the project gets decent attention, when required.

The project gets stalled, but not because of lack of development, or lack of interest. The PKCS#11 standard for GOST algorithms is not approved yet and unstable, - there is a disunity between PKCS#11/GOST designers.

I am not sure, how long this situation will persist :(  Maybe, NSS team will approve vendor-defined PKCS#11 extentions for GOST algorithms ?

Comment 16

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to comment #15)

> Conversely, any entity, whose activity has a legal effect (bank, pension fund,
> tax inspectorate, proprietary organization or civilian) and involves crypto
> operations, is mandated to use crypto facilities, certified by Federal
> Security Service. These facilities, of course, can use only
> GOST algorithms.

I understand that GOST is a standards organization like the US NIST. NIST recommends/allows several different algorithms for different purposes. What I was asking is this: besides these particular algorithms, are there any other algorithms referenced in the same regulations that are allowed for the same purposes?

And, if we have an implementation of these algorithms, would that implementation need to be validated/certified by some Russian government organization, in order to be considered suitable for the uses that require these algorithms? (In the US we have FIPS 140-2 validation, which is required for implementations that are to be used for certain US government purposes.)

> The authoritative references, I can find, are all in Russian. If you are
> interested in, please, confirm.

Yes, this is fine. I can bother some of my Russian-reading peers to help me with the translation.

>   - two or, maybe, three proprietary builds of Mozilla (vendor-specific 
>     PCKS#11 and patched higher levels of NSS) for Linux @ X86.
>
> The decent web-site won't require you to buy Windows and buy 3rd party CSP
> before visiting it :)

These are the specific things that I would like to avoid. It is great that people are customizing our product for their own needs, but it would be great if they could also use the official Firefox builds.

> Thus, Russian web-sites use American crypto where
> visiting shouldn't have a legal effect.
>
> Sadly, some Russian web-sites use American crypto where they shouldn't. Thus,
> some banks use American crypto to protect Internet-banking, because customers
> strongly dislike buying 3rd party CSP.

This doesn't cause any problems, right? If a website can choose widely-approved algorithms that are already built into NSS, Windows, and other software, then that is the easiest and cheapest solution. 

> I am not sure, how long this situation will persist :(

People are interested in the problem but there are many complications.

One complication is that have a situation where some Korean websites need a particular algorithm (SEED) and some CIS websites apparently need another (GOST). But, neither SEED nor GOST are approved/recommended by standards groups in other parts of the world. I think we (Mozilla) need to investigate ways of enabling/disabling these country/region-specific ciphers in some region-specific way. 

A second complication has to do with where the code should live. There is some desire to have region-specific algorithms outside of FreeBL/Softoken to simplify and reduce costs associated with some certifications, specifically FIPS 140-2 validation.

I am very interested to know why, if these algorithms are critical in the CIS market, nobody else (Apple, Microsoft) is implementing them. IP concerns? Security concerns? Other acceptable workarounds exist?

Comment 17

[Konstantin Andreev]

(In reply to comment #16)
> (In reply to comment #15)
> > Conversely, any entity, whose activity has a legal effect (bank, pension fund,
> > tax inspectorate, proprietary organization or civilian) and involves crypto
> > operations, is mandated to use crypto facilities, certified by Federal
> > Security Service. These facilities, of course, can use only GOST algorithms.
>
> I understand that GOST is a standards organization like the US NIST.

To be exact, "GOST" is an acronim, meaning "state standard specification". There is no a single standards authoring organization, but there is a single approving organization.

> NIST recommends/allows several different algorithms for different purposes. What
> I was asking is this: besides these particular algorithms, are there any other
> algorithms referenced in the same regulations that are allowed for the same purposes?

No, there are not. Only GOST's are approved for use in crypto facilities. To be exact, there are three ones:

  GOST 28147-89      [RFC5830]
  GOST R 34.11-94    [RFC5831]
  GOST R 34.10-2001  [RFC5832]

RFCs, indicated in brackets, are informational and contain more or less accurate expositions.

> And, if we have an implementation of these algorithms, would that
> implementation need to be validated/certified by some Russian government
> organization, in order to be considered suitable for the uses that require
> these algorithms? (In the US we have FIPS 140-2 validation, which is required
> for implementations that are to be used for certain US government purposes.)

Exactly, implementation should be certified by Federal Security Service.

> > Thus, Russian web-sites use American crypto where
> > visiting shouldn't have a legal effect.
> >
> > Sadly, some Russian web-sites use American crypto where they shouldn't. Thus,
> > some banks use American crypto to protect Internet-banking, because customers
> > strongly dislike buying 3rd party CSP.
>
> This doesn't cause any problems, right? If a website can choose widely-approved
> algorithms that are already built into NSS, Windows, and other software, then
> that is the easiest and cheapest solution.

Even if web-site can choose (is allowed), I see at least this problem: the Russian web-sites should use foreign CA's because domestic CA's are limited by GOST crypto.

If one or both parties of HTTP or e-mail communication are obliged to use GOST crypto, then both are typically locked in MS Windows software + 3rd party commercial CSP. This may be costly or inappropriate in other ways.

> People are interested in the problem but there are many complications.
>
> One complication is that have a situation where some Korean websites need a
> particular algorithm (SEED) and some CIS websites apparently need another
> (GOST). But, neither SEED nor GOST are approved/recommended by standards groups
> in other parts of the world.

IMO, you are mistaken.

  SEED: ISO/IEC 18033-3:2005
       http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=37972

  GOST R 34.10-2001: ISO/IEC 14888-3:2006/Amd 1:2010
       http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=53613

  GOST 28147-89: ISO/IEC 18033-3 (not published yet)
       At long last has been approved for inclusion on Oct 2010 at 41st meeting of ISO/IEC/JTC1/SC27/WG2.

To the moment, GOST R 34.11-94 is not approved by SC27, but, I believe, SC27 will reexamine it later.

I believe, you can trust ISO experts, they do careful investigation of algorithms before inclusion in the standards track.
 
> I think we (Mozilla) need to investigate ways of enabling/disabling these
> country/region-specific ciphers in some region-specific way.

I see no objections against enabling/disabling certain crypto mechanisms. But, IMO, "region-specific" approach is unhappy. There should be either fine-grained mechanism-by-mechanism approach, of "certification-specific" (FIPS/FSS/...) one.

> A second complication has to do with where the code should live. There is some
> desire to have region-specific algorithms outside of FreeBL/Softoken to
> simplify and reduce costs associated with some certifications, specifically
> FIPS 140-2 validation.

As far as I remember, Robert told that new mechanisms should reside outside NSS 3.12 softoken, because this softoken is frozen, because FIPS-certified. There were not objections against including new mechanisms into NSS 3.13.

There is a reason to have GOST mechanisms in softoken. The use of GOST in e-mail and web requires the changes in NSS layers above PKCS#11, and layers above NSS. These changes are useless (impossible?) if there is no foundation in softoken. And, even if the softoken itself may not be FSS-certified, it becomes possible to use (with NSS) a commercial or hardware GOST token.

> I am very interested to know why, if these algorithms are critical in the CIS
> market, nobody else (Apple, Microsoft) is implementing them.

Not sure. Maybe, FSS certification concerns. Maybe, because demand for GOST algorithms is filled by commercial implementations.

> IP concerns?

No. AFAIK, GOST algorithms are completely patent-free, including signature on elliptic curves.

Comment 18

[Nelson Bolyard (seldom reads bugmail)]

Konstantin, thanks for your well written and informative comments. 

Questions about FSS: Is it a CIS body?  or Russian? or ??

Does it have a web site listing crypto implementations it has certified, 
similar to NIST's list of FIPS certified modules at 
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm ?

When a softoken cryptographic module is certified by FSS, does FSS then
expect that it will remain unchanged in order to retain its certification,
and that changes to that module, after it is certified, will necessitate 
a recertification or at least a an official review of the changes to the 
certified module to continue to claim certification (as with FIPS modules)?


IMO, you should not view softoken as being the ONLY PKCS#$11 module to be 
used by/with mozilla software.  Excluding algorithms from softoken should 
not be understood as excluding them from Firefox or Thunderbird, but rather
should be understood as expecting them to live in a different PKCS#11 module.

NSS even includes a "framework" with which other PKCS#11 modules can be 
easily implemnted by adding their crypto algorithms to that framework.
That's what "ckfw" is: CryptoKi FrameWork. 

Perhaps one day there will be a FIPS module that is periodically certified by NIST and frozen in between certifications, and a separate GOST module that 
is certified by FSS and likewise is frozen in between certifications, and 
perhaps even similar modules for Korea and Japan (although, at present, 
I am unaware of any certification bodies for SEED or Camellia).  

It would certainly simplify life for all concerned if we could all stop thinking in terms of a single monolithic crypto module, and begin thinking 
in terms of separate libraries for separate market segments.  

But I am also aware that presently Mozilla Corporation desires that Firefox 
be a monolith as much as possible, and disdains all crypto certification.
They would rather cast off all crypto certification than segregate certified code separately from non-certified code, so that one can be frozen and one
can remain thawed. (Brian, this is not a comment on you.)  

I will not be shocked to find there is NO separate softoken any more in a forthcoming Firefox release, because PKCS#11 has been abandoned and crypto algorithms have been directly absorbed into the monolith.  It remains to be seen whether that would increase or decrease the chances of GOST algorithms being included in Thunderbird or Firefox.

Comment 19

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to comment #17)
> No, there are not. Only GOST's are approved for use in crypto
> facilities. To be exact, there are three ones:
> 
>   GOST 28147-89      [RFC5830]
>   GOST R 34.11-94    [RFC5831]
>   GOST R 34.10-2001  [RFC5832]
> 
> RFCs, indicated in brackets, are informational and contain more or less
> accurate expositions.

I am aware of those and I even have access to translations of at least GOST 28147-89. But, I am interested in the actual regulations that say "you must use only GOST 28147-89 algorithms in these situations: [...]". For example, a Ukrainian friend found some summaries of the recommendations:

ukrainian regulations
http://www.dsszzi.gov.ua/dstszi/control/uk/publish/article;jsessionid=8CB156B71B12949DCF44DC7D55439F56?art_id=49049&cat_id=38837

russian regulations
http://ru.wikipedia.org/wiki/Криптография

Относительно юридических лиц и предпринимателей, желающих разрабатывать либо реализовывать криптосистемы, существуют п. 5―11 ст. 17 Федерального Закона от 08.08.2001 N 128-ФЗ «О лицензировании отдельных видов деятельности»
« 	

5) деятельность по распространению шифровальных (криптографических) средств;
6) деятельность по техническому обслуживанию шифровальных (криптографических) средств;
7) предоставление услуг в области шифрования информации;
8) разработка, производство шифровальных (криптографических) средств, защищенных с использованием шифровальных (криптографических) средств информационных систем, телекоммуникационных систем;
10) деятельность по разработке и (или) производству средств защиты конфиденциальной информации;
11) деятельность по технической защите конфиденциальной информации;

> Exactly, implementation should be certified by Federal Security Service.

Here is my understanding:

1. Some laws require only GOST algorithms be used.
2. Some websites (especially government websites in Russia) follow these laws.
3. These same laws require that the implementations of the GOST algorithms be certified by the Federal Security Service in Russia and probably by analogous agencies in neighboring countries.
4. An implementation of the GOST algorithms without such certification may or may not be a criminal offense.
5. A website that tries to comply with these regulations will have certificate chains that use only GOST-approved hash and signature algorithms. In other words, no existing CA root certificates would work for these websites.

Obviously, #4 is a big concern. It is expensive just to do the legal research to find out whether we need to do the FSS certification and/or how much it costs. And, #5 means that we probably need to have GOST-enabled CA root certificates in the root cert store, in order for a GOST implementation to make sense. Therefore, the alternative implementation strategy of third-party (hopefully open source) PKCS#11 module seems to make much more sense. But, I am not sure we will (always) support third-party PKCS#11 modules in Firefox Mobile. At the same time, we don't want people distributing hacked versions of Firefox Mobile just to get this support included. And, we would like to have some influence on the quality control of the open-source PKCS#11 module supporting GOST if we are going to suggest people add it. Lots of complications. :(

At any rate, there is no way this can happen for FF4.0 unfortunately. And, I cannot devote much time to non-FF4.0 issues until after FF4.0 ships.


> Even if web-site can choose (is allowed), I see at least this problem: the
> Russian web-sites should use foreign CA's because domestic CA's are limited by
> GOST crypto.

Russian CAs should file inclusion requests if they want this to be remedied. 

> http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=37972
> http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=53613
> 
>   GOST 28147-89: ISO/IEC 18033-3 (not published yet)
>        At long last has been approved for inclusion on Oct 2010 at 41st meeting
> of ISO/IEC/JTC1/SC27/WG2.
> 
> To the moment, GOST R 34.11-94 is not approved by SC27, but, I believe, SC27
> will reexamine it later.

Thank you. That is very helpful to know.

> Not sure. Maybe, FSS certification concerns. Maybe, because demand for GOST
> algorithms is filled by commercial implementations.
> 
> > IP concerns?
> 
> No. AFAIK, GOST algorithms are completely patent-free, including signature on
> elliptic curves.

:(

Thank you very much for your help. I understand the issues around this much better now.

Comment 20

[Mike]

Hi to All. Why until now this patch is not included in the upstream? Which reasons?

Comment 21

[Mike]

This patch is out of date. Need a new patch. And please include it in the upstream.

Patch #99 (gost.patch):
+ /usr/bin/patch -p0 -b --suffix .gost --fuzz=0
+ /usr/bin/cat /home/mikhail/rpmbuild/SOURCES/gost.patch
patching file ./mozilla/security/nss/cmd/p7sign/p7sign.c
Hunk #1 succeeded at 73 (offset -32 lines).
patching file ./mozilla/security/nss/cmd/p7verify/p7verify.c
Hunk #1 succeeded at 63 (offset -32 lines).
patching file ./mozilla/security/nss/cmd/signtool/sign.c
Hunk #1 succeeded at 604 (offset -32 lines).
patching file ./mozilla/security/nss/lib/certdb/certdb.c
Hunk #1 succeeded at 1241 (offset -107 lines).
Hunk #2 FAILED at 1554.
1 out of 2 hunks FAILED -- saving rejects to file ./mozilla/security/nss/lib/certdb/certdb.c.rej
patching file ./mozilla/security/nss/lib/cryptohi/keyi.h
Hunk #1 succeeded at 19 (offset -33 lines).
patching file ./mozilla/security/nss/lib/cryptohi/keythi.h
Hunk #1 FAILED at 49.
Hunk #2 succeeded at 119 (offset -5 lines).
Hunk #3 succeeded at 139 (offset -5 lines).
Hunk #4 succeeded at 208 (offset -3 lines).
1 out of 4 hunks FAILED -- saving rejects to file ./mozilla/security/nss/lib/cryptohi/keythi.h.rej
patching file ./mozilla/security/nss/lib/cryptohi/sechash.c
Hunk #1 succeeded at 8 (offset -32 lines).
Hunk #2 FAILED at 75.
Hunk #3 succeeded at 92 (offset -27 lines).
Hunk #4 succeeded at 103 (offset -27 lines).
Hunk #5 succeeded at 114 (offset -27 lines).
Hunk #6 succeeded at 125 (offset -27 lines).
Hunk #7 succeeded at 136 (offset -27 lines).
Hunk #8 succeeded at 147 (offset -27 lines).
Hunk #9 FAILED at 184.
Hunk #10 succeeded at 189 (offset -15 lines).
Hunk #11 FAILED at 297.
Hunk #12 succeeded at 291 (offset -13 lines).
Hunk #13 succeeded at 304 (offset -13 lines).
Hunk #14 succeeded at 318 (offset -13 lines).
3 out of 14 hunks FAILED -- saving rejects to file ./mozilla/security/nss/lib/cryptohi/sechash.c.rej
patching file ./mozilla/security/nss/lib/cryptohi/seckey.c
Hunk #1 FAILED at 146.
Hunk #2 FAILED at 984.
Hunk #3 succeeded at 548 (offset -453 lines).
Hunk #4 succeeded at 567 (offset -453 lines).
Hunk #5 FAILED at 1127.
Hunk #6 succeeded at 1010 (offset -517 lines).
Hunk #7 succeeded at 1136 (offset -562 lines).
3 out of 7 hunks FAILED -- saving rejects to file ./mozilla/security/nss/lib/cryptohi/seckey.c.rej
patching file ./mozilla/security/nss/lib/cryptohi/secsign.c
Hunk #1 succeeded at 97 (offset -34 lines).
patching file ./mozilla/security/nss/lib/cryptohi/secvfy.c
Hunk #1 FAILED at 137.
Hunk #2 succeeded at 282 (offset -26 lines).
Hunk #3 succeeded at 336 (offset -19 lines).
Hunk #4 FAILED at 404.
Hunk #5 succeeded at 409 (offset -17 lines).
Hunk #6 succeeded at 445 (offset -17 lines).
Hunk #7 succeeded at 511 (offset -17 lines).
Hunk #8 succeeded at 577 (offset -17 lines).
2 out of 8 hunks FAILED -- saving rejects to file ./mozilla/security/nss/lib/cryptohi/secvfy.c.rej
patching file ./mozilla/security/nss/lib/freebl/alghmac.c
Hunk #1 succeeded at 55 (offset -32 lines).
patching file ./mozilla/security/nss/lib/freebl/blapi.h
Hunk #1 succeeded at 343 (offset 85 lines).
Hunk #2 FAILED at 1036.
1 out of 2 hunks FAILED -- saving rejects to file ./mozilla/security/nss/lib/freebl/blapi.h.rej
patching file ./mozilla/security/nss/lib/freebl/blapit.h
Hunk #1 FAILED at 88.
Hunk #3 succeeded at 111 (offset 1 line).
Hunk #4 succeeded at 216 (offset 24 lines).
Hunk #5 succeeded at 235 (offset 26 lines).
Hunk #6 succeeded at 330 (offset 26 lines).
Hunk #7 succeeded at 401 (offset 26 lines).
1 out of 7 hunks FAILED -- saving rejects to file ./mozilla/security/nss/lib/freebl/blapit.h.rej
patching file ./mozilla/security/nss/lib/freebl/ec.c
Hunk #1 FAILED at 96.
Hunk #2 FAILED at 922.
Hunk #3 succeeded at 136 (offset -951 lines).
2 out of 3 hunks FAILED -- saving rejects to file ./mozilla/security/nss/lib/freebl/ec.c.rej
patching file ./mozilla/security/nss/lib/freebl/ec.h
Hunk #1 succeeded at 9 (offset -39 lines).
patching file ./mozilla/security/nss/lib/freebl/gost28147-priv.h
patching file ./mozilla/security/nss/lib/freebl/gost28147.c
patching file ./mozilla/security/nss/lib/freebl/gost3411.c
patching file ./mozilla/security/nss/lib/freebl/gost3411.h
patching file ./mozilla/security/nss/lib/freebl/gost3411i.c
can't find file to patch at input line 2035
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: security/nss/lib/freebl/hasht.h
|===================================================================
|RCS file: /cvsroot/mozilla/security/nss/lib/freebl/hasht.h,v
|retrieving revision 1.7
|diff -u -p -r1.7 hasht.h
|--- ./mozilla/security/nss/lib/freebl/hasht.h	10 Dec 2008 22:48:03 -0000	1.7
|+++ ./mozilla/security/nss/lib/freebl/hasht.h	24 Sep 2009 15:16:39 -0000
--------------------------
File to patch:

Comment 22

[ojab]

It's WONTFIXed because of lack of up2date patches or because it shouldn't be included?

Comment 23

[Sergey Yanovich]

(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #19)

Here is my understanding:

1. Some laws require only GOST algorithms be used.
2. Some websites (especially government websites in Russia) follow these
   laws.
3. These same laws require that the implementations of the GOST algorithms
   be certified by the Federal Security Service in Russia and probably by
   analogous agencies in neighboring countries.
4. An implementation of the GOST algorithms without such certification may
   or may not be a criminal offense.
5. A website that tries to comply with these regulations will have
   certificate chains that use only GOST-approved hash and signature
   algorithms. In other words, no existing CA root certificates would work for
   these websites.

Obviously, #4 is a big concern. It is expensive just to do the legal
research to find out whether we need to do the FSS certification and/or how
much it costs. And, #5 means that we probably need to have GOST-enabled CA
root certificates in the root cert store, in order for a GOST implementation
to make sense. Therefore, the alternative implementation strategy of
third-party (hopefully open source) PKCS#11 module seems to make much more
sense. But, I am not sure we will (always) support third-party PKCS#11
modules in Firefox Mobile. At the same time, we don't want people
distributing hacked versions of Firefox Mobile just to get this support
included. And, we would like to have some influence on the quality control
of the open-source PKCS#11 module supporting GOST if we are going to suggest
people add it. Lots of complications. :(

I did some research on #4, and here are the results for Russia:
A1. Possession of (and circulation of) crypto tools is not a criminal offense.
A2. A FSS license is required for either implementation, distribution or installation of crypto tools for profit. Failure to obtain such a license before engaging in any of this activities is a criminal offense (p. 171 of Criminal Code).
A3. A non-profit organization must also obtain a license, but its failure is a civil offense (p. 19.20 of Civil Offense Code).
A4. A private person doesn't need a license unless it is done for profit.
A5. Distribution of source code does not require license. Installation for own use is exempt from licensing (p.1 of License Regulation).
A6. NSS as a library is exempt from licensing if it is a part of a user-installable OS with open cryptographic specification (p.3 cl. g of License Regulation).
A7. NSS in Firefox is exempt from licensing as channel security software for non-critical infrastructure (p.3 cl. l of License Regulation).
A8. Absence of GOST implementation doesn't make a crypto tool exempt from licensing for implementation, binary distribution or installation.
A9. Certification is voluntarily.

There has been some changes in standards since the last patch. I can refresh patches if it can help to have GOST TLS in Firefox.

Comment 24

[Robert Relyea]

I think there has been a general move away from 'national crypto standards' at mozilla. Even Seed has been deprecated for mozilla NSS builds. It would be good for Ben or Martin to confirm this before Sergey goes to the work to refresh the patch. It wouldn't be fair to say 'the patch is out of date, so it's wontfix' followed by a new patch that either languishes or gets closed with 'we don't support national crypto standards' anymore. We probably be clear about the latter upfront.

bob

Comment 25

[ojab]

um, when we're gonna start removing _national_ institute of standards algorithms?
I guess it's Daniel J. Bernstein or nothing from now on?

Comment 26

[Sergey Yanovich]

... 'we don't support national crypto standards' anymore ...

This seems to contradict 'As of this writing, NSS is now being retested to be recertified for the fifth time' from [1].

It is becoming a necessity to have GOST TLS in the browser in Russia. Most personal interactions with government are now online. The legislation requires GOST DSA in some cases . When GOST DSA is required, GOST TLS is also required. This implies Windows OS, a proprietary DSA software and either Yandex browser, chromium-gost or a third party add-on for Firefox at the moment. I would prefer a free software stack, but there is none available.

'NSS was the first open source cryptographic library to be FIPS certified' [1]. Why not become the first for GOST? There will be no new attack surface if there is no GOST CA in Firefox.

1. https://firefox-source-docs.mozilla.org/security/nss/legacy/fips_mode_-_an_explanation/index.html