the certification authorities have been looking to go up the value chain for sometime now.

the x.509 identity digital certificates from the early 90s ran into a number of issues. the paradigm is basically targeted at offline email authentication that existing in the early 80s (taking a page from the letters of credit/introduction from sailing ship days).

the paradigm ran into numerous discontinuities by the mid-90s

1) online was becoming ubiquitous so relying parties would have connectivity to authoritative agency and get timely information as to the party they were dealing with (as opposed to the information in the stale, static digital certificates)

2) attempting to increase the value of the certificates, there was direction of increasingly overload them with personal information. however, by the mid-90s, is had become apparent to most institutions that identity certificates, grossly overloaded with personal information, represented severe liability and privacy problems. the approach then was to retrench to relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
however, it was trivial to demonstrate that the repositories required as part of the RPO-paradigm, made any digital certificate redundant and superfluous

Certification authorities then look at branching into

1) no-value applications ... possibly internet operations that couldn't justify the cost of maintaining their own repositories and/or making online transactions

2) non-repudiation

we had been called in to help word-smith the cal. electronic signature legislation (and later the federal electronic signature legislation) ... and the lawyers involved laid down the requirements for equivalence to human signature ... i.e. indication that the human had read, understood, agrees, approves, and/or authorizes
http://www.garlic.com/~lynn/subpubkey.html#signature

examing x.509 standard digital signature defined processes ... it was possible to drive large aircraft carriers thru the holes with regard to non-repudiation.

part of the efforts attempting to address some of the gaps was trusted time-stamping ... and a decade ago, we actually reviewed some number of the startups getting into trusted time-stamping.

Other gaps are related to possible "dual-use" vulnerabilities ... i.e. same private key being used for normal authentication operations as well as non-repudiation operations. In numerous purely authentication implementations, the human never actually examines the bits being digitally signed. An attack pattern involves substituting legal documents for random bits (normally used in authentication operations). The countermeasure isn't appended a disclosure to every digital signed message which claims to meet human signature requirements (since that could also be faked). The actual countermeasure would either a) never use the same key-pair for both purposes and/or b) always append a disclosure on every set of bits that have been digitally signed w/o first having been directly examined by the human ... explicitly stating that the bits are being digitally signed w/o having been read (aka every authentication message will require disclosure appended to the bits before signing ... aka included as part of the signed bits).

The countermeasure: appending a disclosure on every signed message that is not read, only, would be inadequate, because there would then not be any default human / legal meaning to the signed messages without disclosure.

That is, there would be an implication that there was a meaning to the signature, but what would it be? "Signed?" "Seen?" "Not my department, try down the hall?"

The only way to deal with this use of public key digsigs is to wrap so much extra candy around it that (I posit) you can leave off the digsig, and it's still as strong. E.g., for public key digital signing applications, the public key is optional.

What one CA is doing is simply kicking the problem back to the user, by stating that it is in unreliable by default, in the CPS. Then, it goes on to say it is possible, but only if you follow a long list of imponderables, with a final warning that it is still not available. This might work.

the dual-use scenario was just one of the gaps that aircraft carriers could be driven thru ... and the disclaimer appended to every non-read, digitally signed, bit-string ... was at "least" required.

as in past posts about electronic signatures
http://www.garlic.com/~lynn/subpubkey.html#signature

there are significant other requirements for indicating that something has been read, understood, aggrees, approves, and/or authorizes (i.e. the disclaimer on non-read messages are just there to eliminate attackers spoofing claims that the bit-string had been read).

an example is pin-debit at point of sale ... digital signatures (aka demonstration of "something you have" authentication, aka possession of the respective private key) is analogous to pin entry ("something you know" authentication) at the POS terminal. However, the authentication is totally separate and independent of demonstration of human having read, understood, agrees, approves, and/or authorizes. In the POS terminal scenario ... it is the pressing of the "yes" button in response to question about agreeing to the transaction. This scenario has authentication and "human signature" equivalence as totally independent operations.

as in other posts about human signatures and digital signatures ... there apparently is lots of semantic confusion caused by both terms containing the word "signature".