March 05, 2006

"doing the CA statement shuffle" and other dances

The much discussed CA branding model has apparently been adopted by Microsoft, implemented in the InfoCard system, if the presentation by Cameron and Jones is anything to go by. I reviewed and critiqued that presentation last week, including relevant screenshots.

Now, the statement as the core reason for the CA's existance is becoming more clearly accepted. It's something that got thrown out with the bath water back in 1995 or so, but it seems to be heading for something of a revival. Cameron and Jones say:

In many cases, all that having a standard site certificate guarantees is that someone was once able to respond to e-mail sent to that site. In contrast, a higher-value certificate is the certificate authority saying, in effect, We stake our reputation on the fact that this is a reputable merchant and they are who they claim to be.

I also found an RFC by Chokhani, et al, called Internet X.509 Public Key Infrastructure (RFC 3647) which throws more light on the statement:

3.1. Certificate Policy

When a certification authority issues a certificate, it is providing a statement to a certificate user (i.e., a relying party) that a particular public key is bound to the identity and/or other attributes of a particular entity (the certificate subject, which is usually also the subscriber). The extent to which the relying party should rely on that statement by the CA, however, needs to be assessed by the relying party or entity controlling or coordinating the way relying parties or relying party applications use certificates. Different certificates are issued following different practices and procedures, and may be suitable for different applications and/or purposes.

The CA's statement is that the the key is bound to attributes of an entity (including Identity). So we are all agreed that the cert has or is a statement of the CA saying something. But consider the caveat there that I emphasised: the authors have recognised that relying parties typically do not control or coordinate their use of certificates. There is typically an intermediate entity that takes responsibility for this. To the extent that this entity controls or coordinates the root list, they are in the driver's seat.

For browsing, this is the browser manufacturer, and thus the browser manufacturer is the relying party of ultimate responsibility. What this does is put browser manufacturers in a sticky position, whether they admit to it or not (and notice how you won't find any browser manufacturer clarifying who makes the statement from a manufacturered cert).

Microsoft's position may be weak in understanding and implementation, or maybe they know full well where this is going, and are implementing an intermediate step. Leaving that aside, it does leave the interesting question as to why they have only partially implemented the model. Not only does the high-assurance program prove the point that the CA has to be branded (thanks for that!) but it also confirms that the browser is on the hook for all the other certs in the other, default, poor man's certificate regime.

Either way, we are on the move again...

Posted by iang at March 5, 2006 06:23 PM | TrackBack

The great coupe is at hand Microslop Bank is hiding in the bushes with so much dam money they only way they can continue to grow is be an internet bank which means be the bank of first and last choice. Advertising is nothing when compared to controlling the systems that process payments and extend credit, Credit is the reason for ID and since CAs are already regulated the perfection of ID and CA are not far off from Microslop offering credit. Imagine if you will a massive mall where advertising and payments are combined and instant credit offered. Retail music downloads receive 50%, gambling keeps 80% of the money, and credit can if not paid on time charge fees that would knock your eyes out. The interesting feature is online transaction processing does not require a bank charter and the receivables can be securitized immediately and the risk passed on to the capital markets. The timing is perfect the housing boom is over and refinancing has all but dried up so consumer users are easy pickins simply offer credit because no one else will. The Microslop Credit Corp will sell cars, televisions, do auctions, and sell just about everything that can be paid for online with Microslop Credit.
Approved Digital Signature Certification Authorities Certification Expires
Digital Signature Trust / an Identrus company
255 North Admiral Byrd Road
Salt Lake City, Utah 84116-3703
Phone: 801-326-5400
Fax: 801-326-5448 November 18, 2005
Entrust, Inc.
One Hanover Park
16633 Dallas Parkway
Suite 800
Addision, Texas 75001
Phone: 613-270-3157
Fax: 613-270-2503 (Certificate Information) August 25, 2006
Verisign, Inc.
487 East Middlefield Road
Mountain View, California 94043
Phone: 650-961-7500
Fax: 650-961-7300 October 3, 2006
GeoTrust, Inc.
117 Kendrick Street, Suite 350
Needham, MA 02494
Phone: 781-292-4126
Fax: 781-444-3961 July 28, 2006

Posted by: Jimbo at March 5, 2006 07:44 PM

when we were doing the original payment gateway as part of the commerce server doing payment transactions

looked at some number of additional things that a certificate could represent, in addition to straight-forward ssl domain name certification.

recent post about ssl domain name certificates being compromised because original design had the user typing in the url and then the server supplied certificate matched the typed in URL implied that the server the user thot they were talking to was the server they were talking to (implicit was belief that the end-user had understanding between some entity and the URL)

as the environment evolved to users simply clicking on buttons or other things (potentially supplied by an attacker) ... the ssl domain name certificate just came to mean that any attacker was who they claimed to be

our proposals about including more detailed checks on e-commerce merchants possibly including things like fbi background checks on all proposals didn't catch on (also mentioned in the above post).

part of the issue was financial justification for doing the additional checking. a merchant/acquiring financial institution already does a fairly detailed check on any credit card accepting merchant (since part of a merchant/acquiring financial institution sponsoring a merchant for accepting credit card transactions ... includes taking financial liability for the merchant).

there was an issue with whether an end-user could trust an unknown merchant. the e-commerce activity was highly skewed with the majority of transactions occuring with well known and well branded websites, frequently repeat business. A small percentage of total e-commerce activity was spread across the large number of websites ... each website only performing a few transactions each. The high volume merchants didn't need anymore trust ... since they had the brand and repeat business. The low volume merchants couldn't justify paying more for trusted certification ... other than what they were already paying to their merchant/acquiring financial institution.

this was still in the days when it was assumed that the user was typing in the URL and was familiar with the entity associated with the URL.

the evoluation came with the disconnect with what the users perceived to be entities and clicking on arbitrary strings that provided the URL to the browsers. This created a disconnect between what the user perceived to be the entity and the URL supplied to the browser. Attackers could provide things to click on that claimed to be some well-known entity, but actually generated some totally unrelated URL. Then the attacker only had to provide a certificate that proved that they were who the URL claimed they were (as opposed to textual claims as to who they were).

So there a possible a couple different countermeasures to vulnerability/exploit. One is to create some variety of trusted "clicks" (which have evolved as a substitute for actually typing in the URL). As part of creating trusted "clicks" there is some user involvement in establishing the relationship between who the user thinks the entity represented actually is, the "trusted" click, and the resulting URL (which was implicit in the original SSL model that assumed the user would be typing in the URL value and understood the relationship between some entity and their URL).

An alternative is some sort of high assurance certificate and some browser visual indication when the browser is dealing with a high assurance certificate (as opposed to any run of the mill certificate).

The high assurance certificates doesn't eliminate the disconnect for end-users where some text can claim that clicking will invoke one thing ... but actually invokes something else different (the only thing that ssl domain name certificates does is prove that you are who your URL claims you to be ... as opposed to what any surrounding text may claim you to be).

Implicit is an assumption that attackers won't be able to obtain a high assurance certificates (and all the entities that can obtain high assurance certificates won't involve themselves in impersonations).

to some extent the certificate-base model is that the end-user needs to have no local support infrastructure ... that it can all be supplied by institutional entities.

the "trusted" click model assumes that the end-user has some sort of local support infrastructure ... for recording and preserving their "trusted" clicks. "trusted" click model could even allow clicking on externally supplied clicks ... and having the browser tell you whether it mapped to a trusted click entry and who was the entity associated with the entry (even visual clues similar to that proposed for high assurance certificates).

Posted by: Lynn Wheeler at March 5, 2006 08:41 PM

I can imagine only two workable models of certification:
1. one that comes together with the domain registration, issued by the registry.
2. Title insurance, like for real estate in California (and possibly elsewhere). The insurer (the CA, in this case) will compensate anyone defrauded using the fact that the title (the identity, in this case) did not, in fact, belong to the insured party.

Posted by: Daniel A. Nagy at March 6, 2006 03:13 AM

from the end-user standpoint, the "trusted click" paradigm, using something analogous to bookmarks, can be quite similar to cellphone phone books (using caller-id to maps to different ring tones) or email address books (where spam blockers may rate incoming different if the origin address is in the address book).

that doesn't address spoofing the origin email address or spoofing the caller-id ... but in the web paradigm, basic ssl is used to catch that type of spoofing.

the current issue is the disconnect with the click paradigm ... where users are presented with to something to click ... and attempts are made to obfuscate the URL domain name (SSL provides the connection between the URL domain name and the website ... but the click paradigm allows for a disconnect between the end-user and the actual URL domain name coming off the click).

digital certificate cps, gov. legislation, and audits can be viewed as attempts to get around the TTP/CA business model being alien to standard business operations. In standard business operations, the relying party has business relationship with the certifying agency and typically there is some exchange of value (implicity or explicity contract). In the typical TTP/CA business model there is no business relationship and/or obligation between the CA and the relying parties. CPS, gov. legislation and audits are approaches that attempt to provide a sense of comfort for relying parties in certifications performed by CAs (where it doesn't otherwise exist in normal business practice).

GSA addressed this in the Federal PKI by signing contracts with all approved certifying agencies issuing digital certificates .... essentially making them agents of GSA (for issuing digital certificates). Then federal gov., as relying party, could rely on the issued digital certificates because of their (gsa) contract with the certification authorities.

note in previous comments, theoritical use of digital certificates is by relying parties where they have no information about the subject entity and/or no way of obtaining such information. in the digital certificate analogy to letters of credit/introduction, the relying party
(when there was no other means of obtaining information) could record information from the letters of credit/introduction in their local repository. typically a letter of credit/introduction wouldn't be repeatedly presented on every interaction, but recorded locally. the local record is then used for future interactions.

so a local trusted repository (bookmarks, public key repository, address book, phone book, etc) is used to record information about interactions. when no other information is readily available (either locally or via direct contacts with reputable agencies ... in the domain name case, it could be direct contract with the domain name infrastructure and retrieving registered public key at the same time registered ip-address is retrieved), then individual's local repository might be populated on first-time interaction between two total strangers with information supplied by digital certificate.

Paradigm that repeatedly presents such credentials on every interaction typically assume that the relying party has no ability to maintain local repository.

The scenario of acquiring/merchant financial institutions implicity certifying merchants that can perform credit card transactions, involves contracts between consumer and their consumer/issuing financial institution, the consumer/issuing financial institution and the associations, the associations and the acquiring/merchant financial institution, as well as the acquiring/merchant financial institution and the merchant. this series of contracts creates obligations between the consumer and the merchant. furthermore, the acquiring/merchant financial institution stands behind the merchant (taking financial liability), and in return takes a percentage of every financial transaction.

In the title insurance scenario ... the relying party (consumer) pays the title insurance company for the certification (direct business contract between the relying party and the certification agency).

As mentioned, in the typical TTP/CA business operation there is no direct contractual relationship between the relying party and the certification agency.

slight drift, part of thread on caller id "spoofing"

which is the analogy between the URL and the webserver and is directly addressed by ssl domain name certificates ... which is different than the vulnerability created with the browser "click" disconnect. lots of past posts about ssl domain name certificates

for even more drift, a recent posting about frequent semantic confusion the result of having the word "signature" occur in both the terms "human signature" and "digital signature" When *not* to sign an e-mail message?

Posted by: Lynn Wheeler at March 6, 2006 03:46 PM
Post a comment

Remember personal info?

Hit preview to see your comment as it would be displayed.