trusted repositories and trusted transactions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Date: Tue Apr 04 2006 - 17:52:41 CEST

ref:
http://www.garlic.com/~lynn/2006f.html#15 trusted certificates and trusted respositories

part of the x.509 identity certificate stuff from the early 90s was
some forces trying to increase the perceived value of the certificate
by grossly overloading it with every possible piece of personal
information. the counterforce that started to show up by the mid-90s
was the realization that x.509 identity certificate grossly overloaded
with personal information represented significant privacy (and even
liability) issues.

as a result there was some retrenchment in the mid-90s to
relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

these were certificates that contained a public key and a record
locator for a repository of information that wasn't generally publicly
available. the necessary personal information needed by the relying
party was in this trusted repository (and not publicly available).
however, it almost every transaction oriented scenario, it was trivial
to demonstrate that the 1) actual transaction also carried the record
location (like an account number) and since this was a
relying-party-only certificate, the relying-party already had a copy
of the public key (having certified and issued the original digital
certificate). As a result, it was trivial to demonatrate that the
existance of any digital certificate was redundant and superfluous.

the other issue with the trusted transaction scenario is that it tends
to be extremely focused on some actual business process. rather than a
paradigm of static information public repository, a trusted
transaction can take into account many factors, like real-time
aggregated information. for a financial example, a trusted repository
of stale, static information might not only have the account number,
but the actual account record including past transactions and possibly
the account balance at some point in time. rather than a merchant
sending off a request for copy of your digital certificate (certicate
respostiory) or a copy of your account record (trusted respository,
with all possible account related personal information, including
current account balanace); the merchant can send off a digitally
signed transaction asking if a operation for a specific amount is
approved or not. The yes/no response divulges minimum amount of
personal information.

so trusted certificate/credential model tends to be a left-over from
the offline world where relying parties did have their own information
regarding the matter at hand and also didn't have access to a trusted
party (as source of the information). offline credential/certificate
paradigm tended to be pre-occupied with forgeriess of the
certificate/credential.

the trusted repository model tends to move more into a more modern
online era. however, it has tended to have more generalized
collections of information ... not necessarily being able to predict
what infomration relying parties might actually be in need
of. however, especially when individuals have been involved, trusted
repositories of general information have tended to represent
unnecessary disclosier of sensitive and/or personal information.

the trusted transaction model has tended to be much more valuable
operation, in part because dynamic operations associated with real
business processes can be taken into consideration. at the same time
the transactions are frequently designed to make minimize unnecessary
disclosier of sensitive and/or personal information.

my joke left-over from the mid=90s was about various suggestions that
the financial/payment infrastructure be moved into the modern era by
attaching (relying-party-only) digital certificates to every
transaction. my reply was that the offline paradigm digital
certificate would actually be setting back the financial/payment
infrastructure to pre-70s days before online, realtime transactions.

it was possible to have digitally signed financial transactions for
purely authentication purposes. the responsible financial institution
could validate the digital signature with the onfile public key
... and any digital certificate was purely redundant and superfluous.
the online transaction could come back approved or declined ... which
is much more valuable to merchants ... than a credential certifying
that at some point in the past you had opened a bank account.

the x9.59 financial standard scenario
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

even required that account numbers used in x9.59 transactions could
not be used in non-authenticated transactions. this had the
characteristic that skimming/harvesting/data-breach threats against
account numbers for fraudulent transactions was eliminated. all the
data-breaches in the world against files containing account numbers
wouldn't enable a crook to take just the account number and use it in
a fraudulent transaction.

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Received on Mon May 1 01:55:06 2006

sci.crypt archive

trusted repositories and trusted transactions