this is sort of my repeated description that the explicit contract is between the certification authority and the party that is having the certificate certified (and pays for the certificate).
this has represented an enormous problem all along for the trusted 3rd party certification authority operations. the foreys during the 90s to address the problem included trying to get legislation passed mandating digital certificates from "approved" certification authorities (codifying the relationship as rule of law ... outside of the business contract infrastructure).
the federal PKI program took another approach. GSA as representing the federal government relying party ... signed contracts with each of the approved certification authorities ... effectively making the approved certification authorities a kind of agent of the GSA (federal governemnt relying party) ... and therefor the certificates became a form of relying-party certificates (i.e. a legal fabrication that the entity issuing the digital certificates was the same as the entity relying on the certificates). misc. past posts about relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
this got around the problem of missing any sort of contractual relationship between the certificate issuing certification authorities and the relying party.
There was another effort in the mid-90s which touches both on changing the burden of proof as well as intent.
Some early digital certificate standard effort got really confused and defined a "non-repudiation" bit. This was taken to imply that if a relying party could produce a (any) digital certificate for a specific public key that could be used to validate a specific digital signature ... then whatever that digital signature had been applied to ... could be construed as a human intent (i.e. read, understood, agrees, approves, and/or authorizes).
The scenario was that there was resistance in the merchant population to spend the money installing the facilities to support digital certificate (PKI) based financial transactions. The "non-repudiation" proposal was that if a merchant could produce a (any) digital certificate (for a consumer's public key) containing the "non-repudiation" bit then in any disputes involving a related digitally signed financial transaction, the burden of proof would be reversed (i.e. burden of proof shifted from the merchant to the consumer).
So this represented some huge issues.
It eventually came to be generaly realized that having a "non-repudiation" bit in a digital certificate carried no meaning ... and the bit definition has since come to be depreciated.
The standard PKI protocols call for appending digital certificates to digitally signed operations ... but provide for no assurance mechanism that can prove what digital certificate a consumer actually appended to any specific transaction. There would be no incentive for a consumer to actually append a "non-repudiation" bit carrying digital certificate to anything (especially when doing so shifted legal liability to them from the other party). There would be lot of incentive for a merchant to discover and be able to produce some consumer digital certificate with the "non-repudiation" bit set.
Part of the confusion goes back to attempts to equate digital signatures to human signatures (as evidence the definition of a "non-repudiaton" bit in digital certificate specification). Some of this could be considered semantic confusion with the word "signature" appearing in both the terms "digital signature" and "human signature".
If you trace back all the steps that a "digital signature" can represent, it basically comes down to "something you have" authentication. There is nothing in any of the operations specified for dealing with a "digital signature" that can tie a existance of a "digital signature" to human intent (some human operation tied to read, understood, approves, agrees, and/or authorizes).
a couple recent posts on the subject:
http://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signature
http://www.garlic.com/~lynn/aadsm23.htm#12 Court rules email addresses are not signature
http://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signature
I expect that attempting to relate digital signature to human signatures and human intent (having read, understood, agrees, approves, and/or authorizes) will eventually go through some similar evoluation that happened to the non-repudiation concept. Rather than the existance of a static bit created at some point in the distant past, the most current non-repudiation thinking involves a whole bunch of (non-repudiation) that will *certify* specific sequence events occured as part of some operation (and it was these sequence of events as part of each operation that were necessary for creating the basis of any sort of non-repudiation).
A similar evoluation for "human intent" will be services that can certify that specific sequence of events occured as part of doing an operation (say digitally signing a transaction) that are the basis for establishing human intent (read, understood, agrees, approves, and/or authorizes). It isn't the existance of the digital signature that represents any sort of "human intent" (i.e. the actual digital signature just represents "something you have" authentication). It is the certification of these other events performed in conjunction with the digital signature that is necessarily for establishing the basis of any sort of "human intent" ... and therefor can be treated as "human signature" (read, understood, agrees, approves, and/or authorizes).
misc. past posts mentioning having worked on some of the word smithing of the cal. state electronic signature legislation and later the federal electronic signature legislation.
http://www.garlic.com/~lynn/subpubkey.html#signature
Binding the relying party through a copyright license is a good idea from the CA's point of view if it can be made to work. CAs worry quite a bit about liability to relying parties (through various theories, such as tort and promissory estoppel) and hope to convince relying parties to waive liability or make it conditional via contract.
For example, in promissory estoppel, if a CA makes promise to a relying party, and the relying party, well, "relies" on that promise to his detriment (the language of CAs actually echoes that of the law here, which could make convincing the judge and jury far easier) -- for example losing a billion dollars on a financial transaction because somebody compromised the root key or an imposter succeeded in getting a certificate naming a stock broker or any number of other possible CA failures -- the CA could end up being liable for that billion dollars, even without a formed contract. There are a number of legal hoops the relying party must jump through to get that far, and it doesn't work even in all American jurisdictions, but it's something CAs worry about.
I'm not sure copyrighting the public key shifts the burden of lawsuit, as the relying party already has to sue and it's easy enough to "pirate" a public key -- the CA can't "repossess" it, unless they have a fancy key revocation scheme; they'd have to sue to make the relying party stop using it. The real win from copyrighting the key comes from stripping legal rights that a relying party could otherwise use against a CA once a lawsuit is brought, either because the relying party violated the law by "pirating" the key or because the relying party agreed to a license where the CA waived liability (i.e. the CPS).
A big specific benefit for the CA of this nature is that even without a contract the fact that the relying party is violating the CA's copyright strips the relying party of equitable claims (such as promissory estoppel) against the CA (one generally cannot make an equitable claim with "tainted hands," i.e. having committed a wrong oneself).
However, there are major logistical problems to making this public key license scheme practical for the CA. Does the license for the software or hardware with which the public key is distributed have to include a copy of the entire CPS in its contract (whether click wrap or traditional paper), or can it be incorporated by reference to a web document? If the latter what language is binding if the online document is updated? (these are part of the "knowledge" and "intent" issues Ian raised, which in U.S. legal terms often fall under "procedural unconscionability -- a traditional example is fine print). Perhaps one could even incorporate the CPS by reference in the key itself by putting its URL in one of those silly X.509 text fields. If a relying party was my client I'd quite likely attack the supposed license on such grounds.
Furthermore, can one effectively copyright this small piece of an otherwise "open binary" free download, or does that circumstance create an implied license or a defense of fair use? If I was mounting an equitable challenge against a CA, such as promissory estoppel, I'd argue that my client did not "pirate" the key in order to maintain the client's "clean hands," and implied license and fair use in this context seem fairly plausible as such arguments go.
One thing's for sure, when companies decide to use legal mechanisms instead of security mechanisms, it's not the security engineers who will be raking in the big bucks servicing the scheme, nor much the companies themselves, but guess who :-) or :-( depending on which profession you're in...