Announcement: Firefox Extension for Key Generation and Certificate Enrollment
Subrata Mazumdar
I would like bring to your attention of our firefox extension for
stand-alone key generation and enrollment.
The extension is available from "sandbox" in
https://addons.mozilla.org/en-US/firefox/. According to sandbox policy
rule, you have to register, login, and then subscribe for sandbox in
order to download any extensions from sandbox.
Title: KeyManager Tool: Firefox Extension for Key Generation and
Certificate Enrollment
KeyManager is a stand alone PKI tool for key generation and certificate
enrollment. The KeyManager tool is packaged as “chrome” based Firefox
extension. We have extended the Certificate Manager wizard in Mozilla
PSM and added the capability for key generation and SCEP based
certificate enrollment. Currently, PSM allows import and export of keys
but does not provide interface for local key generation. In addition,
the tool supports signing of proxy certificates for delegation of
authorities and provides XUL based GUI for signing archive files.
The KeyManager tool has following features:
- Generation of keys, signing self-signing certificate and generation of
PKCS#10 based Certificate Signing Requests (CSR)
(Uses XPCOM based interface for NSS commandline tool for
certutil/certcgi andr XUL based GUI)
- Signing of Proxy Certificate and other users' certificates
- SCEP based Certificate enrollment
- Signing of archive files (provides XUL based GUI for signtool in
Mozilla NSS)
- Generation of configuration file for OpenSSL based applications ; very
useful if are trying to use
OpenSC based engine for smartcard with OpenSSL
For more info: http://pubs.research.avayalabs.com/pdfs/ALR-2006-044.pdf
If you download and use the tool, please write a review. I need enough
review in order for the extension to be nominated for publicly available
extension.
Thanks.
--
Subrata Mazumdar
Subrata Mazumdar
- I forgot tomention, the "KeyManager" extension only works on Windows
and Linux.
If there is interest, I may be able to create a version for SUN-Solaris.
- addson.mozilla.org changed their policy - the extension is now
publicly available. You do not have to regsiter to download the extension.
Here is direct the URL for the extension page:
https://addons.mozilla.org/en-US/firefox/addon/4471
Still, please write review if you use the extension and give
comments using the discussion link on the extension page.
- if you are not really keen on learning Mozilla-NSS command line
utilities, such as certutil, pk12util, signtool etc., if you can use
this extension to do the same tasks. It presents XUL based forms for
various parameters.
-
Thanks,
--
Subrata
Nelson Bolyard
> Here is a follow-up to the original message:
> - I forgot tomention, the "KeyManager" extension only works on Windows
> and Linux.
> If there is interest, I may be able to create a version for SUN-Solaris.
> - addson.mozilla.org changed their policy - the extension is now
> publicly available. You do not have to regsiter to download the extension.
> Here is direct the URL for the extension page:
> https://addons.mozilla.org/en-US/firefox/addon/4471
> Still, please write review if you use the extension and give comments
> using the discussion link on the extension page.
> - if you are not really keen on learning Mozilla-NSS command line
> utilities, such as certutil, pk12util, signtool etc., if you can use
> this extension to do the same tasks. It presents XUL based forms for
> various parameters.
Subrata,
This all sounds very interesting. I would evaluate it if it worked with
my mozilla browser. I use SeaMonkey rather than FireFox.
Does your extension work with SeaMonkey?
Kyle Hamilton
are on Macs can actually compile it? Is this intended to be
proprietary?
-Kyle H
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
-Kyle H
Anders Rundgren
Although I find your extension interesting, I think that the on-line stuff
is nowhere ready. KeyGen, generateCRMFrequest, and Xenroll have
severe limitations which have made most large PKIs in the EU use
home-brewed PKI provisioning solutions. I am trying to create a
standard for this. It will be built on XML rather than ASN.1.
Here comes something related:
----- Original Message -----
From: "Anders Rundgren" <anders....@telia.com>
To: <ietf...@imc.org>
Sent: Saturday, March 31, 2007 08:32
Subject: netscape-cert-renewal-url & beyond
Although the "netscape-cert-renewal-url" certificate extension does
not appear to be incorporated in any PKIX RFC, it is anyway
documented in vendor specs like:
http://msdn2.microsoft.com/en-us/library/aa378149.aspx
I have two open questions regarding this particular extension:
1. Is it supported by any PKI-clients and if so which ones?
2. If it is not already supported on major scale wouldn't it be
worthwhile supporting such a facility? My personal experience
with certificates (I have had numerous), is that they tend to silently
expire, leaving you high and dry and concluding that "passwords are
better". When you have to "renew" from scratch you are thrown
into laborious processes which can take weeks to perform.
If you have certificate and key in a connected device
like a web-server or mobile phone, you could very well
create something like we already have with Windows update,
JRE update, Adobe update, where the user in some instances
only would have to issue a PIN in order to get a credential
update. For commercial certificates the process would be
slightly more complex but of course an auto-renewal-process
must support this use-case as well.
I do not propose making the Netscape extension a PKIX
standard but rather start discussing the road to a better
support of credential life-cycles.
Comments?
Anders Rundgren
Thanks,
--
Subrata
Kyle Hamilton
-Kyle H
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
-Kyle H
Subrata Mazumdar
which I got Mozilla source code.
I have submitted the modified version ( 0.0.2.20070330) under Mozilla
license yesterday.
Only reason I did not package the source with binary is that it would
increase the size of the XPI file.
Also, the directory structure is not as professional as some of the
other extensions. So, I was holding on to it until I can clean it up.
Now that I know there is interest I would package the source (IDL and
C/C++ files) it with the extension in the next release.
Thanks for your interest.
--
Subrata
s
Subrata Mazumdar
I agree with you totally. That is why I have another extension
(https://addons.mozilla.org/en-US/firefox/addon/4522) for XML digital
signature processing to support the all those on-line stuff. You would
still need the PKI based key generation stuff to support XML based
signature and encryption. I just wish that Mozilla DOM supported the
W3c standard for XML canonicalization - then I do not have to go outside
Mozilla code base.
What I do not like is that CA based key generation (as I explained in my
companion document) - I would only do that If I am required to submit a
CA-signed certificate by some service provider. I want to be in full
control on my keys at my side of the browser. I do not want a CA to
invalidate my key when I do not renew my subscriptin.
One my other goal is to support Key Continuity Management (KCM) as
specified by OLPC (One laptop per child) security spec. Hopefully I
would get time outside my day job to do it.
--
Subrata
Anders Rundgren
>Not XER?
You mean http://asf.gils.net/xer/ ?
Although XER would be possible, I intend to build this on the same
ground as WASP (http://webpki.org/WASP-tutorial.pdf ) and WebAuth
("TLS client-authentication killer") in order to create a "family" of matched
PKI-related browser subsystems, recently also including "Bounce" which
is a secure ("phishfree") browser redirect mechanism.
If we take PKCS #10 as an example, I don't see that converting it to XER
would from a CA's point of view be much easier coping with, than a
"pure" XML approach since both alternatives involve software upgrades.
The scheme I'm plotting with is also quite different than PKCS #10 since
it is designed for a web where you have sessions which enables multi-phase
designs that can make quite a difference to the provisioning process. Many
schemes that build on Xenroll already exploits this but I don't see Xenroll
as a suitable candidate for a standard compared to a clean XML request-
response scheme with no visible API. The main point with XML schema-
based protocols versus APIs is that you get a very robust definition and
that you don't have to leave potentially security-critical javascript code for
the provider (CA etc) to supply, all executes in static, locally trusted code
like for TLS-client-authentication. Additional advantages with XML
request-response schemes is the absence of HTML "bootstrap" pages
as well as independence from web page GUI.
Anders
----- Original Message -----
From: "Kyle Hamilton" <aero...@gmail.com>
To: "Anders Rundgren" <anders....@telia.com>
Cc: <dev-tec...@lists.mozilla.org>
Sent: Saturday, March 31, 2007 09:35
Subject: Re: Announcement: Firefox Extension for Key Generation and CertificateEnrollment
Not XER?
-Kyle H
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
-Kyle H
Subrata Mazumdar
No, it does not work on Seamonkey.
An old "contents.rdf" file (which I forgot to remove) also messes up the
browser's menu.
I should have tested it on Mozilla - sorry about that.
--
Subrata