New Architecture and Design for
Mozilla Firefox
Mozilla Firefox has enabled multi-process
operations and phased out the add-on technology.
Mozilla recommends adopting the new web extension
and native messaging for the replacement of the addon technology. The first drafting of the architecture is
to connect the new web extension and native
messaging to the NSS library. However, there are user
certificates which released in the production with the
issues of missing ‘Netscape Cert Type’ field. These
user certificates are having difficulties in calling the
NSS libraries for signing function. In contrast, the
same user certificates function well with a nonMozilla web browser, i.e. Internet Explorer and
Google Chrome which opted for CryptoAPI and CSP
libraries.
The reason being is, the field of ‘Netscape Cert
Type’ is not a sensitive field to CryptoAPI library.
With the prementioned factors, the decision is to
revamp the design of digital signature solution from
add-on technology to extension and native messaging
technology. It involved the decision to drop the NSS
dan PKCS#11 libraries and to replace with the
CryptoAPI and CSP libraries. Thus, in order to
support Firefox 58 onwards, the new architecture is as
shown in Figure 7.
< Firefox 57 >
Firefox 58
Add-on
Extension and
Native
Messaging
NSS CryptoAPI
PKCS#11 CSP
Device Drivers
Figure 7: New Web Extension Architecture for Mozilla
Firefox
5. Digital Signature Ecosystem
With web extension technologies are built in silos,
the integration of web application to the digital
signature as a service demands for simplicity. The first
problem is the digital signature operation on multiple
web extensions technologies generates an
unstructured format of data and digital signature. The
integration requires a web application to provide
functionalities to receive unstructured data from
multiple web browsers and to format the unstructured
data to a structured data that is independent on the
type of web browser. The web application may be a
third-party software vendor who requires to provide a
digital signature as a service.
However, requesting for
the third-party software vendor to manage the
integration code may impede the delivery of the
digital signature solution.
The second problem is inevitable code changes in
web extension, forces code changes in the web
application that provides the digital signature as a
service. For example, if there is a new request to
support time stamping features and leads to the
upgrade of the web extension version, the web
application requires to add the new time stamping
parameter, manage the time stamping data and
supports the latest web extension version. The code
changes occur in multiple places due to the support of
multiple web browsers. If multiple software vendors
adopt the digital signature solution, the codes changes
must reflect on all code of software vendors
immediately.
The third problem is the chaos of web extension
installation in the client machine. Each of the web
extension has its installation policy. Each of the web
International Journal of Intelligent Computing Research (IJICR), Volume 10, Issue 3, September 2019 Copyright © 2019, Infonomics Society 1019
extension has its installation files; C++ and
JavaScript. For web security purposes, the web
extension should be selected from the web browser
extension store and manually install by users. In a
recent development, Google Chrome browser version
73 introduces a new group policy that enables an
administrator of an organisation to configure and
control instances of Google Chrome Browser [16].
This policy results in a seamless installation of the
browser extension, where it is configured to automate
the installation of browser extension to the user.
However, it seems to be unethical to install a web
extension without user’s permission.
In solving the prementioned issues, a general
JavaScript called ‘Web Signature Script’ lays in
between the web browser and web extension layers as
illustrated in Figure 8 is created. The purpose is to
simplify the digital signature integration. The script is
responsible for structuring data and the signature in
JSON format. The JSON format provides the content
secured messages with information of algorithm and
digital signatures. The JSON format acts as a
container to present the data to sign and the digital
signature and built-in JavaScript language.
The JSON format contains four important fields.
The first field is the payload which describes as the
value of the original message to be signed. The second
field is the protected which contains the algorithm
used to generate the signature. The supported signing
algorithms are RSA with hash algorithm SHA256,
and ECDSA with hash algorithm SHA256. The
protected fields contain the expiry of the data and the
signature timestamp. The third field is the header
which contains user certificate signing and the
certificate chain. The last field is the signature which
contain the signature of the digital signing. All
information is in Base64 format.
Despite multiple
selection of web browsers, the web application will
receive the JSON signature data format upon user
successfully perform digital signing.
The script manages the data format of each specific
web extension for each of the web browser. Any
additional of new features which requires new
parameter will be added in the script. The script
provides an abstraction API for the integration of
third-party software vendor to perform digital signing
and verifying digital signatures based on the JSON
format. The API provides uniform signing and
verification functions for all platforms and browsers.
The third-party software vendors will only require
including the web signature script in the web
application as JavaScript and perform either signing
or verification of signature with additional two lines
of codes. In case of a new updated version for the web
extension, the only requirement for the web
application developers is to replace the web signature
script with the latest version. Thus, the script should
offer minimal changes or effort for web application
developers.
For the digital signature solution, to support the
installation of web extensions in multiple web
browser, a standalone installer is created. The installer
is set to cater to the automatic installation process,
supports for manual installation of the web extensions
from the browser store and requires a user manual
agreement to set required security policy prior for
installation.
In summary, the digital signature ecosystem is
built based on client and server technology. The client
is a cross-platform web browser extension and a
minified Web Signature Script, which performs
signing of data, generates and verify the digital
signature on the web browser. In the future, the
extension and the native messaging framework will be
implemented for all web browser as in Figure 8. The
cryptographic libraries will be CryptoAPI and CSP.
The server is a Java library, which performs online
verification of the digital signature and the certificate.