Bad database message with NSS 3.9.2
John Simeone
Followed instructions in:
http://www.mozilla.org/projects/security/pki/nss/ref/ssl/gtstd.html
Initialized database with:
certutil -N -d c:\server_db
Cert directory after the above command contains:
secmod.db 16,384 bytes
cert8.db 65,536 bytes
key3.db 16,384 bytes
Generated two key pairs using:
certutil -G -g 2048 -d c:\server_db
certutil -G -g 2048 -d c:\server_db
Appears to work correctly, i.e. "Generating key. This may take a few
moments..."
Attempting to list the public keys using:
certutil -L -d c:\server_db
produces no output whatsoever but no errors. Just a return to the
command prompt.
Any attempt to go further and generate a cert request using the -R
command produces the message:
"certutil: NSS_Initialize failed: security library: bad database."
Can anyone suggest what is going on here and how to remedy the situation?
Thank you.
Nelson B
> Running NSS 3.9.2 OPT on Win2K SP4 with NSPR 4.4.1.
>
> Followed instructions in:
>
> http://www.mozilla.org/projects/security/pki/nss/ref/ssl/gtstd.html
That web page was written years ago, for a very old version of NSS,
NSS 2.7 (IRC). NSS now is on a new major version (current is 3.9),
and the certutil command works a little differently. Appears to me
that the documentation (specifically this page) hasn't kept up.
> Generated two key pairs using:
>
> certutil -G -g 2048 -d c:\server_db
> certutil -G -g 2048 -d c:\server_db
>
> Appears to work correctly, i.e. "Generating key. This may take a few
> moments..."
Did it ask you for your key DB password in there? If not, then
perhaps your key DB wasn't properly initialized with a password.
In that case, start over, delete your old cert and key DBs,
(back them up first if you like), and start over with
certutil -N again, and create a DB password. That may help.
> Attempting to list the public keys using:
>
> certutil -L -d c:\server_db
>
> produces no output whatsoever but no errors. Just a return to the
> command prompt.
>
> Any attempt to go further and generate a cert request using the -R
> command produces the message:
>
> "certutil: NSS_Initialize failed: security library: bad database."
>
> Can anyone suggest what is going on here and how to remedy the situation?
Please file a bug in bugzilla.mozilla.org against product NSS, component
tools (that may get changed as the bug is worked on), reporting exactly
your original text, and perhaps this reply too. Your bug may get changed
to a documentation bug if the NSS developers decide that the program is
right and the documentation is wrong. One of them is wrong, perhaps
both.
certutil is now capable of generating the key pair in the step that
creates the cert request. It appears to me that it is no longer
possible to explicitly specify which public key to use via an option
to the certutil -R command. It appears to me that certutil -R always
generates a new key pair.
By default, certutil -R generates a 1024-bit RSA key pair. You can
override the defaults through some options, e.g.
-k dsa -q pqgfile if you don't want RSA, or
-g 2048 if you want a different size key.
Perhaps we (NSS developers) should eliminate the old certutil -G feature,
if certutil has no way to use keys generated in that fasion. I think
we should either eliminate that old option, or fix it, and add an option
for certutil -R to enable users to explicitly specify a key pair, as they
could and did before NSS 3.4 (IINM).
> Thank you.
If you can read a shell script, you can see how the NSS automated test
scripts do all this stuff with the present certutil command, by looking in
http://lxr.mozilla.org/security/source/security/nss/tests/cert/cert.sh
Hope this helps.
--
Nelson B
J. Wren Hunt
Hash: SHA1
Nelson B wrote:
| That web page was written years ago, for a very old version of NSS,
| NSS 2.7 (IRC). NSS now is on a new major version (current is 3.9),
| and the certutil command works a little differently. Appears to me
| that the documentation (specifically this page) hasn't kept up.
|
I've run into the problem of 'stale' docs a few times on the Mozilla
site too and have been tempted to use the 'Edit page' link but didn't
know if it was good form to put a blurb at the top with something like
"NOTICE: This information is probably out of date - please see x". I
can volunteer to help maintain some of the pages if help is needed but I
don't think I'm qualified at this point to write new ones...
Wren
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
iD8DBQFCC8XbA/qR4Uok1vQRAjBEAKD7SCsAFM1owBvf3aURDMrtFiDHlQCfcVA4
HgyzQOAec64ustyNRO45d1c=
=hcSm
-----END PGP SIGNATURE-----
John Simeone
3.9.2.
I executed as per his directions a cert request and got a req file out.
When I went to self-sign it (using the -x option)so as to use it as the
Certificate Authority for subsequent certs, I got the message:
"self-signing a cert reqquest is not supported."
I have a Master cert generated by openssl that I can use to sign cert
requests.
Can I import this cert into the cert database?
Is so, must it be in p12 format?
Can I use the "certutil -A command" to add this Master cert?
If so, it lacks any documentation in the help display. Where can I find
a definition of the options for the Add command?
Thanks again.
John S.
Thanks to Nelson for the prompt reply.
I executed as per his directions a cert request and got a file out. When
I went to self-sign it (using the -x options)so as to use it as the
Certificate Authority for subsequent certs, I got the message:
"self-signing a cert reqquest is not supported."
I have a Master cert generated by openssl that I can use to sign cert
requests.
Can I import this cert into the cert database?
Is so, must it be in p12 format?
Can I use the "certutil -A command" to add the cert?
If so, it lacks any documentation in the help display. Where can I find
a definition of the options for the Add command?
Pete Collins
The easiest way to do it is like this:
$ mkdir db
$ certutil -N -d db
[enter your new db pass]
$ signtool -G mycert -d db -p"mypassword"
[answer the questions]
This will generate the files
x509.cacert x509.raw
The file x509.cacert can be posted on your web server so a user can
install it on their browser.
The problem here is this cert is temporary and lasts for only 3 months
I have been working on trying to create a root CA cert and create
signing certs from that certutil but to no avail. This is a RPITA I must
say.
Anyone have any docs that show how to *successfully* do this?
All I want to do is sing an xpi w/ a self signed cert that lasts more
than 3 months ...
I have all the command I am using logged if anyone is interested.
--pete
Nelson B
> I am trying to create a self signed cert:
> The file x509.cacert can be posted on your web server so a user can
> install it on their browser.
Pete, you've told us that you want to generate a self-signed CA cert,
and put it on a web site, and invite users to download it and trust it.
It's one thing for a developer to make a root CA cert for his own
testing, and quite another thing to put it on a web site and entice
others to download it and trust it.
Now, your intentions may be nothing but the best.
Or maybe you're working on the next MITM attack. I don't know.
But I know that if end users start willy-nilly downloading and
trusting CA certs they find on just any web site, it won't be long
before bad-guys are exploting that. The same people that do
phishing would be all over that like white on rice.
I support the request-for-(dis)enhancement at
https://bugzilla.mozilla.org/show_bug.cgi?id=276827
There are lots of good CAs out there now, including some very
inexpensive ones, and some free ones. There's no reason left,
IMO, for someone who cares about real security to be insisting
on using his own root CA certs, instead of using a real cert
from a legitimate CA.
--
Nelson B
Pete Collins
> Pete, you've told us that you want to generate a self-signed CA cert,
> and put it on a web site, and invite users to download it and trust it.
No what I'm talking about is not for general purpose consumption. More
like the intra/extranet cert I read about in the CA Cert docs. This is
for testing only.
But yes, it's obvious that malicious developers can do whatever they
want. 100% of all xpi packages out there now are all unsigned,
untrusted, unaudited, etc. Having it signed doesn't make a whole lot of
difference IMHO. A rouge extension needs to simply just be installed by
a user.
> But I know that if end users start willy-nilly downloading and
> trusting CA certs they find on just any web site, it won't be long
> before bad-guys are exploting that.
I hate to break the news to you, but currently users are "willy-nilly"
downloading extensions. So it seems to me that reality is a lot more
dangerous ...
--pete
Ian G
>> But I know that if end users start willy-nilly downloading and
>> trusting CA certs they find on just any web site, it won't be long
>> before bad-guys are exploting that.
>
>
> I hate to break the news to you, but currently users are "willy-nilly"
> downloading extensions. So it seems to me that reality is a lot more
> dangerous ...
Yup. I've never really figured out a nice way
to put this, but a lot of the security work that
was done in the 90s in the security area was
done in a vacuum - no real threat. So their
solutions weren't really tested...
Now there's a big threat. At the same time,
MF's products are shooting from irrelevant
up to potential challenger for the serious
#2 spot.
The next couple of years are going to be real
fun in the security area.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Gervase Markham
> But yes, it's obvious that malicious developers can do whatever they
> want. 100% of all xpi packages out there now are all unsigned,
> untrusted, unaudited, etc.
99%. Yahoo's latest toolbar beta is signed. :-)
Gerv
Nelson B Bolyard
> 100% of all xpi packages out there now are all unsigned,
> untrusted, unaudited, etc. Having it signed doesn't make a whole lot of
> difference IMHO. A rouge extension needs to simply just be installed by
> a user.
Today, with mozilla products, that is the case, because the browser does
not require signatures, and does not provide any incentive to the end
user to want or prefer signed XPIs.
In the older Netscape browsers, 100% were signed, because the browser
simply would not install any unsigned JARs.
I've been trying to get mozilla to go back to a model that offers
some protection to the users. There are a few of the core mozilla
developers who seem sympathetic. DougT is one.
A few more voices supporting that idea would help. As long as you
guys keep trashing the value of certs, as you do (you know who you
are), I doubt the situation will improve.
Nevertheless, in hope that someday mozilla will improve its use of PKI,
I plan to continue to resist helping those who knowingly thwart it.
/Nelson
Pete Collins
> Nevertheless, in hope that someday mozilla will improve its use of PKI,
> I plan to continue to resist helping those who knowingly thwart it.
Rest assured, I just registered the company w/ Verisign and our new
policy will be to sign every XPI we develop. :)
For me as a developer I'm not that worried about security for myself (I
actually don't install any extension I didn't develop), but for clients,
and their end users, you better believe that I want to ensure the
software we develop is what is actually being installed.
I agree w/ your point entirely. You don't want to "thwart" (no pun
intended) development of open source extensions, but it's not the
developer community we are concerned about, it is protecting end users.
This has only been a fairly recent development that Mozilla technologies
are becoming relevant to the main stream as Netscape once was.
Regards
--pete
Ian G
>
> I've been trying to get mozilla to go back to a model that offers
> some protection to the users. There are a few of the core mozilla
> developers who seem sympathetic. DougT is one.
(I don't know much about code apps.)
> A few more voices supporting that idea would help. As long as you
> guys keep trashing the value of certs, as you do (you know who you
> are), I doubt the situation will improve.
Certs are the only way that MF products
are going to deliver any security.
> Nevertheless, in hope that someday mozilla will improve its use of PKI,
> I plan to continue to resist helping those who knowingly thwart it.
I would support that view. In fact I have
spent the last week over on another
group (also madly debating the shmoo
bug) defending the PKI as being the only
way that this emerging situation can be
resolved.
Their view - which has some merit - is
that the PKI is a broken security design.
Their proposal is to rip it out and start
again (with their design). That has no
merit whatsoever, IMNSHO. None, zip,
nada, zilch.
Not using the certs in browsers and
servers is a non-starter.
Improving the way the PKI is used, now,
*there's* some room for potential.
Ian G
>
>> Nevertheless, in hope that someday mozilla will improve its use of PKI,
>> I plan to continue to resist helping those who knowingly thwart it.
>
>
> Rest assured, I just registered the company w/ Verisign and our new
> policy will be to sign every XPI we develop. :)
Where do I read more on this process? I want
to push Amir and Ahmad to get their TrustBar
signed. They already got quized on this by
the cryptography group, and it would be nice
to go the full distance.
Pete Collins
> Where do I read more on this process? I want
> to push Amir and Ahmad to get their TrustBar
> signed. They already got quized on this by
> the cryptography group, and it would be nice
> to go the full distance.
>
>
https://securitycenter.verisign.com/celp/enroll/retail
How Business Identity Authentication Works
http://www.verisign.com/products/authentication/howitworks.html
Useful Code Signing Docs:
Signing Software with Netscape Signing Tool 1.1
http://web.archive.org/web/20040224074221/http://developer.netscape.com/docs/manuals/signedobj/signtool/
Using the Certificate Database Tool
http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html
Signed XPInstalls
http://www.mail-archive.com/mozilla-...@mozilla.org/msg01096.html
I must say that after spending the better part of about two days of
pain, I can sign an xpi pretty fast now. I plan on integrating it into
our own internal build system once I get the keys from Verisign.
I think I will write up a doc on how to do this because I know next week
I will certainly forget.
--pete
--
Pete Collins - Founder, Mozdev Group Inc.
www.mozdevgroup.com
Mozilla Software Development Solutions
Pete Collins
http://www.mozdevgroup.com/docs/pete/Signing-an-XPI.html
I hope it can help ease the pain for some.
Regards
Duane
> A few more voices supporting that idea would help. As long as you
> guys keep trashing the value of certs, as you do (you know who you
> are), I doubt the situation will improve.
Since spyware is being signed that's supposed to make it ok?
--
Best regards,
Duane
http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://happysnapper.com.au - Sell your photos over the net!
http://e164.org - Using Enum.164 to interconnect asterisk servers
"In the long run the pessimist may be proved right,
but the optimist has a better time on the trip."
Ram...@gmail.com
VeriSign revokes certs for anyone who does not accurately disclose what
the software does. They've done it time and time again.
Duane
> I support the request-for-(dis)enhancement at
> https://bugzilla.mozilla.org/show_bug.cgi?id=276827
>
> There are lots of good CAs out there now, including some very
> inexpensive ones, and some free ones. There's no reason left,
> IMO, for someone who cares about real security to be insisting
> on using his own root CA certs, instead of using a real cert
> from a legitimate CA.
Sure there is, and if this ever did happen we'd just start rolling our
own copy of mozilla products to include our root cert... Not to mention
a lot of people don't trust those legitimate CAs and remove them from
their browser as a result...
Duane
And Verisign is the only CA allowed to issue code signing certs?
Ram...@gmail.com
> Ram...@gmail.com wrote:
> >>Since spyware is being signed that's supposed to make it ok?
> >
> >
> > VeriSign revokes certs for anyone who does not accurately disclose
what
> > the software does. They've done it time and time again.
> >
>
> And Verisign is the only CA allowed to issue code signing certs?
I'm ok with having several CAs competing on authentication policy,
revocation policy, SLA, and price.
I definitely feel better about installing software signed by someone
whose identity I know. The authentication of the software publisher,
signing of the software, and revocation status checking of the
publisher's certificate can mitigate significant risk.
--
My post and comments may represent my personal thoughts at the moment
but they should not be taken to represent anyone else.
Duane
> I'm ok with having several CAs competing on authentication policy,
> revocation policy, SLA, and price.
>
> I definitely feel better about installing software signed by someone
So basically what you are saying is you feel ok about installing spyware
just because it was signed, if it was inline with a CAs policy to allow
spyware to be signed...
Duane
> I definitely feel better about installing software signed by someone
> whose identity I know. The authentication of the software publisher,
> signing of the software, and revocation status checking of the
> publisher's certificate can mitigate significant risk.
If you know the person or company issuing the signed code this causes
the CA and PKI systems to be irrelevant, all you need to do is check the
fingerprints of the company signing it. PKI/CAs are supposed to allow
you to trust formerly unknown parties trust each other.
Ram...@gmail.com
> Ram...@gmail.com wrote:
>
> > I'm ok with having several CAs competing on authentication policy,
> > revocation policy, SLA, and price.
> >
> > I definitely feel better about installing software signed by
someone
>
> So basically what you are saying is you feel ok about installing
spyware
> just because it was signed, if it was inline with a CAs policy to
allow
> spyware to be signed...
Given a CA with a policy of requiring disclosure I can know if
something is spyware and choose to not install it.
Duane
> Given a CA with a policy of requiring disclosure I can know if
> something is spyware and choose to not install it.
But that would require a little more then black and white binary
security, it would also require some alterations to the way certs are
handled and without a lot of effort checking each CA out personally in
the list how will you ever know this? Or do you plan to disable all CAs
from being valid for code signing until you know one way or other?
Nelson Bolyard
> I would support that view. In fact I have
> spent the last week over on another
> group (also madly debating the shmoo
> bug) defending the PKI as being the only
> way that this emerging situation can be
> resolved.
>
> Their view - which has some merit - is
> that the PKI is a broken security design.
> Their proposal is to rip it out and start
> again (with their design).
Pray, Tell. Who is that group?
> That has no merit whatsoever, IMNSHO. None, zip,
> nada, zilch.
>
> Not using the certs in browsers and
> servers is a non-starter.
>
> Improving the way the PKI is used, now,
> *there's* some room for potential.
Thanks for your support!
/Nelson
Nelson Bolyard
> I wrote up a doc on how to sign an XPI package using a test cert.
>
> http://www.mozdevgroup.com/docs/pete/Signing-an-XPI.html
>
> I hope it can help ease the pain for some.
Pete, THANKS for your support of signed XPIs. I appreciate it.
/Nelson
Ian G
> Ian G wrote:
>
>> I would support that view. In fact I have
>> spent the last week over on another
>> group (also madly debating the shmoo
>> bug) defending the PKI as being the only
>> way that this emerging situation can be
>> resolved.
>>
>> Their view - which has some merit - is
>> that the PKI is a broken security design.
>> Their proposal is to rip it out and start
>> again (with their design).
>
>
> Pray, Tell. Who is that group?
The capabilities crowd, which hang out in a
list called cap-...@mail.eros-os.org , details
below. I should warn that the list when active
is deep and time consuming. It could be
desribed as "forward thinking academic
computer scientists looking at stuff a gen
or two beyond OO." Their most promising
work to date (IMO) is the design and
construction of real secure operating
systems.
iang
_______________________________________________
cap-talk mailing list
cap-...@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
Ram...@gmail.com
> Ram...@gmail.com wrote:
>
> > I definitely feel better about installing software signed by
someone
> > whose identity I know. The authentication of the software
publisher,
> > signing of the software, and revocation status checking of the
> > publisher's certificate can mitigate significant risk.
>
> If you know the person or company issuing the signed code this causes
> the CA and PKI systems to be irrelevant, all you need to do is check
the
> fingerprints of the company signing it. PKI/CAs are supposed to allow
> you to trust formerly unknown parties trust each other.
One role of a CA is to authenticated unknown parties (software
publishers in this discussion) as their proper legal entity. If I know
the publisher that may assure me to install and trust the software (or
not!). If I don't yet know the publisher I can still know that they are
being honest about what the software does (given a CA policy that
requires proper disclosure) and I feel assured that I have recourse
against the publisher if they harm me.
Ram...@gmail.com
> Ram...@gmail.com wrote:
>
> > Given a CA with a policy of requiring disclosure I can know if
> > something is spyware and choose to not install it.
>
> But that would require a little more then black and white binary
> security, it would also require some alterations to the way certs are
> handled and without a lot of effort checking each CA out personally
in
> the list how will you ever know this?
The short version is that given a market that enables CAs to compete
(on authentication policy, revocation policy, SLA, and price) through
brand identification I think normal human and market behavior are
suited to drive selection.
> Or do you plan to disable all CAs
> from being valid for code signing until you know one way or other?
Building on your point I think many would benefit from easier ways to
compare CAs especially during the establishment of CA reputations. As a
user of TB and FF I would like to see requirements for being listed as
a CA to including thresholds for authentication and revocation (e.g.
authentication quality, revocation update frequency, disclosure policy,
...). This brings up an policy decision every trust-agent publisher
(e.g. MF, MS, FSF, ...) needs to make and that is how they want to
establish trust criteria, through direct policy, user selection or a
hybrid of somesort. I think this becomes easier to do in a more mature
market with established practices and repuations. The difference
between practices of public CAs today is about as big as it could be
and yet they are treated the same whether they've issued hundreds of
thousands of high assurace certificates with a 99.99% success rate over
10 years, or if they've issued a few hundred high assurance
certificates over 3 years, or if they've issued thousands uf low
assurance certificates over 2 years. Based on the passionate
discussions in this news group it appears to me this is partly because
there is no reasonable way to expect the user to make an informed
decision. One of the basic consumer tools for decisions is
brand/reputation (which is hidden from them when it comes to CAs); the
other basic tool is feature comparison which is part of the basis for
reputation as well. Given a high branding environment one sees experts,
journalists, fanatics, consumer advocates, and consumers 'working
together' to establish and maintain reputations. Another contributing
factor seems to be the perception that one can't increase security for
the normal user without harming the user experience beyond what is
justified by the security increase. I don't believe this argument will
hold down the road and I think we're near the inflection point where
this will have to be addressed. Given that my bank pays for
authentication by a CA I think and given that many users don't get as
much value out of seeing an 80 character URL I think the browser would
do better to accent the certificate subject organization name (with
issuer brand for blame/repuation) rather than the URL. Even an option
to hide the non-domain name portion of the URL would improve security
(the username@ feature is eliminated as a spoof mechanism).
Duane
So basically binary security isn't in your opinion very useful to serve
much of a purpose.
You also mentioned high/low trust certificates, as far as my browser is
concerned there is no distinguishable difference between them. The
browser acts the same either way unless you go digging into the SSL cert
dialog boxes you can't tell there is any difference. So the only
distinguishing difference is for marketing and how money much more money
you can from the sales pitch. Again this makes binary security arguments
look more and more ridiculous the more they're tried to apply a 1 size
fits all system to the world over.
Ram...@gmail.com
>
> So basically binary security isn't in your opinion very useful to
serve
> much of a purpose.
Here is a quote of mine from earlier in this thread:
>I definitely feel better about installing software signed by someone
>whose identity I know. The authentication of the software publisher,
>signing of the software, and revocation status checking of the
>publisher's certificate can mitigate significant risk.
That's still my position. Binary trust isn't the ideal unless of course
it is the result of delegation. One could argue that a trust agent
publisher (like MF and MS) establishes what they consider to be
appropriate criteria for trust and the softare gives me a binary
indication of whether they feel safe (this begs the question 'what is
MF trying to tell me when they show a padlock in the stauts bar') -
this is my guess at the typical user's interpretation of the lock if
they "know what it means."
> You also mentioned high/low trust certificates, as far as my browser
is
> concerned there is no distinguishable difference between them.
You are echoing my earlier point regarding the need to enable brand
distinction so that CA's compete on quality (authentication policy,
revocation policy, ...) and not just price.
> The
> browser acts the same either way unless you go digging into the SSL
cert
> dialog boxes you can't tell there is any difference.
I see this as a UI failure in software that behaves this way *except*
where the softare publisher (MS, MF, ...) intends to perform the trust
evaluation for the user. Showing the issuerLogo (and certLogo) as well
as the authenticated certificate subjectDN passes the responsibility
for authentication to the CA instead of leaving it on the trust agent
(e.g. FF or IE).
> So the only
> distinguishing difference is for marketing and how money much more
money
> you can from the sales pitch.
I nearly agree with you here. Instead of enabling competition to drive
demand for quality it nearly becomes a race to the bottom for quality.
Initially the only CAs for Netscape performed relatively high
authentication before issuing certificates while today some CAs have
SSL Server certificate offerings that don't include authenticating the
identity of the applicant at all. There are many more CAs offering
services near the 'no identity authentication' end of the spectrum than
the 'high identity authentication' end. All is not lost as some CAs do
continue to offer the better auth. service and some CAs provide OCSP
and CRL support - although others offer neither. However because the
consumer is not part of the evaluation in any way it is the entity
being authenticated that has to choose the more expensive and more
robust option, this is why banks and big merchants tend to pay the
bettter CAs more money whereas small merchants tend to use either
cheaper authentication or none at all.
> Again this makes binary security arguments
> look more and more ridiculous the more they're tried to apply a 1
size
> fits all system to the world over.
Again, I quote myself from earlier in this thread:
>I definitely feel better about installing software signed by someone
>whose identity I know. The authentication of the software publisher,
>signing of the software, and revocation status checking of the
>publisher's certificate can mitigate significant risk.
--
David Stutzman
> They do?
>
> http://www.benedelman.org/news/020305-1.html
Woops...looks like Duane got to slashdot before me. I didn't read the
whole thread before posting. :(
David Stutzman
Apparently, not everyone is aware of the above happening regularly enough.
"How VeriSign Could Stop Drive-By Downloads"
February 3, 2005
Duane
They do?
http://www.benedelman.org/news/020305-1.html
"Each of these misleading installations is contrary to VeriSign
contract, contrary to VeriSign's duty to its users, and contrary to
VeriSign's many promises of trustworthiness. In the first installer,
VeriSign affirmatively certified the "click yes to continue" company
name -- although it seems that there exists no company by that name, and
although that company name is facially misleading as to the purpose of
the installation prompt. In the second and third examples, VeriSign
certified companies that subsequently used VeriSign's certification as a
necessary step in deceiving users as to the function of and (alleged)
need for their programs."
Ian G
> http://www.benedelman.org/news/020305-1.html
Nice example of the branding approach that works
because the brandname of the CA is there on the
popup. Users relate that brandname to the results,
and deliver their angst to the CA.
Now, whether the CA should then step up to the
podium and become the policement for their outraged
community of drive-by victims, or whether it should
offer a no-frills cert that doesn't do more than
identify the software supplier ... is a question for
the market to determine. A mixture of both, I'd say.
iang
Gervase Markham
> I wrote up a doc on how to sign an XPI package using a test cert.
>
> http://www.mozdevgroup.com/docs/pete/Signing-an-XPI.html
Pete,
I believe it's true that NSS 3.9, which you link to, is not usable for
signing XPIs because the signcode.exe included does not support the "-X"
switch. So, for people to sign XPIs, they have to build NSS and NSPR
themselves.
This may be one of the reasons why signing has not been done very much
up to this point.
When is the next scheduled release of NSS?
Gerv
Ram0502
Actually they revoked that certificate - possibly after having it come
to light given Ben's write-up. Remember the 'exploder' ActiveX control-
IIRC that was the first well publicized malicious use of signed
software. I am curious how many have been revoked in between these two
well known ones.
Ram0502
Ian G wrote:
> Duane wrote:
>
> > http://www.benedelman.org/news/020305-1.html
>
>
> Nice example of the branding approach that works
> because the brandname of the CA is there on the
> popup. Users relate that brandname to the results,
> and deliver their angst to the CA.
Yep. They revoked that cert as a response to someone complaining about
it - Ben or someone before him that pointed it out. Does anyone know of
other signed software that is not honest about what it does?
> Now, whether the CA should then step up to the
> podium and become the policement for their outraged
> community of drive-by victims, or whether it should
> offer a no-frills cert that doesn't do more than
> identify the software supplier ... is a question for
> the market to determine. A mixture of both, I'd say.
As consumers and relying parties we can at least drive the CAs to
enforce their policies. Does anyone know the policies of the various
CAs approved by MF-FF to issue software signing certificates? VeriSign
only issues class 3 certs for that purpose and does authentication of
the legal identity and as a matter of policy requires that the software
provide full disclosure of it's behavior. I expect Thawte's policy is
the same.
Are all the CA's in FF approved for "identifying software makers" ? We
should put together a summary describing their policies.
Ian G
>We should put together a summary describing their policies.
>
>
This later part - summary of policies - is
certainly something that users could go
looking for ("open governance"). I'd suggest
MF stick to its guns and follow the procedures
established, rather than get into policy advocacy.
Frank Hecker
> Are all the CA's in FF approved for "identifying software makers" ?
No, but I think the majority are. Certainly almost all of the
newly-appproved CAs do issue code signing certs.
> We should put together a summary describing their policies.
I have put together the raw data you need at
http://www.hecker.org/mozilla/ca-certificate-list
at least for the new CAs, namely links to the relevant CP and CPS
documents. You or anyone else are welcome to put together such a
summary, or to extend the list above to cover CAs already in Firefox,
etc., prior to my beginning reviews of CA requests. I'd be glad to
publish additional information in the file above or in a separate list,
but I don't have the time to collect all the information.
Frank
--
Frank Hecker
hec...@hecker.org
Nelson B
> Pete Collins wrote:
>
>> I wrote up a doc on how to sign an XPI package using a test cert.
>>
>> http://www.mozdevgroup.com/docs/pete/Signing-an-XPI.html
>
>
> Pete,
>
> I believe it's true that NSS 3.9, which you link to, is not usable for
> signing XPIs because the signcode.exe included does not support the "-X"
> switch. So, for people to sign XPIs, they have to build NSS and NSPR
> themselves.
Gervase, signtool's -X option (which will be in 3.10, but is not in 3.9.x)
simply eliminates the need for one of the steps that Pete described in his
page, namely, using zip to repackage the files in a different order from
the normal one for Jar files. With the -X option, signtool will package
the files in the same order as shown in Pete's instructions. But Pete's
instructions work just fine with 3.9.x.
> This may be one of the reasons why signing has not been done very much
> up to this point.
There just hasn't been any reason to do so, AFAICT.
> When is the next scheduled release of NSS?
There is no firm schedule for NSS 3.10 yet, but I think it will happen
within 3-6 months (that's an estimate, not a commitment).
> Gerv
--
Nelson B
Pete Collins
able to successfully sign some XPI packages.
I will write up a separate doc demonstrating how to do this as it is
slightly different. I hope to get to it soon ...
Regards
--pete
--
Pete Collins - Founder, Mozdev Group Inc.
www.mozdevgroup.com
Mozilla Software Development Solutions