Ping Roedy Green

[Qu0ll]

Roedy, I just want to thank you for your excellent Java glossary entry on
signed applets. It is very comprehensive and helpful.

One thing I am not clear on though is if I purchase a proper certificate
from a trusted source like Thawte, will the signed applet be able to run
without asking the user first?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Roedy Green]

One thing I am not clear on though is if I purchase a proper certificate
from a trusted source like Thawte, will the signed applet be able to run
without asking the user first?

no.

Here's why. Let's say my Applet rummages around the hard disk looking
for thumbnail photos, and uploads them to a server. I need the
client's explicit permission to do that, not just $350 for a cert.

 

[Roedy Green]

no.

Here's why. Let's say my Applet rummages around the hard disk looking
for thumbnail photos, and uploads them to a server. I need the
client's explicit permission to do that, not just $350 for a cert.

The advantages of real over self-signed phony certificates and the
limitations are discussed in detail at
http://mindprod.com/jgloss/selfsignedcertificate.html

 

[Arne Vajhøj]

Isn't it really a question of which certificates you trust directly and
which you trust indirectly?

My web-browser is full of self-signed certificates for certificate
authorities. I don't really know any of them and have no special reason
to place more than a very minimal level of trust in them.

I also see I have a certificate for a service I use, that certificate is
signed by Comodo CA Limited. I have no idea who Comodo are or how
trustworthy they are. Presumably someone at Mozilla felt they were
trustworthy but I've no idea how much effort that Mozilla developer put
into checking out the integrity of Comodo and I've no idea what checks
Comodo applied to the company that obtained a server cert from them,
maybe just that they appear to be a registered company and that the
payment cleared?

I'd actually have a lot MORE trust in a self-signed certificate
handed[1] to me by someone I personally trust.

I don't think it is just a randomly picked developer that
flip a coin to decide whether a root certificate goes into
the browser or not. This is critical for the security that
the root certificates are legit.

And the CA do make some checks because they are warrantying
their certificates. Then they have 10000 dollars of good reasons
to check.

It is obviously not a perfect system.

Most people will trust something they receive from
a personal friend/colleague. But do they also believe
that he keep his keystore and passphrase properly
protected from spyware/keyloggers etc.?

Arne

 

[Arne Vajhøj]

Roedy, I just want to thank you for your excellent Java glossary entry
on signed applets. It is very comprehensive and helpful.

One thing I am not clear on though is if I purchase a proper certificate
from a trusted source like Thawte, will the signed applet be able to run
without asking the user first?

No. The signing thing is only authentication not authorization. A proper
certificate may get more people to accept your certificate as being
from you, but access will still need to be granted.

Arne

 

[Gerald Murdock]

I'd actually have a lot MORE trust in a self-signed certificate
handed[1] to me by someone I personally trust.

Where's the footnote [1]? I didn't see it in your post.

 

[Roedy Green]

I understand why you use this emotive terminology (real vs phony) but
your root certificates (Verisign etc) must be self-signed and hence phony?

The Oxford dictionary defines certificate as an official document
attesting or recording of a particular fact or event, the level of
achievement or the fulfillment of a legal achievement.

A real certificate involves three levels of certification.

1. the vendor certifies he did indeed write the software.

2. the certificate vendor certifies that the vendor presented
identification details to obtain the certificate he used to sign the
program.

3. Sun certifies that the certificate vendor is a reputable company
who takes sufficient care in handing out certificates to vendors. It
indicates this certification by including the public root certificate
of respected vendors in cacerts.

A phony certificate certifies that the holder of some certificate did
indeed write the software. It says nothing about the identity of the
vendor.

So it seems to me, there no official document involved with a phony
cert. A phony certificate is not actually a certificate. However, it
is not completely valueless. For example, I post the public key of my
phony certificate on mindprod.com. People can then know whomever
created mindprod.com also vouches for the signed code posted there,
but you knew that anyway, without the signing. It does however let
people who pick up code elsewhere to know that also IF they check the
posted root certificate.

I expect eventually personal IDs will be based on private keys. You
will then be able effectively to use your birth certificate id for all
manner of purposes, including purchasing goods and signing code.
Then there would be no need for unsigned code or code signed with
phony keys.

 

[Roedy Green]

Presumably someone at Mozilla felt they were
trustworthy but I've no idea how much effort that Mozilla developer put
into checking out the integrity of Comodo and I've no idea what checks
Comodo applied to the company that obtained a server cert from them,
maybe just that they appear to be a registered company and that the
payment cleared?

I remember getting a cert from Thawte. They certainly did a thorough
check to make sure I was really me. If they didn't, and word of it
got out, it would make ALL Thawte issued certs less valuable. People
would not trust them. Thawte certs would have only intermediate value
between real certs and phony certs.

When you buy a cert, you are primarily paying for the work they do to
verify your identity.

A cert company can't easily sell its certs unless the roots are
accepted in browser lists, OS lists and Java lists. It has to convince
these companies to include its root.

I think a pirate would fool people by creating a plausible sounding
certificate root authority, and giving instructions to install the
root CA authority cert. It would be quite dangerous to try to apply
for a cert in some other company's name. All the certificate issuer
has to do is look up the company in the phone book and give them a
call. They will get the real company.

 

[Roedy Green]

The Oxford dictionary defines certificate as an official document
attesting or recording of a particular fact or event, the level of
achievement or the fulfillment of a legal achievement.

I elaborate on these ideas further at:

http://mindprod.com/jgloss/selfsignedcertificate.html#TERMINOLOGY

 

[Roedy Green]

Would you say Versign certs are less trustworthy than Thawte certs?

Verisign bought out Thawte. Verisign are considerably more expensive.
Verisign are openly hostile when you apply. Thawte are relatively
friendly.

Dealing with Verisign is like going into a 5 star hotel. They sniff at
you if you don't have a Gold American Express card. They are really in
the business of serving the Fortune 1000 only. I would suppose this
hauteur would tend to scare off more crooks.

I doubt many pirates would have the chutzpa to attempt acquire a
Verisign or Thawte certificate. The public, even programmers, are
pretty clueless about certificates. I think a clever pirate would
exploit that confusion instead.

It would be ever so much easier to fob off a phony certificate as
meaningful or a phony CA certificate from a fictitious CA company, or
simply write code in a language that does not require signing, use
piratical means to install software, or just use ordinary Java Apps
with a traditional installer that don't require signing.

 

[Roedy Green]

That is all they have to do. It isn't what they do. Sometimes they issue
the certs before they complete the checks.

http://news.cnet.com/2100-1001-254586.html&tag=tp_pr

That is bold! I suppose the pirates were counting on the fact that
nobody at a huge corporation like Microsoft knows for sure who is in
charge of what. They also might pull it off with just a few bribed MS
employees. Probably the weakest link in the whole verification chain
is knowing who in a company is authorised to acquire certificates on
behalf of the company.

I know from personal experience, you tend to be less careful with
ordinary security procedures when a big name company makes an order.
It is a bit like royal visit.

I know when I got my certs from Verisign and Thawte they did not issue
them until they had checked me over very thoroughly. Thawte GAVE me a
certificate for a year or two. They approached me. They knew I would
document the experience and hence grease the way for other programmers
to go with Thawte. Just the same, they checked me over as if I were
radioactive.

A code signing cert could well be used for many additional purposes,
to act like a corporate digital signature on any document, even a
purchase order. Logically, it is about the best ID you can get, harder
to forge even than a passport.

Back then, getting a cert was a fairly esoteric experience. The
vendors have greatly improved the documentation over the years. It is
pretty much a follow-your-nose process now, even if you have no clue
of how it all works.

 

[Gerald Murdock]

When you buy a cert, you are primarily paying for the work they do to
verify your identity.

And when it "expires" and you have to pay some more to "renew" it? What
work are you paying them to do then? Keeping in mind that your identity
can hardly have changed in the interim, so can't possibly need verifying
again.

 

[Roedy Green]

And when it "expires" and you have to pay some more to "renew" it? What
work are you paying them to do then? Keeping in mind that your identity
can hardly have changed in the interim, so can't possibly need verifying
again.

They still have to verify the business is alive, at the same address
and phone number, with the same principals and contact people .They
can be less suspicious. Logically extra years should be somewhat
cheaper.

They don't have to lower the price since other vendors can't compete,
since you would be new to them.

What other vendors could do is offer you a cheap 5-year certificate,
or a series of 5 one year extensions. They could then compete with a
Verisign renewal.

For a large corporation the bureacratic hassle of buying the
certificate is more expensive than the certificate itself. Overhead
for renewing is cheaper than starting over with a new vendor. This
means renewals are more expensive than you would expect.

 

[Lew]

Gerald Murdock wrote, quoted or indirectly quoted someone who said :

They still have to verify the business is alive, at the same address
and phone number, with the same principals and contact people .They
can be less suspicious. Logically extra years should be somewhat
cheaper.

They don't have to lower the price since other vendors can't compete,
since you would be new to them.

What other vendors could do is offer you a cheap 5-year certificate,
or a series of 5 one year extensions. They could then compete with a
Verisign renewal.

For a large corporation the bureacratic hassle of buying the
certificate is more expensive than the certificate itself. Overhead
for renewing is cheaper than starting over with a new vendor. This
means renewals are more expensive than you would expect.

To add to Roedy's point, a vendor is not under obligation to base their price
on the cost of production, contrary to what Gerald seems to think. They are
under obligation to charge the price that will maximize profits; that means to
increase price as far as possible until it tilts past the profit that demand
will bear. Price is a function of both demand and production cost; those who
try to narrow it to only one or the other misrepresent the situation.

 

[Gerald Murdock]

To add to Roedy's point, a vendor is not under obligation to base their
price on the cost of production, contrary to what Gerald seems to
think. They are under obligation to charge the price that will maximize
profits; that means to increase price as far as possible until it tilts
past the profit that demand will bear. Price is a function of both
demand and production cost; those who try to narrow it to only one or
the other misrepresent the situation.

I have no intention of misrepresenting anything. In fact, I asked a
question, rather than stated something.

It looks like one problem is that the market for certificates is
currently not competitive. In a competitive market, prices do not tend
to be much higher than costs. It sounds like Thawte and Verisign have
pretty fat margins though. Perhaps because a duopoly is not much better
than a monopoly; it seems to take three vendors to get decent
competition, if not more, in most markets.

There is also a problem with Roedy's claim for why they insist on
expirations and renewals, namely that you could have moved.

First of all, you might move just after a renewal.

Second of all, the purpose of code signing certs is to prove that the
code is from who it says its from. If the code is certified as being
from Gerald Murdock, for example, then it doesn't magically need
recertifying if I move from New York to LA or something. That same old
code is still code that was written (or at least vetted and endorsed) by
Gerald Murdock. It can't magically become virus-infested code from J.
Random Script Kiddie just because I moved house or got a different job.

My suspicion is that the renewal stuff is just to lock coders into
paying a Verisign yearly tax for life if they ever release code signed
with one of their certs into the wild, because if they ever stop paying,
that code magically reverts to unsigned (and nevermind that it's by then
proven to be safe, still of proven provenance, and so forth) and all its
users will be inconvenienced or worse.

My prescription: we need some more competing certificate-signing
companies. The barrier to entry for producing signed jars and similarly
should not be so high. Right now it's prohibitive for a hobbyist
programmer and onerous for a small business, thus favoring big
businesses like Microsoft.

Perhaps the whole concept of code signing, or even of personal identity,
needs rethinking too. Surely there's a mechanism by which someone could
get a cheap, for-life identity to use for such things, which would
resist attack? I don't notice many people having to pay over and over
again for their birth certificate, and most other kinds of ID tend to
have good reasons for needing renewal; for example, a driver's license
has a good reason in that a formerly good driver might go blind or
something. (Even then, there's a possible time lag between the condition
and the next renewal; renewal really isn't the best way to handle that
sort of thing IMO -- immediate conditional revocation is.)

 

[Gerald Murdock]

[...]
My suspicion is that the renewal stuff is just to lock coders into
paying a Verisign yearly tax for life if they ever release code signed
with one of their certs into the wild, because if they ever stop
paying, that code magically reverts to unsigned (and nevermind that
it's by then proven to be safe, still of proven provenance, and so
forth) and all its users will be inconvenienced or worse.

Verisign's code signatures last for ten years, independently of the
lapsed or active status of the publisher ID that created them.

That's funny, because the post I responded to explicitly made reference
to "one-year extensions", implying a renewal periodicity of a year, not
a decade.

 

[Roedy Green]

That's funny, because the post I responded to explicitly made reference
to "one-year extensions", implying a renewal periodicity of a year, not
a decade.

see
http://www.thawte.com/code-signing/index.html?click=DoYouNeedTo-SecureCode

Thawte now sells 1-year and 2-year code-signing certificates.

I may have mislead you. I know that you can't sign any code after the
cert expires, but I am not sure how long the cert is considered valid
thereafter.

I have always resigned and re-released code each year. I leapt to the
conclusion this was necessary to keep existing signatures valid. My
original reason for doing it is to update the copyright notices.

I have put in a query to thawte.com to clarify the expiry.

 

[Roedy Green]

To add to Roedy's point, a vendor is not under obligation to base their price
on the cost of production, contrary to what Gerald seems to think. They are
under obligation to charge the price that will maximize profits; that means to
increase price as far as possible until it tilts past the profit that demand
will bear. Price is a function of both demand and production cost; those who
try to narrow it to only one or the other misrepresent the situation.

Exactly. I was trying to explain why corporations were willing to pay
considerably more for a renewal than the cost of providing it, so
there was no motive to drive the price down.

 

[Roedy Green]

My suspicion is that the renewal stuff is just to lock coders into
paying a Verisign yearly tax for life if they ever release code signed
with one of their certs into the wild, because if they ever stop paying,
that code magically reverts to unsigned (and nevermind that it's by then
proven to be safe, still of proven provenance, and so forth) and all its
users will be inconvenienced or worse.

It does not work that way. The cert is usually good for one year. It
expires whether you renew or not. You must re-sign your code each
year and re-release it.

 

[Roedy Green]

My prescription: we need some more competing certificate-signing
companies. The barrier to entry for producing signed jars and similarly
should not be so high. Right now it's prohibitive for a hobbyist
programmer and onerous for a small business, thus favoring big
businesses like Microsoft.

At least for SSL certs, there are plenty of vendors. The Java code
signing market is too small to attract many vendors. see
http://mindprod.com/jgloss/certificatevendors.html

Part of what Verisign is selling is their reputation and advertising
budget. Verisign would contend that people are more likely to trust
an app signed with an expensive Verisign cert that one signed by some
cheapie company. It much like buying $1 a sheet office stationary to
impress clients.

At times I toyed with the idea of setting up a code signing cert
company that would be not be as thorough as Thawte/Verisign, but would
be much more affordable. The problem I would have would be getting my
root cert into cacerts. If Sun did not accept them into the
distribution, my certs would be all but useless.

I would expert Verisign/Thawte to lean on Sun to keep upstarts like me
out.