Misc AADS & X9.59 Discussions


AADS Postings and Posting Index,
next, previous - home



Is The Public Key Infrastructure Outdated?
redundant and superfluous (addenda)
Public Key Infrastructure: An Artifact...
Public Key Infrastructure: An Artifact...
Public Key Infrastructure: An Artifact...
Public Key Infrastructure: An Artifact...
Public Key Infrastructure: An Artifact...
Public Key Infrastructure: An Artifact...
Public Key Infrastructure: An Artifact...
Public Key Infrastructure: An Artifact...
Public Key Infrastructure: An Artifact...
Thin PKI won - You lost
Thin PKI won - You lost

Is The Public Key Infrastructure Outdated?

Refed: **, - **, - **
From: lynn@xxxxxxxx
Subject: Is The Public Key Infrastructure Outdated?
Date: Tuesday November 14, @11:05AM EST (#128)
Website: slashdot.org
from lynn@xxxxxxxx
for years, centuries, etc ... businesses have used account records for binding of information regarding business processes. Many existing business processes today even have online, real-time access to such binding infrastructures ... and, in fact, require such real-time access. Many of these existing acocunt-based binding infrastructures also include authentication information and processes for non-face-to-face and face-to-face transactions ... included are such things like passwords, mother's maiden name, PINs, SSNss, signature cards, etc. Account Authority Digital Signatures
(AADS ... ref
https://www.garlic.com/~lynn/))
adds public key binding and digital signature authentiction (for both message integrity as well as authentication) to these existing business process, account-based, binding infrastructures. In fact, many of the existing "PKI" deployments have actually used certificates as a front-end facade ... and than fall-back on traditional account-based binding authentication for the real operation. AADS just eliminates the duplication, superfluous and redundancy introduced by the more traditional PKIs.

Is The Public Key Infrastructure Outdated?

Posted by CmdrTaco on Saturday November 11, @11:17AM

from the something-to-think-about dept.

dchat writes: Roger Clarke, Visiting Fellow, Faculty of Engineering and Information Technology at the Australian National University claims that the "Conventional, hierarchical PKI, built around the ISO standard X.509, has been, and will continue to be, a substantial failure", and then he goes on to explain why. I'd be interested in the views of Slashdot users, as my organisation is contemplating considerable investment in X.500 and PKI (including X.509). Lots to read here.

redundant and superfluous (addenda)

Refed: **, - **, - **, - **
From: lynn@xxxxxxxx
Subject: redundant and superfluous (addenda)
Date: Thursday November 16, @05:17AM EST (#129)
Website: slashdot.org
to a large extent, certificates are an answer to offline electronic authentication/security. compared to having no authentication/security in an offline environment, having a copy of some (potentially really stale) auuthentication/security information is better than nothing.

in that respect, certificates are analogous to the '60s "signing limit" corporate checks. Printed on each check was the maximum value that the check could be written for ... say $5000. The problem was that they started finding people that covered $1m transaction by signing 200 $5000 checks.

The 1990s online solution is corporate purchase cards ... a special form of credit cards. Standard credit card is real time transaction aggregation i.e. say an aggregate of credit limit of $50,000. To that can be added additional business rules on each transaction. Credit card transactions normally have had merchant type/code, merchant id, store id and total transaction amount. Purchase card transactions now carry SKU/item level detail (in addition to aggregate). Business rules can be written about transactions at type of merchant (say office stores), specific merchant, specific store and specific types of itmes (only pencils and staples) and individual transaction amount (no more than $20/day, no more than $500/month and only for pens less than $2 each). Also can do groups of account aggregation (all members in deparment can't spend more than $250/day & only at office stores).

In any case, if it is really offline ... then the certificate 1960s electronic offline paradigm is an improvement of no authentication/security at all.

However, if it is a 1990s electronic online paradigm, then offline, stale certificates repreasent a decrease in the level of authentication/security that could be done. Or what may happen is an attempt is made to implement both real online real security as well as an offline certificate security ... and there is significant cost & effort duplication (since the offline certificate effort is redundant and superfluous when the real online security is being done anyway).

Public Key Infrastructure: An Artifact...

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 11/19/2000 08:28 AM
To: Ben Laurie <ben@xxxxxxxx>, Bram Cohen <bram@xxxxxxxx>,
  obfuscation@xxxxxxxx, rah@xxxxxxxx, cryptography@xxxxxxxx,
cypherpunks@xxxxxxxx, dbs@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
oh yes, as to the other kinds of certificates.

basically this is an issue of trust establishment. there are various forms of trust establishment, advertisement, brand, word-of-mouth, previous history, etc ... not just BBB or consumer report like stuff.

Transactions are highly skewed ... with the majority of transactions having some form of trust establishment not needing BBB, consumer report, etc. (i.e. previous history, brand, etc)

on the internet, for the minority of transaction w/o other forms of trust establishment and which would benefit from a BBB, consumer report, etc solution ... there can actually be two approaches:

1) offline paradigm; certificates are offline paradigm solution ... they've been manufactured at some time in the past with potentially out-of-date and/or really stale information.

2) online paradigm; a BBB, consumer report, etc online web site that gives up-to-date, real-time information about a merchant. these would be well-known web-sites and merchants could even have buttons that take the consumer to such a web-site.

Some number of the certification, licensing, & trust organizations have actually expressed preference for the online paradigm, in part because it creates a tighter bound with the consumer, they have better tracking of consumer reliance on their services, and the information provided is current & up-to-date.

Public Key Infrastructure: An Artifact...

From: Lynn Wheeler
Date: 11/19/2000 08:29 AM
To: Ben Laurie <ben@xxxxxxxx>
cc: Bram Cohen <bram@xxxxxxxx>, obfuscation@xxxxxxxx,
rah@xxxxxxxx, cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
dbs@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
actually ... not really ... this was discussed early this summer as to what they actually check ... and how trivial it is to fabricate necessary details to pass such checking

random ref:


https://www.garlic.com/~lynn/aadsmore.htm#client3

in general it is sufficient to have registered any DBA name & have a d&b entry plus some misc. other stuff ... all relatively easy to establish. Since the DBA name & d&b entry aren't cross-checked as part of the SSL certificate validation ... just the domain name in the certificate against the domain name used ... you could be really surprised at what comes up for DBA names.

I've had credit card statements that listed the DBA names which had absolutely no relationship to the name of the store I had been to ... which i eventually had to call both the credit card company/bank and the store to figure out what was going on.

Ben Laurie on 11/19/2000 04:08:39 AM
The difference is that a CA _also_ binds the certificate to a legal entity. When the fraud is discovered, the identity of the fraudster is, too.

Cheers,
Ben.

Public Key Infrastructure: An Artifact...

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 11/19/2000 12:37 PM
To: Ben Laurie <ben@xxxxxxxx>
cc: Bram Cohen <bram@xxxxxxxx>, obfuscation@xxxxxxxx,
    rah@xxxxxxxx, cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
dbs@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
specifically with respect to SSL server certificates ... their primary objective was supposedly to overcome shortcomings in the domain name infrastructure integrity (and as stated, most of the SSL server certificate issuing entities actually also have dependencies on that integrity). Fixes for the integrity of the domain name infrastructure ... eliminates the domain name infrastructure as a business case/justification for the existance of those certificates.

Specifically with respect to SSL server certificate, the remaining issue is possibly merchant/server trust (not trust with respect to internet operational integrity ... but fusiness/fraud trust with respect to the business operation of the merchant/server). Establishing that trust goes beyond just having the comfort that if you are defrauded that you might be able to identify the guilty party. That can be addressed with an online BBB &/or consumer report type of service providing real-time information.

Eliminating both justifications for SSL server certificates ... then makes the vast majority of the existing SSL server certificates redundant and superfluous (and I believe would severely impact the business case justification for setting up an operation to provide such a service).

Now this is applicable to the current existing dominant PKI deployment in the world today (possibly accounting for 99.999999999% of instances where there is a certificate transmitted and a client checks the contents of that certificate). It possibly is not applicable to any other hypothetical PKI implementation which may or may not currently exist.

Ben Laurie on 11/19/2000 05:03:20 AM
This is not a comment on the crapness of PKI, it is a comment on the crapness of Verisign. The two are far from synonymous.

Don't get me wrong - I don't think PKI is a perfect solution by any means - however, it gets us nowhere to attribute the faults of others to PKI.

Cheers,
Ben.

Public Key Infrastructure: An Artifact...

Refed: **, - **, - **, - **, - **
From: lynn wheeler
Date: 11/20/2000 06:51 PM
To: Ben Laurie <ben@xxxxxxxx>
cc: Bram Cohen <bram@xxxxxxxx>, obfuscation@xxxxxxxx,
    rah@xxxxxxxx, cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
dbs@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
as pure asside ... any SSL server certificate signed by any CA in my browswer's CA list is acceptable.

for list of current valid signing CA's in a typical browswer see:

https://www.garlic.com/~lynn/aepay4.htm#comcert14
https://www.garlic.com/~lynn/aepay4.htm#comcert16

my broswer makes no distinction on which CA signed what ... and/or even what they signed. If I get a certificate signed by any CA in my browswers list that says foo.bar ... and I think i'm connecting to foo.bar ... then the SSL connection will go thru.

given that the supposed justification for SSL certificates is weaknesses in the domain name infrastructure integrity ... and they beef up the domain name infrastructure integrity (in part so that SSL certificate issuing operations ... like any from the above list ... can rely on domain names not having been hijacked) ... then it eliminates that as a business case & justification for SSL certificates.

There are a lot of short-comings of the existing SSL certificate infrastructure. To a large extent, most PKI definitions are purely hypothetical (there is the line someplace, in theory there is no difference between theory and practice, but in practice there is) ... trivial example is that most PKI definitions include things like CRLs for dealing with revoked or compromised certificates/private keys ... and yet the SSL infrastructure doesn't have any of that in it (even tho client checking of server SSL domain certificates accounts for 99.999999% of all such PKI operations that occur in the world today).

Ben Laurie on 11/19/2000 05:03:20 AM
This is not a comment on the crapness of PKI, it is a comment on the crapness of Verisign. The two are far from synonymous.

Don't get me wrong - I don't think PKI is a perfect solution by any means - however, it gets us nowhere to attribute the faults of others to PKI.

Cheers,
Ben.

Public Key Infrastructure: An Artifact...

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 11/22/2000 10:29 AM
To: "Arnold G. Reinhold" <reinhold@xxxxxxxx>
cc: Bram Cohen <bram@xxxxxxxx>, Ben Laurie <ben@xxxxxxxx>,
   obfuscation@xxxxxxxx, cryptography@xxxxxxxx,
cypherpunks@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
the other scenerio that some certification agencies have expressed (i.e. licensing bureaus, bbb, consumer report, etc operations) is that in the online world ... that they would provide an online service .... rather than certificates designed for an offline world. the online website provides a superior experience, real-time information, and a better binding between the certification agencies and the relying parties (i.e. current use of certificates totally disintermediate the certification authorities and the relying parties .... except in the scenerio where the certification authority and the relying party are the same ... in which case the certificates are redundant and superfluous).

in the shopping experience trust establishment ... trust can be established in a variety of ways, brand, advertisement, word-of-mouth, previous experience, etc. certification trust is just one of the many ways of establishing various kinds of trust. however, any certification trust in the online environment could be better provided by online certification delivery vehicle ... rather than an offline (certificate) vehicle (which disintermediates the certification agency and the relying party).

"Arnold G. Reinhold" on 11/22/2000 08:00:34 AM
At 1:59 PM -0800 11/20/2000, Bram Cohen wrote:
>On Mon, 20 Nov 2000, Arnold G. Reinhold wrote:
>
>> Perry's last sentence gets to the heart of the matter. If CAs
>> included a financial guarantee of whatever it is they are asserting
>> when they issue a certificate, then all these problems would go away.
>
>They aren't going to.
>
>-Bram Cohen
>
It's still early in the game to be so certain. But if you are right, that in it self is an indictment of PKI. If there really is a market for trust establishment and a form of PKI is the low cost producer of trust, then someone should be able to make money by using their expertise to assemble a technology suite and sell trust insurance based on the spread between the risk perceived by the market and what they know to be a lower risk. If such services never develop, it either means there is no market or PKI doesn't have enough economic impact to cover the costs of starting such a business. Arnold Reinhold

Public Key Infrastructure: An Artifact...

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/23/2000 12:14 PM
To: Mark Scherling <mscherling@xxxxxxxx>
cc: Bram Cohen <bram@xxxxxxxx>,
    "Arnold G. Reinhold" <reinhold@xxxxxxxx>,
Ben Laurie <ben@xxxxxxxx>, obfuscation@xxxxxxxx,
cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
Basically cetificates are an implementation of R/O partial replicated distributed data that were intended to address availability of information in a predominately offline environment.

In the SSL server certificates, distribution of CRLs tend to create a problem for consumers because they aren't likely to want to see 99.99999999999999999999% of the CRLs distributed and/or they aren't online at the time the CRLs are distributed (and/or if done via email would create a horrible spam issue ... every possible consumer in the world receiving email CRLs from every possile SSL server certificate issuing CA).

The other solution is to go online and do real-time checks ... but doing real-time checks invalidates basic design decision trade-offs associated with choosing a R/O partial replicated distributed data implementation in the first place.

A number of other efforts have looked at the trade-offs associated with large distributed data implementations and have made various different implementation decisions based on different criteria & requirements. Some of the partially replicated data implementations have gone to the trouble if 1) truely offline, R/O replicated data that has low change frequency, and possible adverse effects of dealing with stale data is non-existent or 2) support R/W partial replicated distributed data with various dictionary implemenations keeping track of the "current" R/W owner.

However, in the case of both having R/O replicated distributed data and also requiring online access ... creates a situation where the R/O replicated distributed data implementation is redundant and superfluous (except in some scenerios where the packet of R/O replicated distributed data is significantly larger than the transaction to check on its staleness ... aka multi-megabyte documents might be an example).

It isn't that you can't have perfect R/O replicated distributed data implementation if there is also concurrent real-time access to the original data ... but that usually invalidates the design decisions trade-offs that justified having a R/O replicated distributed data implemenation in the first place.

The degree of redundancy and superfluous becomes more significant as outlined in the SSL server certificate case ... where 1) in large part SSL server certificates are justified to address integrity weaknesses in the domain name infrastructure, 2) SSL server certificate issuing agencies are dependent on the domain name infrastructure as the authoritative source associated with proofing information for issuing an SSL server certificate, 3) correcting integrity weaknesses in the domain name infrastructure (needed by the SSL server certrificate issuing agencies) by registering public keys with domains names, 4) said registered public keys can both a) eliminate integrity weaknesses justifying SSL server certificates and b) be distributed as part of domain name server real time request to the client ... which then can be used in a much more efficient SSL protocol implemenation.

A possibly better phrase is that in a large number of cases revokation isn't practical w/o real-time access to the original data ... but real-time access to the original data obsoletes the need for revokation (by obsoleting the necessity for R/O partial data replication which might require revokation).

The issue in many scenerios isn't that revokation can't work ... it can work if you have real time access to the original data ... which obsoletes the requirement for R/O partial data replication which in turn obsoletes the requirement for revoking R/O partial data replication. The ideal solution for revokation is somehting of a catch-22 ... the ideal solution for revokation also removes the requirement for revokation (somewhat analogous to the catch-22 for solving the problem that SSL server certificate issuing agencies have with domain name server infrastructure integrity issues ... the solution is also the seed for obsoleting the need for issuing SSL server certificates).

Mark Scherling on 11/23/2000 09:24:51 AM
I would like to get further information as to why you don't think revocation does not work? I'll admit that in the case of the revocation of Sun's certificates, it was very apparent that the notification process was weak. The other piece, the browser checking of expired/revoked certificates is non-existent but if you properly set up your application, it "should" check the revocation status of both the CA certificate and the subscriber's certificate.

Your thoughts?

Bram Cohen wrote:

> On Wed, 22 Nov 2000 Lynn.Wheeler@xxxxxxxx wrote:
>
> > the other scenerio that some certification agencies have expressed (i.e.
> > licensing bureaus, bbb, consumer report, etc operations) is that in the
online
> > world ... that they would provide an online service .... rather than
> > certificates designed for an offline world.
>
> Yes, it seems fairly well established that revocations just plain don't
> work.
>
> Once again, the solution to the problems of offline operation appears to
> be online operation.
>
> -Bram Cohen
>
> For help on using this list (especially unsubscribing), send a message to
> "dcsb-request@xxxxxxxx" with one line of text: "help".

Public Key Infrastructure: An Artifact...

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/23/2000 06:39 PM
To: Paul Crowley <paul@xxxxxxxx.uk>
cc: Mark Scherling <mscherling@xxxxxxxx>,
Bram Cohen <bram@xxxxxxxx>,
"Arnold G. Reinhold" <reinhold@xxxxxxxx>,
Ben Laurie <ben@xxxxxxxx>, obfuscation@xxxxxxxx,
   cryptography@xxxxxxxx, cypherpunks@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
the other way to look at it ... is why design something that is broken (i.e. offline certificates in an online world) and then turn around it have to patch it up (with various online CRLs) ... unless you are really interested in featuring how broken something is.

there use to be a company that sold a lot of copying machines in the '80s ... the product was one of the worst in the industry with regard to paper jamming. they came out with a television ad campaign highlighting how easy it was to fix paper jams in their product (compred to other products ... which of course you hardly ever had to worry about fixing paper jams).

misc. refs:


https://www.garlic.com/~lynn/rfcietff.htm

select terms in the above and then select SPKI ... rfc2692 & rfc2693

in many cases ... the use of (offline paradigm) certificaets are redundant and superfluous in an online environment ... much simpler to just register a public key with the relying party or if you prefer .... appended certificates, compressed to zero bytes ... significantly reducing the problem of revoking information carried in the zero byte certificate.


https://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2


https://web.archive.org/web/20010419074830/http://lists.commerce.net/archives/ansi-epay/199910/msg00006.html

in general


https://www.garlic.com/~lynn/

random. other


https://web.archive.org/web/20000226031418/http://weever.vic.cmis.csiro.au/~smart/tpki.html

Paul Crowley on 11/23/2000 03:15:52 PM
Lynn.Wheeler writes:

> The other solution is to go online and do real-time checks ... but
> doing real-time checks invalidates basic design decision trade-offs
> associated with choosing a R/O partial replicated distributed data
> implementation in the first place.
Have you looked at the design of SPKI CRLs? I think there are possibilities in there that address the difficulties you raise.

Public Key Infrastructure: An Artifact...

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/25/2000 08:44 AM
To: John Kelsey <kelsey.j@xxxxxxxx>
cc: Bram Cohen <bram@xxxxxxxx>, "Arnold G. Reinhold" <reinhold@xxxxxxxx>,
    Ben Laurie <ben@xxxxxxxx>, obfuscation@xxxxxxxx,
cryptography@xxxxxxxx, cypherpunks@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
public keys can be used to provide some degree of trust propagation w/o the problems associated with shared-secrets ... independent of key-exchange for session confidentiality.

certificates were designed to provide for offline trust propagation (i.e. trusted 3rd party generating paper credentials in the days of sailing ships ... for things like letters of credit).

two possible online scenerios for online trust propagation was online domain name infrastructure providing public key as part of online hostname resolution response ... and licensing/certification agencies providing public key as part of a trust lookup.

trust propagation also works going from highly authenticated environment ... which might register a public key with a relying party; to a quickly authenticated environment remote, non-face-to-face transactions with digital signature (the digital signature would be a mathematical encapsulation of the authentication business process that occured as part of public key registeration) . Asymmetric algorithms have some advantages over traditional shared-secret algorithms in that there can be lower maintenence expense at the relying party (i.e. security exposure associated with divulging a shared-secret).

random refs:


https://www.garlic.com/~lynn/2000f.html#1
https://www.garlic.com/~lynn/2000f.html#3

John Kelsey on 11/24/2000 12:59:42 PM
At 04:47 PM 11/22/00 -0800, Bram Cohen wrote:
>On Wed, 22 Nov 2000 Lynn.Wheeler@xxxxxxxx wrote:

>>the other scenerio that some certification agencies have
>>expressed (i.e. licensing bureaus, bbb, consumer report, etc
>>operations) is that in the online world ... that they would
>>provide an online service .... rather than certificates
>>designed for an offline world.

>Yes, it seems fairly well established that revocations just
>plain don't work.

>Once again, the solution to the problems of offline
>operation appears to be online operation.
And the annoying thing about this is that once we go to needing an online trusted third party to allow us to have secure communications, we may as well chuck the public key stuff and just use symmetric ciphers and the key exchange protocols worked out ten or fifteen years ago. Which makes me suspect that we're just not using public key mechanisms very intelligently yet. We've realized that screws are better for many jobs than nails, it's just that they're so damned hard to hammer in....

--John Kelsey

Public Key Infrastructure: An Artifact...

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 11/27/2000 02:37 PM
To: "Arnold G. Reinhold" <reinhold@xxxxxxxx>
cc: cryptography@xxxxxxxx, cypherpunks@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
problem is that consumer don't normally know that they want to check on a particular merchant's CRL entry until they realize that they want to go to that merchant site. in general, the consumer's aren't going to want keep a local (usenet) database of all CRL entries (however they are distributed) ... so it is more likely the ISP would have to keep all the entries ... pushed into a database ... and let the consumer do an online database lookup of the CRL entries (effectively the local ISP is keeping cached copy of all entries ... and uses usenet as the distribution infrastructure).

sometimes, usenet can take several hrs to a day to propagate ... so the person may still want to do an online transaction against the agency that issued a certificate

In which case, the local ISP would be considered a "stand-in" ... maintaining a negative file ... and returning positive answers if there isn't a match in the negative file for the online transaction ... in which case the consumer may still want to do another online transactions against the master file (located somewhere in the internet).

Given that online transactions are being performed ... then it may even be more straightforward to use domain name infrastructure to manage distribution and management of cached entries. It has a somewhat better online transaction semantics than usenet (already). However, since this is turning into online transaction infrastructure ... it is then possible to eliminate both the certificates and CRLs totally and just use the straight-foward domain name infrastructure.

back again to certificates typically being redundant and superfluous in an online infrastructure.

"Arnold G. Reinhold" on 11/27/2000 07:53:35 AM
At 11:17 AM -0800 11/23/2000, Lynn.Wheeler@xxxxxxxx wrote:

>Basically cetificates are an implementation of R/O partial replicated
>distributed data that were intended to address availability of
>information in a
>predominately offline environment.
>
>In the SSL server certificates, distribution of CRLs tend to create a problem
>for consumers because they aren't likely to want to see
>99.99999999999999999999%
>of the CRLs distributed and/or they aren't online at the time the CRLs are
>distributed (and/or if done via email would create a horrible spam issue ...
>every possible consumer in the world receiving email CRLs from every
>possile SSL
>server certificate issuing CA).
Sounds like a job for Usenet.

Arnold Reinhold

Thin PKI won - You lost

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/15/2000 11:01 AM
To: Camillo Särs <Camillo.Sars@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
    PKIX-List <ietf-pkix@xxxxxxxx>
Subject: Re: Thin PKI won - You lost
in retail electronic transactions ... not only is "identity" fairly irrelevent ... it represents privacy compromise

that is one reason that some of the european parties a couple years ago went to relying-party-only certificates ... we've been able to show for 3-4 years that using certificate compression techniques that such certificates can be highly compressed to zero bytes (redundant and superfluous to repeatedly resend copies of information to the relying party that has the original copy of the information).

the real issue is does any of the transactions have to be offline. the analogy is the business paper checks of the '60s that had signing limits ... until they found that people were signing 200 individual checks to achieve their results.

certificates (of whatever kind) represent offline trust propagation between entities with no prior business relationship. as online becomes more & more prevalent and online costs drop, the threshold justifying not doing things online is dropping. the typical current day replacement for the '60s signing limit paper checks is a corporate purchase card, akin to a form of (online, electronic) credit card, that in addition to the familiar credit limit (i.e. real time aggregated balance), also can have business rules about things like merchant type, specific merchant, merchant location, and SKU (product) codes.

x9.59 (financial industry standard for all electronic account-based retail transactions) addresses all of this.

the response (to the merchant) doesn't currently have to be signed for authentication purposes because it comes in via a trusted network. One could imagine migration to a non-trusted network implementation for the response ... reguiring signed authentication. However, because of the required prior business relationships there isn't a requirement for offline trust propagation, the public key of the responding merchant financial entity is simply installed at the merchant (possibly in a manner similar to the way that root public keys are delivered in browsers, but under somewhat more strict business controls).

one way of characterising a much thiner form of PKI uses highly optimized compression techniques for redundant and superfluous information transmission reducing certificate to zero bytes in cases of online transaction between entities with prior business relationship (i.e. in the retail transaction scenerio, there is a consumer instruction to the consumer's financial institution, and the response is an instruction from the merchant's financial institution to the merchant).

the transaction value threshold for offline trust propagation involving certificates that haven't been compressed to zero bytes is dropping as online becomes more & more ubiquitous and the corresponding cost of online drops.

Camillo Särs on 12/15/2000 04:46:17 AM
I tend to agree with you. For most on-line transactions, the concept of "identity" is fairly irrelevant - the real issue for the relying party is the authorization to perform an action. Once the high-level legal trust relationships exist [Read: "If you cheat, we will sue you out of business."], the remaining issues are mostly about transferring authorization - delegation - and avoiding fraud by the users.

Thin PKI won - You lost

From: Lynn Wheeler
Date: 12/15/2000 11:03 AM
To: Camillo Särs <Camillo.Sars@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
PKIX-List <ietf-pkix@xxxxxxxx>
Subject: Re: Thin PKI won - You lost
the response (to the merchant) doesn't currently have to be signed for authentication purposes because it comes in via a trusted network. One could imagine migration to a non-trusted network implementation for the response ... reguiring signed authentication. However, because of the required prior business relationships there isn't a requirement for offline trust propagation, the public key of the responding merchant financial entity is simply installed at the merchant (possibly in a manner similar to the way that root public keys are delivered in browsers, but under somewhat more strict business controls).

of course one could quibble whether the above referenced signed response is a thin certificate or not. it could look & taste like a thin certificate ... the primary business difference between a thin certificate and a signed transactions ... is one (the certificate) is signed before the transaction (and might possibly be used for multiple transactions) and the other (signed transaction) is specific to the current transactions. In effect, the thin certificate has the liable party signing something for offline trust propagation that they might not have exact knowledge of before hand. As a thin PKI makes more & more of the transition to online ... it eventually crosses the business line from doing pre-authorized signatures to signing the actual transactions.


AADS Postings and Posting Index,
next, previous - home