I agree with ichimunki that this thinking just wouldn't fly with dynamic content. You're talking about adding one more process to squeeze your data through to get it to the client. However, this wouldn't be a bad idea at all for static resources.

But what if your CGI that was generating the dynamic pages could add in signature for the CGI itself (something hinging on a sessionID or something), to indicate that the resulting pages are genuine? A simple check from the client against that tag would verify the authenticity of the replies.

Update: misread ichimmunk's comment. Sorry :(

Better would be a signed text file containing the approved MD5 or SHA1 hashes for the downloadable files or libraries.

In my original post, I said that downloadable files are so-signed. But how does the downloader know that it was signed by the right person? Seeing the same sig identity in other places establishes knowledge of that person. That's the whole point of doing this.

Besides having an external sig file for the whole page, here's a couple reasons why it would be nice to sign just parts of a page:

Consider signing the "script" that's embedded in a HTML file. I was also thinking of putting together parts into a single presented page, where each part is already signed. For example, public statements and contact info.

If HTML is dynamically generated, such quoted blocks, like "send payment to..." could have sig's built-into the template. —John

that doesn't mean it makes no sense

That's why I said it did make sense. :)

If you have pieces of a web-page that are static so that they can be signed, it's a great idea. I'd love to see an application that helped verify embedded signatures in HTML from places like PM, where it would be nice to verify that a user is the same user from elsewhere based on their signature.

But how does the downloader know that it was signed by the right person?

The same way they'd know if the file itself was signed correctly.

It's an intriguing notion, it would be fun (and potentially useful) to have a web page that had IMG tags that had a signature attribute and the browser would note whether the image was signed or not. Or would do the work of detecting any signed element and validating it-- good suggestion. Is there something in the HTML spec that allows for this, or would we simply use a comment field?

The real fun is how to sign the image (or other binary file) outside the web page without altering the image file (so that non-compliant viewer programs could still display the image). And that's what I was thinking of with the signed hash file. You can caption the image (as part of the image) with a pointer to a signed hash file, hash the new image, put the hash in the hash file, sign the file, and distribute that file. If a version of the image is found that doesn't have a matching hash to the one in the file, the image has been altered. But I suppose this is redundant, you could just put a bunch of detached sigs in the file, eh?

So, how does someone downloading my library know that it's signed by me, not just signed by anyone who figures out how to run PGP and type a name? Because the same signature is used in other places, so the consumer "gets to know" that person.

Well, thats not how a digital signature works if digital signatures in s/mime (my only experience) are anything to go by. We dont know that your signature is real until we can do two things, first determine if the signature was generated from a trusted root authority and second determine if the primed checksum (be it md5 or sha dat de da..) is correct for the payload carried. By primed I mean that only someone who knows the private key could have generated that checksum for that data. Having passed these checks we would assume that both the payload actually comes from you and that it is what you and only you meant to send.

So if I want to send you something I take my private key use it to prime my checksum and then post my public key and checksum for said document, basically the same process of encrypting but I dont change the data.

Anyway, I suppose i've missed the point, but isn't all of this what SSL (https) and brethren are for?

Yves
--
You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)

That's a fundimental difference between Netscape's plan for SSI to enable web commerce, and the grass-roots no-trusted-third-party idea behind the original PGP.

If I want to spend $1000 to VeriSign, they issue a certificate after checking me out. A certificate issued by them is presumably good, because everybody trusts them.

However, a more general form is that my key (which I made myself) is signed by people I know personally. PGPkeys app will look at who signed my key, and do a recursive search all the way back to someone you said you trust because you know them personally (they're the ones who signed your key).

PGP's plan is a more general approach. I could have my friends sign it at a key-signing party, or I could pay a famous notary to sign it, or both. X.509 certifiates only have one authority signature, so it's much simpler.

The problem is, I don't know anyone personally who uses PGP regularly, to sign my key and be worth anything. It won't add it to the peer network, because we are all islands. The network is not hooked up!

So, how else do you get to know someone? From repeated exposure. I sign newsgroup posts to prevent fakes from appearing in my name. The reader can't prove that the signature really identifies a specific person, but he knows that all the posts are from the same person. A fake will stand out.

So, all my online friends know me from 10 years of correspondence. Many don't know what I look like, but they know me, to some extent. If I needed to, I could prove that a specific statement I issue is signed by the same person they "know", even though no authority is identifying me as an individual outside of that context.

That's the concept I'm using to make "grass-roots" (e.g. no big bucks to VeriSign) code signing work. A DLL is signed by somebody. So what? Well, if the same signature is used in many places that are visible, you can come to know the signor from those places and know that the code was written by the same person.

Signing a web page with the manual and whitepapers helps link the code to its creator. Signing the page that contains pictures of my family is not "necessary" for commerce, but helps keep the chain of identity, of "same person here", going. We have that link in face-to-face society. We know we're dealing with the same individual because we see and/or hear him and compare the face or voiceprint implicitly. I'm proposing one mechanism to continue that mechanism into cyperspace.

Now back to SSL. If you send me money, you want to know more specifically that I'm a legitimate business in line with the idienting marks on the page. It might be a business you've never seen before but found on pricewatch.com. Having an authority check it out is a great solution for that.

However, for someone who's not Amazon, spending $1000 per year is just bogus, especially if you're not sending me credit card info. Instead, what I really want, is to have a notary public sign my key for a $2 stipend. That's good enough for selling titled merchanice like cars, or making small legal contracts, right? So it should be good enough for some online purposes, too.

—John

Hi John

Well a few thoughts, mostly chaotic, BWTH..

There is no need to obtain a CA from verisign for big $$$. You could go to any number of free CA (thawte comes to mind) to get yourself a personal certificate.

However perhaps for perlmonks (hypothetically speaking) there might be a simpler plan, simply get an OpenSSL build and generate a root cert for the site. Then every time a user signs up issue them with their own certificate using this as a root CA. Explicitly trusting a certificate or authority when the exchange is of non critical information should be no problem. Any time a user wanted to post authenticable material they could email it signed or encrypted to the site or perhaps prepackage it as s/mime and post it that way. Once you learn OpenSSL little tricks (and there are a few :-) it is relatively easy to use it and MIME::Entity to facilitate secure arbitrary payloads. On the other hand how they meld with the visual interface of a web page is another story.

For me it all comes down to trust. Trust that the same person whose posts I have seen before is indeed the author of some document, or trust that this person is not a risk. And in the case of e-commerce the risk is not the value of the transaction being undertaken but simply the insecure exchange of financial details. For that kind of data I want to know that the information will not be abused, and to do that I need some form of validation beyond simply identity uniqueness.

On the other hand I like the idea that users of a forum like this have an easy way to authenticate posts and thus prove their identity, even if the true details of that identity are anonymous like they are here.

Yves
--
You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)

Nice that radiusnet is out there as a resource (++ for the link)-- they have a highly concentrated crypto site. However, you'd think they'd have a pointer or two to their own public keys... the 17 keys I got that matched 'radiusnet.net' from keys.pgp.com don't match the one used to sign the HTML page in question.

And sadly, they've basically shown how to embed the signature by hand in a very static HTML file... a method which requires the verifier to fiddle with the page in question. Even with their public key, I'd have to add some information to their HTML to get it to verify (and I'd be guessing to do that).

By subclassing CGI, I've managed to build methods that insert detached sigs into HTML comments to sign both text and images. I'm just polishing that up, and then I want to make a quickie to assist in batch process creating detached sigs (part of the way I would implement John's original idea-- since you'd be signing everything ahead of time). Then, of course, the fun part, building a utility to verify the signatures (since the data requires some handling to get it into GnuPG or PGP in a useful format). Once I get a basic set of tools together, I plan to post for review. :)

Interesting. He just points out that PGP sig verification will work just fine if you get the correct ascii armor header/footer lines in there. He puts the first inside an HTML comment and the latter inside a PRE.

So, stuff before and after the signed parts are not checked.

I don't plan, at its simplest, to do anything much more elaborate than that. But I'll have a Perl script to automate it.

—John