From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Hard disk architecture: are outer cylinders still faster than inner cylinders? Newsgroups: comp.arch Date: Sat, 07 Aug 2004 01:19:48 -0600"Bill Todd" writes:
1) in the late 70s, we took detailed record level access traces on a number of different production systems ... and ran it thru a file i/o cache simulator. for a fixed amount of electronic storage ... having a single large file i/o cache always outperformed any partitioning of the electronic memory between channels, controllers, and/or devices (modulo enuf electronic memory for things like track buffer to do rotational compensation)
2) when i was an undergraduate in the 60s, i developed global LRU replacement clock algorithms. later in the early 70s side-by-side comparisons showed it outperformed an implementation of local LRU replacement algorithm (described in the '60s literature aka local LRU basically did semi-static fixed partitioning of available memory and then did "local" LRU replacement within the partitioning).
collection of postings on clock replacement
https://www.garlic.com/~lynn/subtopic.html#wsclock
random posts mentioning global LRU & local LRU replacement strategies
https://www.garlic.com/~lynn/94.html#1 Multitasking question
https://www.garlic.com/~lynn/96.html#0a Cache
https://www.garlic.com/~lynn/96.html#0b Hypothetical performance question
https://www.garlic.com/~lynn/98.html#54 qn on virtual page replacement
https://www.garlic.com/~lynn/99.html#18 Old Computers
https://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000f.html#34 Optimal replacement Algorithm
https://www.garlic.com/~lynn/2000f.html#36 Optimal replacement Algorithm
https://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names
https://www.garlic.com/~lynn/2002o.html#30 Computer History Exhibition, Grenoble France
https://www.garlic.com/~lynn/2003f.html#55 Alpha performance, why?
https://www.garlic.com/~lynn/2003g.html#55 Advantages of multiple cores on single chip
https://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
https://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Hard disk architecture: are outer cylinders still faster than inner cylinders? Newsgroups: comp.arch Date: Sat, 07 Aug 2004 08:22:55 -0600"Bill Todd" writes:
when I was working on the distributed lock manager for ha/cmp ...
https://www.garlic.com/~lynn/subtopic.html#hacmp
many environments had large database caches. the state-of-the-art at
the time tended to be when a cached/locked record had to move to a
different processor ... the lock could move directly via
inter-processor communication ... but the record itself tended to be
pushed to disk first. so i spent a lot of time working on letting the
record piggyback on the lock transmission w/o having to first go to
disk (direct inter-cache transmission). this tended to create the
appearance of a large distributed cache. the problem actually wasn't
allowing records to float around the different caches ... it was the
recovery after a failure. each processor had its own log of comitted
transactions ... forcing the record to disk prior to moving it between
processors resulting in the "current" record image being represented
by, at most, the log of the current active processor for that record.
if the record wasn't forced to disk prior to moving, the most current
active image might be either the current processor log ... or the log
of some previous processor the record had visited. In which case, you
effectively had to maintain some sort of consistent record versioning
information across the available logs ... in order to reconcile on
recovery after a failure. misc. past dlm posts
https://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
https://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001j.html#47 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2002e.html#67 Blade architectures
https://www.garlic.com/~lynn/2002f.html#1 Blade architectures
https://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
misc. past post about trying to eliminate outboard "duplicates" of
things that exist at the system level (so that the outboard isn't
totally redundant and superfluous) ... note that dup/no-dup also
applies to large memory paging and whether or not to maintain
backing store allocation for pages that are also in real memory
https://www.garlic.com/~lynn/93.html#12 managing large amounts of vm
https://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
https://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
https://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File
https://www.garlic.com/~lynn/2001l.html#55 mainframe question
https://www.garlic.com/~lynn/2001n.html#78 Swap partition no bigger than 128MB?????
https://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#16 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#19 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
https://www.garlic.com/~lynn/2002f.html#20 Blade architectures
https://www.garlic.com/~lynn/2002f.html#26 Blade architectures
https://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
https://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
https://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004h.html#19 fast check for binary zeroes in memory
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sat, 07 Aug 2004 08:51:17 -0600note that one of the issues with stale, static certificates ... is that from an information theory standpoint ... they are effectively free floating cached information ... which might show-up in a large number of unknown (and possibly unknowable) locations. the cryptography aspect of certificates are primarily attempting to insure the certificate long-term static integrity .... but has little or nothing to do regarding the currancy or usefulness of the (cached) information.
however, given the design point of an offline environment ... where the relying party otherwise has recourse to no other information ... the certificate paradigm represents something that is better than the alternative ... nothing.
an issue is what use is there for some stale, static, cached information paradigm designed for the offline environment ... in an online world where the relying party could have access to dynamic, real-time information. there is some contention that such certificate paradigm could find a market niche for transactions that are of such low-value ... that otherwise it doesn't make financial sense to resort to an online operation. one of the problems is that as the internet paradigm becomes ubiquitous the cost of performing online operations is descreasing .... which in turn reduces the possible low-value market niche for certificate-oriented operation.
the other issue facing the certificate offline paradigm is that they somewhat have positioned themselves as an high-integrity solution. the problem comes up is that high-integrity operations tend to be costly. however, if the solution is really relegated to the no/low value market niches ... it is difficult to come up with sufficient cash flow to maintain a high-integrity operation. inability to underwrite any sort of high-integrity operation would even further restrict the no/low value market niche appropriate for certificate use.
minor recent post with respect to cache coherency
https://www.garlic.com/~lynn/2004i.html#1
... this is respect to work i had done in ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
with respect to distributed lock manager and maintaining
database consistency across a large number of distributed
processors.
another minor reference
https://www.garlic.com/~lynn/95.html#13
which turns out to have some relationship to the work done for the
stuff called electronic commerce ... mentioned previously
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Univac 9200, 9300: the 360 clone I never heard of! Newsgroups: alt.folklore.computers Date: Sat, 07 Aug 2004 11:22:44 -0600jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sat, 07 Aug 2004 12:02:08 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
nope, people just have to trust something. the motivation for SSL domain name server certificates were trust issues about the domain name infrastructure and whether the server you thot you were talking to was actually the server that you were talking to.
in fact, SSL domain name server certificates have absolutely nothing at all to do with whether the client can trust the server ... it is just whether the server that the client thinks it is talking to is actually the server that it is talking to.
what it is you are trusting can be precisely defined in this case by explicitly describing what the threat model is ... and exactly what the countermeasures are designed to achieve.
for whatever reason, the exact trust model of what SSL domain name server certificates have frequently been severely obfuscated ... possibly as an objective in obfuscating exactly what the value of SSL domain name server certificates represent.
it is one of the reasons that we coined the term certificate
manufacturing early on ... in order to differentiate from theoretical
PKI models. It is also why I've frequently mentioned "merchant comfort
certificates"
https://www.garlic.com/~lynn/subpubkey.html#sslcert
because frequently there is a very confused understanding of what it is that SSL domain name server certificates actually accomplish.
In point of fact, the authoritative agency ... for domain name ownership and supposedly the arbitrator of whether the server that you are talking to is actually the server you think you are talking to ... is the domain name infrastructure.
My repeated past comments is that a prime motivation for SSL domain name server certificates are because of trust & integrity issues with the authoritative agency for domain name ownership ... the domain name infrastructure.
Also, as I've repeatedly stated before .... when a certification authority gets an application for an SSL domain name server certificate ... the certification authority is also dependent on the authoritative agency for domain name ownership (aka the domain name infrastructure) ... as much so as everybody else.
If there are issues with the integrity of the domain name infrastructure with regard to the true ownership of a domain name ... it can affect the integrity and quality of the information that a certification authority is certifying .... aka if all the clients in the world have trust and integrity concerns with regard to the domain name infrastructure ... and all the certification authorities in the world as as dependent on the integrity of the domain name infrastructure (as all the clients in the world) for the integrity of the information they are certifying ... then there can be a serious issue with the integrity of the information that has been certified by a certification authority.
If a certification authority is dependent on an untrusted authoritative agency for the information it is certifying .... then just because you have placed the certified information inside a certificate that has been armored by digital signatures .... doesn't make the armored information true or valid ... it just indicates that the certification authority believes it to be true.
If the authoritative agency that is responsible fur the true and valid accuracy of the information (in the case of SSL domain name server certificates) has integrity issues ... then that propagates to any such copies of that information, whether or not it has been armored inside a digital certificate with digital signatures from a certification authority.
The only thing that a armored digital certificate is a countermeasure for is the integrity of the information after it leaves the domains of the certification authority (and/or the authoritative agency that is the source of the information). If the original information that a certification authority gets is wrong ... it doesn't correct it by placing that information inside an armored digital certificate ... this is the GIGO theory of data processing applied to certification authorities and digital certificates ... aka garbage-in, garbage-out.
The previous postings gave a detailed description that the certification authorities are dependent on the authoritative agency for domain name ownership when creating a SSL domain name server certificate.
The authoritative agency for domain name ownership is the domain name infrastructure. A prime motivation for SSL domain name server certificates were integrity concerns about the domain name infrastructure. However, the certification authority industry is also dependent on the domain name infrastructure as the authoritative agency for domain name ownership. If the domain name infrastructure has an integrity problem and the domain name ownership information is wrong ... having a certification authority take the wrong information from the domain name infrastructure and place it in an armored SSL domain name server certificate ... doesn't make it less wrong. If the information is wrong ... it is wrong ... whether or not it is in a certificate.
As repeated many times before ... that is one of the reasons that
I've used the description merchant comfort certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcert
when applied to this stuff some people call electronic commerce
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
... trying to make the description even simpler ... the original, proper description for CAs was "certification authorities" ... not "certificate authority". It was to distinguish that they weren't actually the authoritative agency for the information being placed in an armored digital certificate ... it was just that they went thru some number of processes to "certify" the information that they were placing in an armored digital certificate (somewhat analogous to a notary).
However, if the process that a notary goes thru to certify something is based on incorrect information .... it doesn't invalidate the notary process ... but it doesn't also magically make incorrect information, correct.
the analogy to the integrity issues with regard to domain name infrastructure ... is all of a sudden everybody lost all trust in drivers licenses and demanded that people have a notarized statement as to who you were; and it turns out that the process that notaries use for generating a notarized statement as to who you are ... is by checking your drivers license.
If everybody had lost trust in drivers license as being valid ... having a notary public also check the drivers license and sign a notarized document attesting to who you are (based on having also checked a drivers license) ... wouldn't actually improve the integrity level much (if at all).
You have to understand what the lack of trust issues are.
You have to understand what the additional certification operations are actually performing.
You have to understand that whether the certification operations are performing anything meaningful ... other than the things that you already don't trust.
You have to understand that digitally signed armored digital certificates are a countermeasure for the information being modified after it has left the certification authority. However, it the exploit/vulnerability is with regard to the integrity of the information from the authoritative agency responsible for the information ... having a certification authority armor incorrect information inside a digitally signed digital certificate ... can't make incorrect information correct.
In most instances, a certification authority is there to certify that it has validated some information with some authoritative agency responsible for the validity of the information. If there are integrity issues with that authoritative agency responsible for the validity of the information, placing suspect information inside a digitally signed armored digital certificate doesn't wave a magic wand over incorrect information, making it correct.
There is nothing magic about a digital certificate.
There is nothing magic about certification authorities
Certification authorities and digital certificates can also be subject to GIGO.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sat, 07 Aug 2004 13:05:32 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
certificates are credentials targeted for relying parties that don't have recourse to any other trust mechanisms.
certificates were originally designed as credentials for offline environments where the relying parties didn't have recourse to any other trust mechanisms.
certificates are just one possible mechanism for establishing trust with relying parties ... and specifically designed for relying parties having some basis for trust when they had no other recourse to trust mechanisms.
after having worked on this thing that came to become electronic
commerce and payment gateway:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
i wrote some amount about certificates compared to online credit card
model business infrastructure ... some of it is included in the
multitude of posts ... including references to merchant comfort
certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
prior to the 70s, credit cards were offline credentials and the credit card process was an offline process. people carried around their offline credentials, went into merchants with their offline credentials and performed offline financial transactions.
there are basically four operational quadrants
1) offline and physical (original credit card) 2) online and physical 3) offline and electronic (where certificates play) 4) online and electronic
the threat model to the offline and physical transaction included lost and stolen cards ... but also included valid person charging way more than they were allowed to.
going to a very expensive anti-theft and anti-counterfeit credential in the 70s would have only address the lost and stolen threat model. it could not address whether the correct person was doing things that they shouldn't. also, including stuff like credit limit in a static, offline credential would represent a major privacy threat. furthermore, the actual credit limit isn't the real matter ... the real information of interest is the real-time, non-stale, aggregated information referred to as "open-to-buy" ... i.e. the credit limit minus the outstanding charges.
so it turned out that the online technology was starting to come down so fast ... that it was possible to make a cost effective change from "1" (offline and physical) ... directly to "4" (online and electronic) ... skipping the intermediate technology steps like certificates have been trying to do.
The electronic mechanism wasn't really the most spiffy (i.e. magnetic stripe) ... but it was cost effective for its time. Also the online process was not only able to address the timely and aggregated information of "open-to-buy" ... but also at least bound the lost & stolen card issue ... by being able to report the card lost&stolen and have the account disabled.
so we move forward 20 years to the early 90s, the x.509 identity certificates were in a catch-22 .... they were on one side trying to add more and more identity related information to the identity certificates ... trying to establish a viable value proposition for having identity certificates ... while at the same time ... many people were starting to realize that having any information in an x.509 identity certificate represented server privacy and liability issues.
so we move forward to the mid-90s ... where some financial institutions started looking at relying-party-only certificates .... basically a certificate that contained a public key and an account number ... with no other useful information.
the scenario is you walk into your financial institution and register your public key ... they put it on file in your account record ... and then issue you a digital certificate.
then the next time you do a financial transaction ... instead of just the standard 60-byte transaction ... you append a 128-byte digital signature to it and a 4k-12k byte certificate and send it off. It eventually arrives at your financial institution ... they pull the account number out of the transaction and retrieve your account record. the account record also contains your public key ... which they use to verify your 128-byte digital signature. The digital certificate turns out to be totally redundant and superfluous ... other than to increase the payload bloat of the transaction by a factor of one hundred times.
as an aside ... there were some number of random other proposals from the mid-90s era about using certificates for implementing totally offline financial transactions. however, from the stand point of the business process of performing financial transactions ... that represented effectively regressing the financial industry at least 25 years back into the dark ages.
so how would a certificate-less, trusted process work (w/o having to resort to certificates):
1) in order to do credit card transactions, the consumer has to register with their financial institution .. and therefore can also register their public key for the consumer account.
2) in order to do credit card transactions, the merchant has to register with their financial institution ... and therefore can also register their public key for the merchant account. the merchant also must load some financial institution specific software ... which can include the merchant's financial institution public key.
3) nominally when the consumer is executing a transaction with the merchant, the merchant's primary concern is not who the person is ... but whether they get paid.
4) the consumer does a DNS transaction and gets back the ip-address and the unarmored/naked public key of the merchant server (as per the previous description of the certification authority industry objective of improving the integrity of the domain name infrastructure)
5) the consumer does a pseudo SSL-like transaction with the merchant server, but instead of relying on a certificate from the merchant in order to obtain the merchant public key ... it uses the merchant public key it gets from the domain name infrastructure
6) the consumer can digital sign a transaction and send it to the merchant. the merchant has no real idea who the consumer, but the merchant is interested in knowing that they will get paid.
7) the merchant takes the signed consumer transaction and can digital sign it and package it with a little bit more ... and send it to the merchant's financial institution
8) the merchant financial institution can verify the merchant's digital signature with the public key on file in the merchant account.
9) the merchant financial institution forwards the transaction to the consumer's financial institution. the consumer's financial institution validates the consumer's digital signature with the public key on file for that account record.
10) if everything is satisfactory ... not only the digital signature, but all the other criteria for approving a transaction ... the consumer's financial institution approves the transaction and sends an affirmative response to the merchant's financial institution.
11) the merchant's financial institution digitally signs the affirmative response and forwards it to the merchant.
12) the merchant gets the affirmative response and validates the digital signature of the merchant's financial institution with the public key that the merchant has on file when it installed the merchant financial institution software.
13) the merchant now knows that they are going to get paid ... and they don't really need to know who the consumer is.
============================================================
so the above description has a whole bunch of trusted operations that make absolutely no use at all of digital certificates ... for at least two reasons:
I) the relationships of importance all involve prior business relationship ... while there is a financial transaction that sort of flow between the consumer and the merchant ... the merchant doesn't have to know or trust the consumer ... the merchant just has to be relatively confident that they are going to get paid
II) it is all online
this is effectively the x9.59 scenario
https://www.garlic.com/~lynn/x959.html#x959
now there is actually a business feature of the x9.59 standard involving the whole idea of shared-secrets. the primary use of SSL encrypted channels (step number #5 in the above described process) involves hiding the credit card account number from eavesdropping with SSL encrypted channel.
this has a real problem ... because since at least the mid-90s, the primary vulnerability/exploit on account numbers haven't been eavesdropping exploits (which SSL is a countermeasure for), but harvesting the merchant transaction files ... which can contain hundreds of thousands or millions of account numbers.
almost all of the internet oriented stuff has been oriented around trying to preserve the secrecy of the account number (as a shared-secret) with massive amounts of encryption. however, none of the transmission protocol encryption has in any way addressed the major vulnerability/exploit of account numbers on the internet ... the harvesting of the merchant transaction file by either insiders or outsiders.
what x9.59 standard does is state that account numbers used in digitally signed x9.59 transactions can NOT be used in non-authenticated transaction.
the current account number vulnerability as a shared-secret ... is that anybody learning the account number value can use that information in some number of unauthenticated fraudulent transactions.
the x9.59 business rule says that regardless of the number of people that might learn the value of the account number ... it does them no good .... since it will no longer work in an unauthenticated transaction. this removes x9.59 associated account numbers from the domain of shared-secrets. As a result, x9.59 associated account numbers are no longer vulnerable to merchant transaction file harvesting (by either insiders or outsiders). Furthermore, it also makes x9.59 associated account numbers vulnerable to fraud exposure by internet eavesdroppers. Therefore it is no longer a requirement to use SSL encrypted sessions to preserve the secrecy of the credit card account numbers (from criminals who would use it in non-authenticated fraudulent transactions).
some amount about x9.59 with regard to privacy
https://www.garlic.com/~lynn/subpubkey.html#privacy
some general number of posts on exploits, vulnerabilities, threat
models, and fraud:
https://www.garlic.com/~lynn/subintegrity.html#fraud
some general number of posts on assurance
https://www.garlic.com/~lynn/subintegrity.html#assurance
it turns out that the requirement placed on the x9a10 standards working group for doing the x9.59 standard was to preserve the integrity of the financial infrastructure for all retail payments ... aka a standard that could be used for ALL retail payments; internet, point-of-sale, atm machine, credit, debit, ach, ... aka ALL.
applying just a digital signature to an x9.59 transaction preserves the integrity of the x9.59 transaction (in manner similar to armoring a digital certificate by digitally signing it) ... however, since account numbers used in x9.59 transactions can no longer be used in non-authenticated transactions ... it is no longer necessary to keep the account numbers secret in order to preserve the integrity of the financial infrastructure. somewhat at issue was that the major exploit/vulnerabilities to the account number was that it was subject to insider capture (insiders are at least 77 percent of the fraud and possibly 95 percent) and that there were a large number of different business processes requiring the account number to be in the clear and accessible by insiders.
eliminating the account number as a shared-secret does more for
preserving the integrity of retail transactions that completely
burying the whole surface of the earth under a uniform mile thick of
encryption.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sat, 07 Aug 2004 13:13:18 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
.... certificates are useful for establish trust between people ... who don't otherwise know each other ... if
1) the people don't have direct access to the trust source ... and that timely and aggregated online information is of a lot more trust value than stale, static redundant and superfluous certificate-based information
2) any trusted certificate information has any significant meaning to business process at hand between the two individuals.
in part II ...
i described that a merchant/consumer relationship ... where the merchant doesn't know the consumer ... is primarily concerned with whether they will get paid ... and it is possible for online certificate-less transactions (even digitally signed transactions) to establish that.
I also described that the early 90s x.509 identity certificates that were in the process of getting overloaded with all sorts of identity related information ... attempting to discover some valid value proposition ... ran into a significant privacy and liability barrier
Part of the problem, with regard to item #2 (from this post) is whether or not any of the types of information that might be contained in a stale, static certificate is in anyway meaningful for normal business processes that otherwise unacquainted entities might want to perform. Typically, it doesn't come down to identity ... but whether or not they can trust that some operation will be performed.
the privacy and liability barriers in the mid-90s resulted in some significant retrenching to relying-party-only certificates. however, it is trivial to demonstrate that relying-party-only certificates are totally redundant and superfluous in online transactions.
the problems with the early 90s, x.509 certificates overloaded with identity information went beyond the significant privacy and liability issues ... but also frequently that identification was not particularly of interest to the subject business processes; aka they don't really care who you were ... they wanted to know stuff like
1) you have a financial account 2) there is currently, at this instant, enuf funds in the financial account 3) the funds will, in fact, be transferred.
and #3 ... most importantly of all.
with regard to lots of stuff related to identity ... is if all else fails ... they know who to send the authorities after. from a business stand-point you are much better having an infrastructure that makes sure that you never have to get to the point of needing to use identity information. if you are at the point of actually having to make use of identity information, it can imply that the rest of the infrastructure has failed and things are about to get really costly.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sat, 07 Aug 2004 14:23:23 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
... there has been some amount of reputation management (aka trust) involving relationships involving entities that are otherwise strangers. one such example is the ebay online system .... here again there aren't certificates involved ... and it isn't particularly identity oriented (other than as a matter of last recourse if everything else goes wrong).
it basically is prediction based on history ... w/o actually being able to relate any identity information to some personal context ... the trust basis is reputation based ... has the entity consistently performed in some manner ... regardless of what their identity might be. this is online, real-time information ... and the information isn't armored in a digitally signed, stale, static, redundant and superfluous certificate.
in the ebay reputational case, the type of information is aggregated, real-time, online and specifically statistics based on past transactions ... something that presumably is felt to have some direct correlation and meaning for future transactions ... and therefore provide some direct level of trust and comfort ... and something that would be difficult to accomplish in a stale, static, redundant and superfluous certificate-based paradigm.
misc. past posts related to reputational trust
https://www.garlic.com/~lynn/aepay10.htm#53 First International Conference On Trust Management
https://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
https://www.garlic.com/~lynn/aadsm14.htm#45 Keyservers and Spam
https://www.garlic.com/~lynn/2003f.html#45 Timesharing TOPS-10 vs. VAX/VMS "task based timesharing"
https://www.garlic.com/~lynn/2003l.html#43 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#46 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#53 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/aadsm17.htm#58 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm18.htm#14 In Search of Eve - the upper boundary on Mallory
https://www.garlic.com/~lynn/aadsm18.htm#15 In Search of Eve - the upper boundary on Mallory
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Hard disk architecture: are outer cylinders still faster than inner cylinders? Newsgroups: comp.arch Date: Sat, 07 Aug 2004 14:13:00 -0600"Bill Todd" writes:
i was contacted 6-7 years ago by somebody from a major dbms vendor (but it wasn't mohan) ... after having posted something about inter-cache record movement (related to the ha/cmp dlm work).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sat, 07 Aug 2004 15:33:06 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
in fact, as repeatedly described, certification authorities tend to be nothing more than certifying some piece of information that originates from a real trust agency ... where the certification authorities aren't actually any trust agency at all ... they are just certifying trust information.
in several examples ... where the certification agency is directly contacting some authoritative or trust agency to certify some piece of information ... i described scenarios where relying parties can
1) directly contact the authoritative/trust agency directly themselves ....
2) totally eliminating the need for intermediary, certification authorities to certify information for relying parties to use 3rd hand ... when the relying party can directly contact the authoritative/trust agencies directly
3) with relying parties directly contacting authoritative/trust agencies directly ... eliminating the need for intermediary certification authorities to contact and certify information from authoritative/trust agencies on the behalf of relying parties (because the relying parties are contacting the authoritative/trust agencies directly) ... then the need for certificates containing certified information from authoritative/trust agencies is also eliminated and therefore the stale, static certificates become redundant and superfluous in such situations
note that certificates have typically not been equivalent to authoritative/trust agencies ... and shouldn't be confused with being equivalent to authoritative/trust agencies.
stale, static certificate-based information is useful for relying parties when they are operating in an offline environment and are unable to directly contact and obtain the information directly for themselves.
stale, static certificate-base information becomes redundant and superfluous when relying parties can directly contact authoritative/trust agencies on their own behalf ... eliminating the requirement for intermediary, certification authorities to do it for them.
the issue is as the world moves to ubiquitous, online environment, the number of situations where a relying party has to resort to stale, static, redundant and superfluous certificate-based information ... because the relying party is unable to directly contact the authoritative/trust agency ... is becoming vanishingly small.
certificates are not equivalent to authoritative/trust agencies .... certificates typically contain some small, selected subset of information that originated sometime in the past ... and hopefully represents some value to a relying party that is incapable of otherwise obtaining the information in real time.
besides the issue of certificates being targeted as a solution for the rapidly diminishing offline world ... the other value-proposition problem that certification authorities have faced ... is attempting to identify which stale, static, subset information could possibly be useful for some relying party at some point in the future.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sat, 07 Aug 2004 16:45:30 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
the issue is that for a certificate in a PKI/CA infrastructure is that the certification authority is certifying the combination of a certificate containing both a public key and some other information. the purpose of this certificate is that the public key owner can present the certificate to a relying party at some point in the future ... and the relying party can make decisions and/or execute operations purely based on the contents of the certificate ... w/o needing to directly contact the certifying, authoritative, and/or trust agency.
so you are seriously confusing any possible act of certification using any kind of technology ... with the specific subject of a digitally signed public key certificate which contains at least a public key and some other information.
the public key owner goes to a certification authority and presents their public key ... and some information needing certifying; the certification authority certifies that information (possibly by directly contacting the authoritative and/or trust agency responsible for that information) and creates a digitally signed certificate containing the public key owners public key and the certified information ... and returns that digitally signed public key certificate to the public key owner.
at some future time, the public key owner
1) creates some transaction, digitally signs the transaction,
2) appends the digital signature to the transaction and
3) appends the previously created digital certificate (containing some certified information and public key) and
4) sends the tuple (transaction, digital signature, and digital certificate) off to some relying party
5) the relying party receives the tuple and
6) the relying party uses the public key from the appended digital certificate to verify the appended digital signature
7) the relying party then is able to execute the indicated transaction or operation based on the appended information bound in the digitally signed certificate
8) w/o having to contact either the certifying authority and/or the authoritative/trust agency responsible for the information.
you can have things that are certified with the addition of digital signature ... but they are not considered a standard, normal public key certificate since they don't contain a public key bound to some certified information .... they just contain some digitally signed certified information.
so the question is are you confusing the certifying of any information ... attested to by the application of a digital signature ... with a public key certificate which is defined as containing the certification of a public key combined with some other information?
just because some information is digitally signed ... possibly coming directly from some authoritative and/or trust organization ... doesn't make it a public key certificate ... which is what the traditional CA/PKI, certificate, etc genre of terms normally refer to.
the CA/PKI, certificate, etc, genre of terms when referring to certificates are talking specifically about public key certificates that contain certified public keys and other information.
there is actual distinction between generally certified information and specifically certified public key certificates ... which include a public key and originally had the design point of address a problem where a relying party had to "rely" on the information provided by the person presenting the transaction ... w/o being able to directly contact the certifying, authoritative, and/or trust agency responsible for the information.
specifically, the certificate was designed to be used in lieu of the relying party being able to directly contact the certifying, authoritative, and/or trust agency responsible for the information.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sat, 07 Aug 2004 16:50:17 -0600on the other hand ... maybe i'm confused ... i have been under the impression that we are talking about normal, conventional Digital Certificates (as per the subject line and the initial postings) ... which in the traditional digital signature, public key, certification authority environment refers specifically to something that contains a public key plus some additional information ... which is combined together and digitally signed.
has somehow this thread been taken over and drifted into a totally different subject ... where the subject is no longer Digital Certificates in the traditional CA/PKI context .... but some other completely different subject ... which potentially has some slight semantic relationship ... because the completely different subject somehow also involves the word and concept of certify??
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sat, 07 Aug 2004 17:00:30 -0600... on the off-hand chance that somewhere along the way you have decided to talk about something else than Digital Certificates used in the traditional CA/PKI context .... possibly we can go back and start again with reference definitions .... these are from my merged security taxonomy and glossary which can be found at:
i was under the impression that the original subject matter
specifically was referring to Digital Certificates within the context
of public key digital certificates ... or public key certificates as
defined in the attached.
certificate authority (CA)
(D) ISDs SHOULD NOT use this term because it looks like sloppy use
of 'certification authority', which is the term standardized by
X.509. [RFC2828] The entity or organization that attests using a
digital certificate that a particular electronic message comes
from a specific individual or system. [FFIEC] (see certification
authority) (see also certificate, certification, test, public-key
infrastructure)
certificate
(I) General English usage: A document that attests to the truth of
something or the ownership of something. (C) Security usage: See:
capability, digital certificate. (C) PKI usage: See: attribute
certificate, public-key certificate. [RFC2828] A declaration by an
independent authority operating in accordance with ISO Guide 58,
Calibration and testing laboratory accreditation systems - General
requirements for operation and recognition, confirming that an
evaluation pass statement is valid. [SC27] A digitally signed data
structure defined in the X.509 standard that binds the identity of a
certificate holder (or subject) to a public key. [SRV] An electronic
identifier from a certificate authority that includes the CA signature
made with its private key. The authenticity of the signature is
validated by other users who trust the CA's public key. [misc] An
entity's data rendered unforgeable with the private or secret key of a
certification authority. [SC27] An entity's data rendered unforgeable
with the private or secret key of a certification authority. [ISO/IEC
WD 13888-1 (11/2001)] A declaration by an independent authority
operating in accordance with ISO Guide 58, Calibration and testing
laboratory accreditation systems - General requirements for operation
and recognition, confirming that an evaluation pass statement is
valid. [SC27] Certificates are data which is used to verify digital
signatures. A certificate is only as trustworthy as the agency which
issued it. A certificate is used to verify a particular signed item,
such as an Email message or a web page. The digital signature, the
item and the certificate are all processed by a mathematical
program. It is possible to say, if the signature is valid, that
'According to the agency which issued the certificate, the signer was
(some name)'. [RFC2504] Record holding security information about an
AIS user and vouches to the truth and accuracy of the information it
contains. [IATF][NSTISSC]
certification authority (CA)
I) An entity that issues digital certificates (especially X.509
certificates) and vouches for the binding between the data items in a
certificate. (O) 'An authority trusted by one or more users to create
and assign certificates. Optionally, the certification authority may
create the user's keys.' (C) Certificate users depend on the validity
of information provided by a certificate. Thus, a CA should be someone
that certificate users trust, and usually holds an official position
created and granted power by a government, a corporation, or some
other organization. A CA is responsible for managing the life cycle of
certificates and, depending on the type of certificate and the CPS
that applies, may be responsible for the life cycle of key pairs
associated with the certificates. [RFC2828] A centre trusted to create
and assign public key certificates. Optionally, the certification
authority may create and assign keys to the entities. [SC27] A trusted
agent that issues digital certificates to principals. Certification
authorities may themselves have a certificate that is issued to them
by other certification authorities. The highest certification
authority is called the root CA. [IATF][misc] A trusted entity that
issues certificates to end entities and other CAs. CAs issue CRLs
periodically, and post certificates and CRLs to a repository. [SRV]
Commercial-off-the-shelf (COTS) workstation with workstation (CAW) a
trusted operating system and special purpose application software that
is used to issue certificates. [NSTISSC] Third level of the Public Key
Infrastructure (PKI) Certification Management Authority responsible
for issuing and revoking user certificates, and exacting compliance to
the PKI policy as defined by the parent Policy Creation Authority
(PCA). [NSTISSC]
public-key certificate
(I) A digital certificate that binds a system entity's identity to
public key value, and possibly to additional data items; a
digitally-signed data structure that attests to the ownership of a
public key. (C) The digital signature on a public-key certificate is
unforgeable. Thus, the certificate can be published, such as by
posting it in a directory, without the directory having to protect the
certificate's data integrity. (O) 'The public key of a user, together
with some other information, rendered unforgeable by encipherment with
the private key of the certification authority which issued it.'
[RFC2828] Contains the name of a user, the public key component of the
user, and the name of the issuer who vouches that the public key
component is bound to the named user. [NSTISSC] The public key
information of an entity signed by the certification authority and
thereby rendered unforgeable. [SC27] The public key information of an
entity signed by the certification authority and thereby rendered
unforgeable. NOTE - In the context of this part of ISO/IEC 9796 the
public key information contains the information about the verification
key and the domain parameters. [SC27] The public key information of an
entity signed by the certification authority and thereby rendered
unforgeable. [ISO/IEC 9798-1: 1997, ISO/IEC 11770-1: 1996, ISO/IEC
11770-3: 1999, ISO/IEC WD 13888-1 (11/2001)] The public key
information of an entity signed by the certification authority and
thereby rendered unforgeable. NOTE - In the context of this part of
ISO/IEC 9796 the public key information contains the information about
the verification key and the domain parameters. [SC27]
public-key infrastructure (PKI)
(I) A system of CAs (and, optionally, RAs and other supporting servers
and agents) that perform some set of certificate management, archive
management, key management, and token management functions for a
community of users in an application of asymmetric cryptography. (O)
PKIX usage: The set of hardware, software, people, policies, and
procedures needed to create, manage, store, distribute, and revoke
digital certificates based on asymmetric cryptography. (C) The core
PKI functions are (a) to register users and issue their public-key
certificates, (b) to revoke certificates when required, and (c) to
archive data needed to validate certificates at a much later time. Key
pairs for data confidentiality may be generated (and perhaps escrowed)
by CAs or RAs, but requiring a PKI client to generate its own digital
signature key pair helps maintain system integrity of the
cryptographic system, because then only the client ever possesses the
private key it uses. Also, an authority may be established to approve
or coordinate CPSs, which are security policies under which components
of a PKI operate. (C) A number of other servers and agents may support
the core PKI, and PKI clients may obtain services from them. The full
range of such services is not yet fully understood and is evolving,
but supporting roles may include archive agent, certified delivery
agent, confirmation agent, digital notary, directory, key escrow
agent, key generation agent, naming agent who ensures that issuers and
subjects have unique identifiers within the PKI, repository,
ticket-granting agent, and time stamp agent. [RFC2828] An architecture
that is used to bind public keys to entities, enable other entities to
verify public key bindings, revoke such bindings, and provide other
services critical to managing public keys. [SRV] Framework established
to issue, maintain, and revoke public key certificates accommodating a
variety of security technologies, including the use of
software. [CIAO] Public and private keys, digital certificates,
certification authorities, certificate revocation lists, and the
standards that govern the use and validity of these elements make up
an infrastructure where principals can engage in private and
non-repudiable transactions. This combination is called the Public Key
Infrastructure. [IATF][misc] The system consisting of TTPs, together
with the services they make available to support the application
(including generation and validation) of digital signatures, and of
the persons or technical components, who use these services. NOTE -
Sometimes the persons and the technical components participating in a
PKI by using the services of TTPs, but not being TTPs themselves, are
referred as end entities. An example of a technical equipment used by
an end entity is a smart card which may be used as a storage and or
processing device. [SC27] The use of public key cryptography in which
each customer has a key pair (i.e., a unique electronic value called a
public key and a mathematically-related private key). The private key
is used to encrypt (sign) a message that can only be decrypted by the
corresponding public key or to decrypt a message previously encrypted
with the public key. The public key is used to decrypt a message
previously encrypted (signed) using an individual's private key or to
encrypt a message so that it can only be decrypted (read) using the
intended recipient's private key. [FFIEC]
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sat, 07 Aug 2004 17:38:59 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
within that context ... you are changing the topic thread to a theoretical discussion of any type of theoretical agency that might possibly be in a responsible or trust position and potentially responsible for the integrity or validity of any kind of arbitrary information.
in this theoretical context ... apparently completely divorced from and possibly having absolutely nothing to do with public key technology, what are the possible meanings of trust and certifying?
well, resorting again to the merged security taxonomy and glossary
at
https://www.garlic.com/~lynn/index.html#glosnote
I find the possible following definitions that might possible be of some use ... unfortunately there are generic definitions as well as definitions specifically within the context of a Public Key, Digital Certificate, Certification Authority environment.
note in the following more general definitions ... there are some that are still PKI specific ... and potentially can be considered ambiguous.
for instance in the attached trust definition .... is the "certificate user" referring to the
a) public key owner .... which has a direct trust relationship with a certification authority ... since the public key owner directly interacted with the certification authority in obtaining the certificate
b) the relying party ... which is the entity that is relying on the information contained in a public key certificate ... and in many of the TTP certification authority scenarios involve the relying party having absolutely no relationship at all with the CA ... and therefore it is difficult to demonstrate a relying party trusting a CA ... a situation where there is likely to be no direct relationship.
but i apparently digress to the original subject that is PKI specific
... when you are attempting to address the trust and certify topic
totally divorced from any PKI related context.
certification
(1) Comprehensive evaluation of the technical and nontechnical
security features of an AIS and other safeguards, made in support of
the approval/accreditation process, to establish the extent to which a
particular design and implementation meet a set of specified security
requirements. Note: There remain two other definitions in active
common usage that differ according to circumstances. (2) The issue of
a formal statement confirming the results of an evaluation, and that
the evaluation criteria used were correctly applied. Synonym for IT
security certification. [AJP] (I) Information system usage: Technical
evaluation (usually made in support of an accreditation action) of an
information system's security features and other safeguards to
establish the extent to which the system's design and implementation
meet specified security requirements. (I) Digital certificate usage:
The act or process of vouching for the truth and accuracy of the
binding between data items in a certificate. (I) Public key usage: The
act or process of vouching for the ownership of a public key by
issuing a public-key certificate that binds the key to the name of the
entity that possesses the matching private key. In addition to binding
a key to a name, a public-key certificate may bind those items to
other restrictive or explanatory data items. (O) SET usage: 'The
process of ascertaining that a set of requirements or criteria has
been fulfilled and attesting to that fact to others, usually with some
written instrument. A system that has been inspected and evaluated as
fully compliant with the SET protocol by duly authorized parties and
process would be said to have been certified compliant.' [RFC2828]
Comprehensive evaluation of the technical and nontechnical security
features of an AIS and other safeguards, made in support of the
accreditation process, to establish the extent to which a particular
design and implementation meets a set of specified security
requirements. [FCv1] Procedure by which a third party gives written
assurance that a deliverable (product, system or service) conforms to
specified requirements. [SC27] The administrative act of approving a
computer system for use in a particular application. [SRV] The
comprehensive evaluation of the technical and non-technical security
controls of an IT system to support the accreditation process that
establishes the extent to which a particular design and implementation
meets a set of specified security requirements. [800-37] The
comprehensive evaluation of the technical and nontechnical security
features of an AIS and other safeguards, made in support of the
accreditation process, that establishes the extent to which a
particular design and implementation meet a specified set of security
requirements. [NCSC/TG004][OVT] The issue of a formal statement
confirming the results of an evaluation, and that the evaluation
criteria used were correctly applied. [ITSEC] The technical evaluation
of a system's security features, made as part of and in support of the
approval/accreditation process, that establishes the extent to which a
particular system's design and implementation meet a set of specified
security requirements. [TCSEC][TNI]
certify (unfortunately is specific to the PKI environment):
(I) Issue a digital certificate and thus vouch for the truth,
accuracy, and binding between data items in the certificate, such as
the identity of the certificate's subject and the ownership of a
public key. (C) To 'certify a public key' means to issue a public-key
certificate that vouches for the binding between the certificate's
subject and the key. (I) The act by which a CA employs measures to
verify the truth, accuracy, and binding between data items in a
digital certificate. (C) A description of the measures used for
verification should be included in the CA's CPS. [RFC2828]
trust
(I) Information system usage: The extent to which someone who relies
on a system can have confidence that the system meets its
specifications, i.e., that the system does what it claims to do and
does not perform unwanted functions. (C) 'trusted vs. trustworthy': In
discussing a system or system process or object, this Glossary (and
industry usage) prefers the term 'trusted' to describe a system that
operates as expected, according to design and policy. When the trust
can also be guaranteed in some convincing way, such as through formal
analysis or code review, the system is termed 'trustworthy'; this
differs from the ABA Guidelines definition. (I) PKI usage: A
relationship between a certificate user and a CA in which the user
acts according to the assumption that the CA creates only valid
digital certificates. (O) 'Generally, an entity can be said to 'trust'
a second entity when it (the first entity) makes the assumption that
the second entity will behave exactly as the first entity
expects. This trust may apply only for some specific function. The key
role of trust in [X.509] is to describe the relationship between an
entity and a authority; an entity shall be certain that it can trust
the certification authority to create only valid and reliable
certificates.' [RFC2828]
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sat, 07 Aug 2004 17:47:15 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
b) and the message originated from the entity related to the public key that is used for verifying the digital signature.
so I assert that the application of a digital signature can be totally unrelated to certifying anything (commonly understood in the literature or not)
that the certifying something can be totally unrelated to the application of a digital signature.
furthermore certifying something and the application of a digital signature can be totally unrelated to the subject of public key digital certificates (as commonly understood in the literature).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sat, 07 Aug 2004 20:32:08 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
as defined in the function of the certification authorities, they are certifying the combination of the public key contained in the public key certificate and the information content that they "bind" to that public key.
at several points you have since mentioned simple certifying of any information ... possibly with or without the application of digital signature to that certifying operation ... including the possible instances where a relying party has directly contacted a trust and/or authoritative agency ... and gotten back some possibly digitally signed certified information.
at several points you seemed to have grossly confused my assertions that public key certificates can be redundant and superfluous in an online world where the relying parties can directly contact the authoritative agency ... as implying that any and all certifying of any information by any and all authoritative agencies (whether such certified information was digitally signed or not) could be considered redundant and superfluous.
however, your repeated statements of confusion regarding my statements about certificates being redundant and superfluous ... cannot be considered to apply to anything other than public key certificates given the context and commonly accepted definition of Digital Certificates.
any impression regarding my statements regarding redundant and superfluous nature of public key digital certificates being confused with any and all forms of certifying (as you have since made several references to) ... could only be construed if the context has been totally changed ... from specifically the context of public key digital certificates to the context of any arbitrary certifying operation.
1) I never claimed that the PK mechanism doesn't work.
2) I've repeatedly claimed that in the cases where the relying party can contact the authoritative agency directly ... and obtain timely and higher quality (possibly certified) information ... that in such situations stale, static public key certificates are redundant and superfluous
3) i've repeatedly claimed that the specific design point for stale, static public key certificates ... are for situations where the relying party has no other recourse (i.e. isn't able to directly contact the authoritative and/or trust agency) and therefore must rely on stale, static certificates.
your repeated statements about confusion regarding my assertions as to public key certificates being redundant and superfluous in situations where the relying party has direct, real-time access to the information (in the case where the relying party and the authoritative agency are the same) or direct access to the authoritative agency (where the relying party and the authoritative agency are different)
... and appears to be totally discounting what it means for the relying party to have direct and/or online access to the information or the authoritative agency ... as well as equating the phrase "public key certificates being redundant and superfluous " as being equivalent to all forms of certifying being redundant and superfluous.
1) the assertion is that public key certificates are redundant and superfluous when the relying party has direct, real-time access ... as in direct real-time access to the actual information ... that the relying party can trust more than they can trust stale, static public key certificates.
2) the assertion doesn't say that public key certificates are equivalent to all forms of certified information
3) the assertion specifically says that when the relying party has access to real-time, direct, online information ... then the stale, static public key certificates manufactured at some point in the past are redundant and superfluous.
4) the assertion doesn't say that w/o public key certificates that the relying party has no access to trusted information
5) the assertion does say that if the relying has no access to any other form of trusted information then the stale, static public key certificates are better than nothing
the assertion has always been that with access to real-time, online information, then stale, static public key certificates are redundant and superfluous.
the assertion has never been that stale, static public key certificates is equivalent to all forms of certified information and/or there has never been any assertion that all forms of certified information are redundant and superfluous.
the assertion is that with access to timely, online, direct, etc information ... that the form of the information that was manufactured into a stale, static public key certificate at some point in the past is redundant and superfluous.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sun, 08 Aug 2004 10:01:17 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
so a better example is one that i gave about merchants on the internet ... in which i repeated the assertion that certificates were redundant and superfluous and which you replied that you were confused.
in order for the merchant to do credit card transactions they have to have been authorized by their merchant financial institution and typically received some software & other stuff from that financial institution.
this software comes in somewhat more reliable way than the manner that most people obtain their browser. current browser technologies contain a table of public keys that users take as trusted. in the case of the merchant ... it could be non-internet, point-of-sale, device with special software loaded into the point-of-sale device and initialized with stuff about phone number to call, merchant-id, etc. In the case of the internet e-commerce, it is something that basically emulates a point-of-sale device.
so merchant gets their merchant financial transaction processing software with significantly higher trust level than most people get their browsers ... and it can contain a public key of the merchant financial institution ... and therefore they trust the software and if the software happens to contain the public key of the merchant financial institution ... for communication over the internet rather than communication over dial-up phone line ... they trust it.
that is effectively and exactly modern e-commerce. as stated before,
my wife and i were actually involved in the original creation of
this thing that people are now calling e-commerce:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
there was this thing that needed to be created called a (merchant) commerce server ... which had two versions ... one that used private line to the merchant financial institution and one that used internet to something called a (internet) payment gateway (which in turn had a private line to the merchant financial institution). both versions emulated a point-of-sale terminal ... and the version that used the internet to talk to a payment gateway ... actually emulated the private line protocol over an mutually authenticated SSL session (i mandated that the SSL session to the payment gateway be mutually authenticated ... this was before there was mutual authentication specification in a SSL standard). This was not dependent on public key exchange via certificates ... in part because the key exchange issue was a minor trivial portion of the business process required to establish the business relationship between the merchant and the merchant financial institution. There is a couple order of magnitude other things that have to go on ... of which key exchange is a minor nit.
this is the modern e-commerce.
now what modern e-commerce has been trying to do is leverage that there are extremely strong trust relationships between entities and financial institutions ... and the financial institutions are willing to take risks on behalf of the entities that they have relationships with (at potentially a profitable discount).
so, modern e-commerce is trying to allow two complete strangers who have absolutely no basis to trust each other (regardless of whether they are absolutely, 100% sure that they have each others valid public key ... regardless of the mechanism) ... to comfortably perform transactions.
basically ... as i've oft repeated in detailed notes ... which you have repeatedly replied comments about confusion regarding what is redundant and superfluous ... the relying parties in modern e-commerce typically could care less about who you are ... they are really interested in will they get paid. in possibly 99.99999 percent of todays, internet, modern e-commerce, the (merchant) relying party gets a reply back from the consumer's financial institution that the merchant will get paid. that comes back via either some sort of dedicated phone line ... or a mutually authenticated SSL session that emulates a dedicated phone line.
99.9999 percent of modern, internet-based e-commerce isn't based on the merchant knowing/trusting the consumer or the consumer knowing/trusting the merchant. the consumers trust the financial infrastructure that allows them to repudiate any transaction. the merchants trust the financial infrastructure to give them some level of comfort regarding whether they get paid or not.
having absolutely perfect knowledge about some strangers public key (regardless of the method that public key is obtained) is almost totally extraneous to the fundamental trust operations on which modern e-commerce is based. The fundamental trust operations that allow modern e-commerce are
1) the inter financial institution trust 2) the trust between the consumer and the consumer financial institution 3) the trust between the merchant and the merchant financial institution 4) the risk that financial institutions are willing to take on behalf of entities that they have relationships with
that is 99.9999 percent of the trust issues that account for the original
e-commerce model that my wife and i worked on
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
so there is a new merging e-commerce paradigm typified by ebay model. the issue here is the entity performing the merchant function no longer has a merchant financial institution that is taking the risk on behalf of the merchant entity. both the consumer and the consumer's financial institution have trust issues with the merchant entity, since there typically isn't a merchant financial institution taking risk & liability on behalf of the merchant (which is where being able to do credit card transaction breaks down). so ebay has to come up with other mechanisms for merchant entities feeling comfort that they will get paid ... as well as other mechanisms that give consumers comfort in the merchant entity they are dealing with. these new trust mechanisms are so far devoid of any public key content.
the ebay model is provided substitute comfort (to the credit card system backed by risk taking on behalf of their affiliated entities by the respective financial institutions) to the merchant entity that they will get paid. this is typically some sort of funds escrow. the merchant entity doesn't have to know or care who the client is ... they just have to trust ebay and their word that the funds are in escrow. for two complete strangers ... absolutely knowing the other entity's identity ... down to possibly their DNA ... doesn't create trust. So ebay has developed a reputation model for creating merchant entity trust ... which is data on a strangers past performance.
trust is typically about taking risk and mitigating risk and how much risk ... absolutely knowing a strangers DNA identity still says little about the risk. ebay mitigates the perceived risk on the part of sellers by providing funds escrow. ebay mitigates the perceived risk on the part of buyers by providing sellers past reputational transaction history.
that is modern e-commerce. the trust & risk issue isn't whether two absolute strangers can absolutely determine each others identity ... it is about how large is the perceived risk and what risk mitigation business processes are in effect.
second order detail about perceived risk and trust ... are the variety of threat models. risk mitigation is about countermeasures for the perceived threat models.
so modern e-commerce isn't about two strangers being able know who each other are ... it is about countermeasures to perceived threats ... i.e. risk mitigation. risk mitigation can be financial institutions taking financial liability on behalf of other entities (the credit card model).
possibly, on the off-change of confusing you again. I'll describe the X9.59 plus secure DNS model ... which requires no public key exchange between the consumer and the merchant ... and also doesn't require any appending digital certificates to any transactions, and doesn't require any digital certificates at all.
You get some DNS software that you trust ... that trusted DNS software contains table of public keys for trusted DNS servers. This is analogous to the table of root CAs that you might get in a browsers. The difference is that the browser tabls of root CAs public keys are used to validate certificates and the DNS table of trusted public keys is used to directly validate real-time communication. In some sense this is certifying ... but not certifying certificates ... and I make the assertion that certificates are redundant and superfluous w/o making the (possibly confusing) assertion that certifying is redundant and superfluous.
As suggested by the certification authority industry, people now registered (naked) public keys at the same time they register a domain name with the domain name infrastructure.
You enter a URL into a browser. The browser asks the DNS software to map the domain name to an IP-address ... and also retrieve the corresponding public key in addition to the IP-address. This can be digitally signed and authenticated with the public keys that comes with the DNS software. No certificates are required they are redundant and superfluous. The public key operation is a countermeasure for the treat model is somebody impersonating the domain name infrastructure.
The browser gets back both the IP-address and the public key. It uses the IP-address to contact the server and public key to validate that the correct server is being talked to. This has nothing at all to do with you trusting the server ... you presumably made some trust decision about the server when you entered the URL. The ip-address is for a server that you presumably have already made some trust decision about. The domain name public key is a countermeasure for the treat model where somebody redirects the ip-packets to a different server. This is the same function performed by SSL domain name server certificates, it is countermeasure to the packets going to the wrong server. It has nothing at all to do with any risk/threat decision about the correct server ... it has to do with the threat model regarding the packets going to the wrong server.
You perform some number of interactions with the server and decide to pay something. you create a x9.59 payment transaction that you digitally sign and send to the server. as previously mentioned this transaction doesn't require an encrypted SSL session and/or the requirement to hide the account number. The existing use of encrypted SSL session is countermeasure to the treat model that somebody learns the account number and is able to use that knowledge to perform a fraudulent transaction. Since knowing an X9.59 account number is not sufficient to being to perform a fraudulent transaction ... it is no longer necessary to hide the account. The fundamental threat model is performing fraudulent transactions. In the current credit card case, just knowing the account number enables fraudulent transactions ... so the countermeasure is preventing criminals from learning the account number (this can be difficult since at least 77% of fraud is insiders related and insiders have to know the account number). In the x9.59 case, fraudulent transactions are prevented by requiring all transactions with that account number be digitally signed.
The x9.59 transaction is sent off with a digital signature but no digital certificate. the certificate is redundant and superfluous as well as potentially creating a one hundred times payload bloat.
The merchant receives the transaction and forwards it to their merchant financial institution ... either via internet or dedicated line. The merchant doesn't really need to authenticate the transaction, however the merchant may examine the transaction to verify that it has specified the correct amount. The threat model is that the consumer has specified the wrong amount. The countermeasure is that the merchant doesn't bother to forward the transaction to the merchant's financial infrastructure.
Now, you possibly are confused about the merchant interface to the financial infrastructure. It turns out that in both the internet case as well as the non-internet case, the majority of transactions are performed by very few merchants ... something like 60% of transactions are maybe 20 top merchants and possibly 90% of transactions are combination of top 200-400 actual merchants plus some number of transaction aggregators.
you may have never noticed ... or have been confused when you see a totally different domain name when you click on the "pay" button. however, there are large number of e-commerce web sites that hand off the "pay" button to a payment transaction aggregator ... that is unrelated to the e-commerce site (you have been visiting) and which provides the payment service for a large number of different merchants. You likely have not been using SSL when you were performing the actual shopping operations ... so you have no SSL or certified assurance that you are actually talking to the merchant web site you think you are talking to. Then when you click on the pay button ... you have not actually entered the URL that you are being transferred to. Furthermore, in the case of payment aggregator ... it is in fact redirecting you to a completely different web server with no knowledge on your part (in theory a threat model that SSL was designed to prevent ... but in fact is now part of large number of correctly operating e-commerce transactions ... redirecting you to somebody else w/o your knowledge).
It turns out that for the large merchants (that aren't using an external payment aggregator) they may still internally aggregate all their internal payment (whether they are internet or not) and send them over a dedicated line to their financial processor. This is exactly the majority of modern e-commerce ... possibly 90% or more.
The issue for the merchant & payment aggregators is that the internet has tended to have some number of vagaries and service. The threat model is all sorts of service vagaries and interruptions. The countermeasure is a dedicated line (regardless of whether or not it is running tcp/ip protocol). The issue for operations doing large number of transactions is that incremental cost of dedicated line (vis-a-vis an open line to the anarchy of the real internet) is less than the possible loss of business due to various vagaries of internet service. The high volume dedicated lines may also have active monitoring by the network operations center at the merchant financial center. The NOC will possibly be sending query requests every second down actively monitored lines ... and include provisions for fall-over and/or redundant dedicated lines into geographically dispersed centers.
this is possibly 90 percent of actual e-commerce on the internet ... in fact for some number of the large merchants that also have brick&mortar operations ... the same dedicated line(s) service both point-of-sale as well as internet-originated transactions. this is more than the spirit of modern e-commerce ... this is actual majority of all modern e-commerce.
so back to the x9.59 flow. the merchant decides that the transaction value is correct and for the majority of the modern e-commerce transactions in the world ... send them over a dedicated line. For some number of other modern e-commerce operations they will send the transactions thru a long-lived SSL encrypted session that emulates a dedicated line to a payment gateway. The SSL encrypted session has been set-up with mutual authentication and isn't dependent on certificates for public key exchange ... because it has been authorized as part of a long term relationship between the merchant and the merchant financial institution (or possibly a payment aggregator on behalf of the merchant). The other flow is that there are some number of internet merchants that have a phone line into their PC that is doing a real-live dial-up point-of-sale emulation with their internet payments. This isn't a large percentage in turns of transactions ... but has a significant number of the small operations.
so an interested question is whether the spirit of modern e-commerce is assumed to be represented by 90-95 percent of actual e-commerce transactions ... or if somebody has a definition that the spirit of modern e-commerce is totally unrelated to actual e-commerce?
in any case, the x9.59 transaction forwarded by the merchant disappears into the financial infrastructure and eventually arrives at the consumers financial institution. This is the nominal 60-80 byte transaction, a 42-byte digital signature and little bit of other gorp ... w/o a digital certificate that would represent a possible payload bloat of a factor of 100 times besides being redundant and superfluous. The consumers financial institution pulls up the consumers account record and is able to verify the digital signature with the public key on file with the consumer's financial institution.
for those steeped in the depths of certification authority operation and/or have read the previous posted definition, a common feature of certification authority happens to be referred to as RA or registration authority ... an entity that registers the key owners public key and stuffs it away someplace. If steeped in CA lore ... the consumer's financial institution has performed the RA function at the same time they set up the business relationship for the consumers account.
Similarly, the certification authority industry suggestion that public keys are registered with the domain name infrastructure when domain names are registered ... is having the domain name infrastructure execute an RA operation. In neither the consumer financial institutional nor the domain name infrastructure execution of the RA operation ... is it necessary for the institution to return a (digital, public key) certificate to the key owner.
In the x9.59 scenario, not returning any sort of certificate to the key owner it could be considered a safety measure .... if they had such a certificate, they might append the redundant and superfluous certificate to an x9.59 transaction ... causing a transaction payload bloat of possibly a factor of 100 times.
In any case, the consumer financial institution validates the digital signature on the x9.59 transaction with the public key on file in the consumer's account record ... does the other gorp related to deciding to approve the transaction and finally injects a response into the financial network. The response wanders around the financial network and eventually arrives at the merchant financial institution (or an acquiring processor acting as the agent of the merchant financial institution). At this time, the merchant financial institution transmits the consumers financial institution response back to the merchant ... using whatever dedicated line, long-lived ssl connection (emulating a dedicate line), or dialed phone connection.
The merchant gets the response from their merchant financial infrastructure ... which is either approved or denied.
the merchant doesn't know the consumer ... the consumer doesn't (really need to) know the merchant.
the actual (whether or not it is the spirit depending on your view)
modern e-commerce is dependent on long term established trust
relationships ... and the knowledge of total strangers dealing with
each other that the risk is mitigated by the respective financial
institutions (not by total strangers knowing the names of who they are
dealing with).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sun, 08 Aug 2004 14:44:36 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
so rather than talking about some theoretical, hypothetical conjecture about how e-commerce operates ... we can talk about how it actually operates.
several of your replies expressed confusion over my assertion that certificates were redundant and superfluous when the relying party has access to the real information.
I eventually took that to mean that either
1) you lacked any understanding that there is semantic meaning difference between digital certificates (as used in the original context of the original posting) and the semantic meaning of trust
or
2) you explicitly chose to change the context of the discussion so that there was, in fact, no semantic meaning difference between certificates and trust
now, i've described several scenarios that represent 99.999 percent of the actual e-commerce operation today. the basic underpinnings for trust has nothing to do with public key and/or digital signature operations. the basis of (possibly 99.999 percent of) todays e-commerce trust between two arbitrary entities was leveraged off payment transaction support for MOTO ... which also involved non-face-to-face operations between strangers ... but pre-ecommerce.
the addition of public key operations to these environments isn't to improve the trust between the strangers in the transaction ... it is to improve the authentication in non-face-to-face environment.
the primary parties involved in 99.9999 percent of todays trust operations are the financial institutions. they are the basis of trust. the basis of that trust is the stranger/participants trust in the operation of the financial infrastructure.
the threat model to ecommerce isn't that two strangers are interacting ... it is whether the financial institutions can be sure that they are taking the risk and liability for entities for which they have long standing relationship.
Now there is a slight commonality that i've described between certification authority based operation and institutional long term relationship authentication that possibly involves public keys.
There is a process that is described in the previously posted definitions related to public keys ... called RA or registration authority. It is the process of registering an entity's public key and making sure that specific public key is related to some specific entity.
In the certification authority scenario, they return a certificate to the public key owner ... so that the public key owner can present the certificate/credential to random other (relying) parties as representation/standin for the real information ... in hypothetically conjectured scenarios where the relying party might not have direct access to the authoritative agency for the actual/real information (originally hypothesized to address a perceived problem in a theoretical environment where the relying party would be offline and not have any direct access to the responsible and/or authoritative agency responsible for the information).
In all of the 99.9999 percent of the existing ecommerce transactions where the basis of trust has been scaffolded off the pre-existing MOTO trust environment ... there is a requirement that the representative financial institutions (who are the institutions responsible and liable for the trust in the ecommerce transactions) be able to correctly authenticate the entities that they are taking liability for. There is no requirement that the strangers authenticate each other .... there is only a requirement that the merchant and merchant financial institution be able to trust each other and the consumer and the consumer financial institution be able to trust each other (and of course the two financial institutions be able to trust each other).
creating trust is typically a time-consuming and expensive operation ... trust doesn't happen just because you've met a total stranger and now happen to possibly know their name. one of the purposes for the ecommerce leveraging the existing MOTO trust infrastructure .... and actually the creation for the original MOTO trust infrastructure ... was that you can have instant transactions w/o having to establish any new trust relations at all ... you could immediately have spur-of-the-moment, impulse buying w/o actually having to invoke any new trust creation operations ... you just instantly leverage existing trust relationships.
in the PKI and CA definitions previously distributed from the merged
security taxonomy and glossary at
https://www.garlic.com/~lynn/index.html#glosnote
the incremental requirement to increase the authentication strength of long term trust relationships is to perform the "RA" or registration authority function (for the public key). There are long standing and pre-existing business processes that have been around for a long time that deal with trust and they don't have to be changed.
The threat model in 99.999 percent of existing ecommerce transactions doesn't involve anything to do with new and/or additional certification operations ... and definitely don't require certificates (certificates are redundant and superfluous and can actually represent a hundred fold payload burden bloat and add no additional benefit).
The threat model in 99.999 percent of existing ecommerce transactions is specifically with respect to institutions that need better authentication of entities with which they have long-term and long-standing trust relationship. They have no need to have such pre-existing trust relationships in any way certified.
In fact, the analogy of describing the public key registration as a type of registration authority operation is simply for description sake. The existing financial institutions already have registration processes for information like SSN#, mothers maiden name, PINs, etc. These are all examples of registered information that financial institutions leverage for authentication purposes. From a financial institutional business process ... the additional registration of a public key should in no way be any different than the existing business processes for registration of any other authentication material (it would be at most a technology issue ... but in no way needs to change existing business processes).
So you are either
a) trying for instantaneous transactions ... w/o prior relationship ... and any sort of simple certificate no matter the information ... isn't going to surfice as well as the mechanism that is used for 99.999 percent of current ecommerce operations; which is to leverage long term trust relationships ... where the use of public key would be strictly for authentication purposes and can utilize long standing existing business processes that were designed for registering and using authentication material (public key just becomes a better technology version of PINs). the two strangers in the instantaneous transaction aren't trusting each other ... they are trusting the financial institutions that are standing behind and taking financial liability for the transaction. there is possible technology issue as to whether the two financial institutions can strongly authenticate their respective participating entities.
or
b) you are trying to actual establish a real trust relationship directly between two parties. this isn't trivial operation ... and requires a lot more than exchange of public keys and oh, by the way simple digital signature by itself isn't sufficient to be a legal signature.
As been repeated numerous times before, digital signatures are used for
1) transaction/document integrity ... as to whether or not the bits have been modified since the signature was applied
2) indicating the origin of the bits
It turns out that digital signatures aren't real signatures in the sense that signing a contract with a physical signature is a real signature.
For what ever reasons (besides having been involved in the original inception, development, deployment and operation of what has since been called ecommerce) my wife and I were also brought in on the word smithing of the cal. electronic signature law and then on the fed. electronic signature law. There are very specific requirements that real signatures have with regard to demonstrating intent, agrees, approves, and/or authorizes ... that simple creation of a digital signature doesn't meet ... things typically considered as prerequisite for contracts.
If you are talking about what is necessary for using digital signatures in the sense of legal signatures on a legal contract ... then there is a much higher level of proof that must be met.
One somewhat extraneous issue that I have raised in earlier postings
(and reference several URLs where there was detailed discussion) was
the dual-use attack on digital signatures .... original post referencing
dual use thread:
https://www.garlic.com/~lynn/2004h.html#50 Re: New Method for Authenticated Public Key Exchange without Digital Certificates
This is basically that there are protocols out there where a server effectively sends random bits for the client to digital sign ... as an authentication mechanism. The client digitally signs the random challenge bits w/o examining them and returns the digital signature. A difference between digital signatures and legal signatures is that people should never be expected to legally sign something that they haven't read. Any deployment of mechanisms that promote the use of digital signatures in purely authentication protocols where the signee isn't expected to have read the bits negates the use of digital signatures as legal signatures. At the very lease it must be possible to prove that a specific private key has never been used in non-legal digital signature operations and/or that everything that has ever been digitally signed always has a lengthy legal disclaimer appended prior to signing.
So the other is the whole thing about legal signatures and repudiation. There have been a lot of false starts with digital certificates. First was the wide misstep in the early 90s with trying to overload x.509 certificates with lots & lots of identification information ... until it started to dawn on everybody that represented an enormous liability and privacy exposure.
Another is the definition of the non-repudiation bits in certificates. There were several attempts in the mid-90s to claim that if a digital certificate carried the non-repudiation bit ... and if there was a digitally signed document which had the non-repudiation bit set ... then the digital signature could be interpreted as a legal signature and shift the legal burden of proof (in retail ecommerce scenarios) involving disputes from the merchant to the consumer. The attack is since the traditional process of simply appending a certificate to a separately signed transaction/document ... the relying party just has to find some certificate anywhere in existence for the consumer that has the non-repudiation bit set ... and replace whatever certificate the consumer had chosen to attach, with any certificate with the non-repudiation bit. The problem was that the setting of the non-repudiation bit in a certificate was supposedly creating legal obligations on the part of the person performing the digital signature .... but there was absolutely no integrity control over which real certificate was associated with any operation.
Of course since the early 90s .... identity certificates with anything that might considered private (name, address, zip code, employer) is depreciated ... and the whole issue of the certificate non-repudiation bit has been depreciated.
In any case, specifically to your point about legal signatures absolutely can't be the raison d'etre of CAs ... since they aren't around when the digital signature actually occurs and therefore can't be relied on to give evidence as to intent, agrees, approves, and/or authorizes with regard to the use of a digital signature as a legal signature. A secondary of possibly lessor importance ... is that all CAs that i'm aware of take absolutely no legal or financial liability for entities application of digital signatures.
A third issue is that the business and contractual relationships in the traditional TTP CA model are totally out of sync with standard business contractual and obligation conventions. The contractual relationship between CAs are between the CAs and the public key owner. Typically relying parties are looking to have some legal reliance and obligation. In part, because the CA is certifying the public key in a contractual relationship with the key owner ... there is no certification of the actual digital signature ... on which the relying party must rely ... and there is no contractual relationship between the CA and the relying party. The contractual relationship as to any certification of the public key is between the CA and the public key owner ... and in that contractual relationship, the relying party isn't a part of. Therefore the relying party has
a) no certification of the actual digital signature ...
and
b) any certification of the public key is between the CA and the public key owner ... and there is no legal relationship between the relying party and the CA ... for a relying party to base legal action on if something goes wrong (aka a big part of contracts is to identify who is liable for what at any point in time)
The US federal gov. has attempted to create a legal fiction to get around item "b". The CAs sell certificates to corporations who are suppose to use the related keys to sign documents sent to the federal gov. GSA(?) has legal contracts with all approved CAs for the federal PKI project ... so that the federal gov., as the relying party then has a legal and contractual relationship with the certification authorities. That basis establishes some legal relationship between the relying party and the certification authority. For this same thing to apply to something like SSL domain name server certificates .... every client browser in the world are theoretically the relying parties ... which would then require that every client in the world have individual contracts signed with every certification authority (that they are prepared to accept via the table of root CA public keys that have been preloaded into their browser).
total aside, a frequent and gross mistake that people frequently confuse in the notary analogy ... is that the notaries are typically certifying the application of an actual legal signature ... they aren't certifying that somebody has the ability to make a legal signature ... they are certifying the actual application of a specific legal signature.
An even further aside ... i've somewhat jumped back and forth between financial and security context. Financial context tends to refer to things as trust, risk, fraud, risk mitigation, and risk management. Security context tends to refer to similar things as exploits, vulnerabilities, threats, threat models, and countermeasures.
Back in 2001 there was a long drawn out thread in this newsgroup about the issues of PKI related to non-repudiation ... and in effect what is needed along with digital signature to possibly establish any legal obligation. There is some overlap between the issues discussed in the non-repudiation threads and the issues involved for establishing a legal signature with the demonstration of intent, agrees, approves, and/or authorizes
some random past threads touching of the subject of non-repudiation:
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
https://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
https://www.garlic.com/~lynn/2001g.html#1 distributed authentication
https://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
https://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
https://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
https://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#15 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#42 Beginning of the end for SNA?
https://www.garlic.com/~lynn/2002d.html#16 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002d.html#41 Why?
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#29 Crazy idea: has it been done?
https://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
https://www.garlic.com/~lynn/2002e.html#58 O'Reilly C Book
https://www.garlic.com/~lynn/2002f.html#10 Least folklorish period in computing (was Re: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002f.html#23 Computers in Science Fiction
https://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
https://www.garlic.com/~lynn/2002f.html#45 Biometric Encryption: the solution for network intruders?
https://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for intranet websites?
https://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
https://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002j.html#24 Definition of Non-Repudiation ?
https://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
https://www.garlic.com/~lynn/2002k.html#42 MVS 3.8J and NJE via CTC
https://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ?
https://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
https://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#36 (OT) acceptance of technology, was: Convenient and secure
https://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
https://www.garlic.com/~lynn/2002p.html#23 Cost of computing in 1958?
https://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
https://www.garlic.com/~lynn/2003.html#29 Message (authentication/integrity); was: Re: CRC-32 collision
https://www.garlic.com/~lynn/2003e.html#47 Public key and the authority problem
https://www.garlic.com/~lynn/2003f.html#35 Public Encryption Key
https://www.garlic.com/~lynn/2003f.html#37 unix
https://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003h.html#18 Authentication protocol
https://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN Encryption security, possibly
https://www.garlic.com/~lynn/2003h.html#29 application of unique signature
https://www.garlic.com/~lynn/2003h.html#38 entity authentication with non-repudiation
https://www.garlic.com/~lynn/2003h.html#42 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs
https://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
https://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
https://www.garlic.com/~lynn/2003k.html#6 Security models
https://www.garlic.com/~lynn/2003l.html#65 Strength of RSA with known plain-text
https://www.garlic.com/~lynn/2003m.html#38 Questioning risks of using the same key for authentication and encryption
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003o.html#22 securID weakness
https://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop identity fraud
https://www.garlic.com/~lynn/2003o.html#44 Biometrics
https://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication?
https://www.garlic.com/~lynn/2003p.html#11 Order of Encryption and Authentication
https://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?
https://www.garlic.com/~lynn/2004.html#29 passwords
https://www.garlic.com/~lynn/2004e.html#20 Soft signatures
https://www.garlic.com/~lynn/2004h.html#13 Two-factor Authentication Options?
https://www.garlic.com/~lynn/2004h.html#30 ECC Encryption
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sun, 08 Aug 2004 16:18:06 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
visa doesn't stand behind the merchant or the consumer.
the card associations (visa, mastercard, etc) have specifications, brand compliance and possibly a value added network.
consumer financial institutions provide consumers with cards and assume some financial liability for the role of the consumers. in the case of debit cards, there is specific authentication information that is recorded at the consumer financial institution and is available for the consumer. there is a slight technology issue that the existing PIN infrastructure for authentication between a consumer at places like point-of-sale and atm machines ... is shared-secret based and vulnerable to eavesdropping in the internet context. There is a lot of stuff done at point-of-sale machines to not expose the merchant to the consumer's PIN. This is a treat model for the migration of debit authentication to the internet .... masking the ability of merchants (and others) from the consumer's authentication and being able to impersonate the consumer with fraudulent transactions. The countermeasure for this threat model is to replace the existing PIN-based shared-secret with digital signatures. Such digital signatures (in places of PINs) can flow thru all existing merchant infrastructures w/o the threat that a merchant (or others) can steal the consumer's digital signature and enable impersonation and fraudulent transactions.
at a simple understanding level ... take the existing debit card model ... which is vulernable to evesdropping of the PIN authentication material and replace it with a digital signature. The claims are
1) the existing PIN model works w/o any digital certificates
2) the existing PIN model has an eavesdropping threat
3) the existing PIN model can be upgraded to digital signatures ... keeping the same exact flows and business processes ... but replacing a PIN with digital signatures.
The PIN model tends to be slightly more complex. Remember I've stated that digital signature provides
• message integrity (whether bits are modified or not) • origin of the message
... the PIN process typically does something like calculate an HMAC of the transaction (instead of sha-1 possibly found in digital signature operations) and then encode the HMAC with PIN-based shared-secret. The mechanics of a digital signature tends to provide the same exact function as typical PIN-based transaction operation ... but using public/private key technology rather than shared-secret symmetric key technology.
There is a direct technology translation of the existing PIN-based certificate-less debit card operation to a digital-signature based certificate-less debit card operation.
As a explained in previous posting the pre-1970 was a certificate-like based operation ... where the card was the actual certificate (made of plastic instead of electronic bits). The merchant checked the credential for counterfeit and checked the revocation list booklet sent out once a month to all merchants.
Circa early 70s, a magnetic stripe was added to the card. The card still looked like a credential ... but it operated totally different. There were point-of-sale terminals that went online to the financial infrastructure ... the magnetic stripe on the back of the card was used to authenticate to the consumer's financial institution in an online transaction. The merchant/relying-party wasn't involved in the authentication (other than they hosted the point-of-sale terminal ... but supposedly had a security module and all sort of tamper evident material that acted as an agent for the financial infrastructure ... and not the merchant). Later on, similar magnetic stripes were provided for something called debit cards that operated using the same point of network ... but in addition to the magnetic stripe sent to the consumer's financial institution for authentication, a PIN-based shared-secret was added.
There is absolutely no necessity in the online case for a
certification or credential or other 3rd party mechanism because the
consumer is simply authenticating to the consumer's financial
institution ... with which the consumer has a long standing trust
relationship. There is no requirement in the online transaction case
to present any sort of certificate oriented information to any other
entity ... since the online transaction involves the consumer
financial institution authenticating the consumer ... using some
combination of one-factor or two-factor authentication:
• something you have
• something you know
As you mention, you have no exact knowledge of how any of this
operates.
So there are some activities to introduce certificates into this model
... where the consumer's financial institution is authenticating the
consumer. This is the scenario that would theoretically create a
normal payment transaction (of 60-80 bytes), digital sign it, combined
the payment transaction, the digital signature, and the consumer's
certificate and send it off to the consumer's financial institution
for operation.
Now prior to this, the consumer had gone into their financial
institution, registered their public key, the financial institution
stored the public key in the corresponding account (this turns out is
also required for PKI CA registration authority operation ... but
financial institutions have registering authentication material for
years and years). The consumer could have gotten back what is called a
relying-party-only certificate ... containing just the account number,
the public key ... and possibly 4k bytes to 12k bytes of other bit
gorp.
Now back to (the oft repeated) transaction scenario. the consumer's
financial institution gets the transactions, pulls up the account
record from the number in the transactions, pulls the public key out
of the account record and verifies the digital signature. It never
references the relying-party-only digital certificate. The redundant
and superfluous digital certificate is just there to increase the
payload bloat of the transaction by possibly one hundred times.
The transaction online model is purely an authentication model between
the two entities that have long time trust relationship. It started to
supplant and replace the old fashion offline certificate/credential
oriented model in the early 70s.
Proposals to use digital certificates to return to the old-fashion,
pre-70s, offline certificate/credential model are archaic. The purpose
of the migration to the online paradigm was to eliminate the
credential paradigm ... and actually have the legally responsible
party for the transaction (i.e. the consumer's financial institution)
actually authenticate and approve every transaction. Since the
consumer's financial institution and the consumer have the long term
relationship ... there isn't any requirement for certification between
them. This is an online authentication based model ... not the old-fashion,
archaic, offline credential model.
Ok, some more that you don't know about. part of the length of some of
these replies ... is that there is actually quite a large amount that
you don't know about.
I've already mentioned that the consumers financial institution is
liable for the consumer in the transaction (authenticating and
approving consumer transactions). The merchants financial institution
is liable for the merchant in the transaction (authenticating and
approving what the merchant does ... since the merchant financial
institution is liable for the merchant it is also able to stop
transactions flowing from merchants it wants to throttle/cancel). The
transaction from the consumer doesn't need to be authenticated by
other than the consumer's financial institution. However, it does flow
thru both the merchant and the merchant financial institution
... allowing them to throw it away if they decide to. They can't
actually approve the transaction ... but they can discard the
transaction.
So where do the associations come in.
Well first the advertising for the brand
then back when the online infrastructure was getting going ... we are
talking about tens of thousands of financial institutions that needed
to exchange transactions. the associations put in private value added
networks to interconnect all the merchant financial institutions and
the consumer financial institutions.
finally there is this problem of legal liability and trust between
each individual consumer financial institution and each individual
merchant financial institution .... the basis for creating the
inter-bank trust infrastructure. prior to the invention of the
associations, there was something called bilateral contracts ... in
effect, every consumer financial institution had to have an explicit
contract with every merchant financial institution. This was an NxM
number of contract problem ... actually approximately NxN (since lots
of institutions were both consumer and merchant operations). say for
100000 institutions that is potentially ten billion contracts. The
associations created a legal third party that every financial
institution (that does cards) signs a contract with. The operation of
the legal third party and the individual contracts creates the legal
obligations between the merchant financial operations and the consumer
financial operations ... so there are possibly only a 100,000
contracts instead of 10 billion contracts. In effect it is a two level
structure ... there are contracts between every consumer and every
consumer financial institution ... and then there are contracts
between the consumer financial institution and the association legal
entity. Correspondingly there is a contract between every merchant and
every merchant financial institution and then between every merchant
financial institution and the association.
The arrangement eliminated the requirement that there potentially be
10 billion bilateral contracts between all financial institutions.
It also eliminated the requirement that there be bilateral contracts
between every cardholder and every merchant. While the financial
institution bilateral contract problem is only about 10**10 ... there
would have also been a N*M bilateral contract problem between all
possible cardholders and all possible merchants. Little round-off say
a billion cardholders and only ten million merchants ... say 10**16
potential bilateral contracts potentially required.
This is the 10**16 N*M trust issue that the whole infrastructure side
stepped ... all cardholders only needed a trust relationship with
their consumer financial institutions; all merchants only needed trust
relationships with their merchant financial institutions ... this is
an N+M contractual problem rather than an N*M contractual problem in
the direct trust case. Then the financial institutions only needed
S contracts with the associations rather than S*S.
so the scenarios are
N = billion card holders
M = ten million merchants
S = 100 thousand financial institutions
worst case w/o financial institution trust required are N*M (10**16)
contracts.
worst case w/o association trust, required S*S (10**10) contracts
instead with the current trust model there are N+M+S contracts
required (linear rather than exponential).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sun, 08 Aug 2004 16:38:40 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
So 99.999 percent of the transactions use the standard online authentication based model because of pre-existing long term relationships with the ecommerce, financial transactions.
the problem with financial transactions is that they are typically with the ability to pay. a financial institution is not going to write a very long term, open ended credit for use in an unknown number of transactions involving unknown sums of money.
in the financial/insurance business every contract has a risk and a calculated risk exposure ... it is one of the reasons for migration to online transactions. the merchant financial institution that is legal liable for the financial transactions of the merchant gets to decide on whether to pass or not pass along each and every financial transaction. they then have a real-time knowledge of their risk exposure. the offline model has entities running around wild with credentials that can create an unknown and potentially arbitrary large financial risk for the merchant financial institution. It is just dumb business.
It is the same for the consumer financial operation. If you were a parent ... and you had a choice of giving some relative, your long lived offline payment credential ... that could be used repeatedly in offline transactions with absolutely no restrictions ... would you do it. The consumer financial institution operation has switched to an online authentication and approval paradigm ... which no longer requires demonstrating credentials to 3rd parties. The consumer financial institution then gets to see every financial transaction that it is legally liable for ... and can authenticate and approve every one as it is happening.
So we get to the .001% ... i never said that they were credential based ... i said the rest were pretty much the ebay model ... which escrows funds and does reputational statistics. ebay isn't interested in taking financial liability and creating trust in that manner ... so it sure isn't likely to issue certificates that creates legal liability on behalf of ebay. they provide an operation that escrows funds ... so they aren't on the hook for the consumer payment ... and they provide reputational statistics for consumers to make their own trust decisions based on passed history performance ... but they aren't likely to take on financial and legal obligations and issue certificates claiming that they have.
So all the cases that i know of where true trust is involved ... don't require certificates for trust representation. The online credit/debit model is long term relationships with online authentication and authorization. The ebay model is funds escrow and reputational statistics. ebay doesn't even give an entity a certificate saying that the entities reputational statistics is any number ... that the entity can in turn provide to any other relying party. it is not a credential/certificate oriented system. It is possibly most analogous to the better business bureau model ... the BBB keeps statistics and there are no credentials representing what the BBB statistics are ... if anybody wants access to the BBB statistics ... they go in real time and look at the real time statistics. If you want ebay statistics ... there are no ebay certificates or credentials ... you go to ebay and ask for the current real-time statistics ... analogous to the ebay model.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sun, 08 Aug 2004 17:08:25 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
associations provided a solution around the bilateral contractual problem ... so that every possible financial institution didn't require a contract with every other financial institution. it reduce the 10**10 possible contracts to a linear number of contracts ... one per financial institution. trust was created because there are explicit contractual relationships and legal and financial obligations based on those contracts.
once you have direct contractual relationships ... as in the relationship between the consumer financial institution and the consumer ... with an online environment ... the problem reduces to authentication and authorization and doesn't involved 3rd party certification.
so ... as mentioned ... there is a big disconnect between the standard TTP PKI/CA model ... where the legal obligation and contract is between the CA and the owner of the public key ... the CA has certified to the public key owner that they have certified something about the public key owner. Since no contract (typically) exists between a CA and all the relying parties .... there is no direct contractual legal obligation between the CA and the relying parties as to what the CA may have certified as to the meaning of the public key. And incidentally, the CA is also in no way certifying each and every digital signature.
so if you want to move the TTP PKI/CA model into the legal contractual world there has to be some legal obligation between the TTP PKI/CA certification and the relying parties. That is totally incidental the problem of certificates being redundant and superfluous in an online authentication and authorization model ... as opposed to the ancient and much more risky offline credential/certification model.
As mentioned in previous post ... if you want to expand the TTP PKI/CA model for the existing SSL domain name server certificates to directly be analogous to the way the online payment card works ... you first have to have a chain of legal obligations between all the parties.
So that means that the relying parties ... which are the clients with browsers in this case ... have to have direct contractual relationships with the TTP PKI/CA businesses ... who have created the certificates that they are relying on. So ... what there are possibly 20 major TTP PKI/CA business in operation now ... and possibly one billion client browsers. So to create the equivalence ... every one of the 20 major TTP PKI/CA business operation has to go out and sign a contract with each and every possible client browser owner.
The current scenario is that the 20 possible businesses have sold maybe 100,000 SSL domain name certificates ... and those TTP PKI/CA businesses therefore have possibly some total 100,000 contractual obligations in aggregate. However, that isn't how it would work legally, each one of those 20 possible TTP PKI/CA business operations need separate individual contracts with the one billion potential relying party clients.
Actually you are misquoting me.
I've said that in an online trust operations that the use of certificates are redundant and superfluous ... since the relying parties are either directly performing an authentication operation with somebody that they have a long term relationship or they are directly contacting another party which has a long term relation and will perform the authentication operation.
I've repeatedly said that the original design point for certificates were for use in situations where they relying had no direct access to the real information and that the certificates stood in as better than nothing.
However, as the world rapidly migrates to an online environment the number of situations that meet the original design point criteria are becoming vanishingly small.
The other issue was seen in the migration of the payment card industry from a credential/certificate oriented operation ... before the early 70s ... to an online authentication oriented operation ... there is a cost/risk trade-off. There is a potential risk for the financial responsible trust agencies that have provided the certification ... and that is that there can be a somewhat unbounded number of financial transactions that they will be left holding the bag for. The cost to the financial responsible trust agencies for moving to an online authentication based model (from the offline credential model) is the cost of the online network and the cost of authenticating and approving in real time each individual financial transaction.
The issue is the cost of the online authentication infrastructure offset by the reduction in fraud and risk ... compared to the offline credential model that it replaced. Apparently it was in the 70s ... before the advent of ubiquitous, commercial-off-the-shelf, inexpensive internet. The arrival of the internet supposedly drastically reduces the cost of having an online infrastructure. With a drastic reduction in having an online infrastructure the cost/benefit trade-off of moving from an offline credential based model to a online authentication based model changes significantly.
The assertion is that the online authentication based model then opens up to larger number of different market niches as well as lower and lower valued transactions (as the internet impacts the cost of operating an online infrastructure).
The assertion then is as the online authentication based model extends into more and more market niches ... that the offline credential (aka pki certificate) based model market niche gets smaller and smaller ... aka the places where it makes sense to use an offline credential based operation begins to vanish as the online authentication based model rides the success of the internet.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sun, 08 Aug 2004 17:22:12 -0600Elliott Roper writes:
as a countermeasure for a dual-use attack where the person is sent some valid contractual verbiage under the guise that they are getting a random challenge for authentication ... the person appends a disclaimer paragraph to all data that is advertised as random challenge and doesn't need reading ... specifically a disclaimer that says something to the extent that the person has not read the contents of the message and the digital signature is not met to imply intent, agrees, approves, and/or authorizes any content that is being digitally signed.
a trivial ISP login protocol using standard radius could be deployed that upgrades passwords to digital signatures. the ISP registers the persons public key at the time the account is generated ... and when the person does the PPP connection from their PC at home to their ISP ... they get a random data challenge which they must digital sign and send back the digital signature (in theory it isn't necessary to return the random data to the server ... since the random data originates from the server in the first place). The ISP server can get the public key using standard radius interface ... and verify the digital signature on the random challenge using the radius retrieved public key (in place of doing a password check).
the purpose of the server sending random data challenge to the client as part of connecting to the ISP internet account is a countermeasure to replay attacks.
Now, if somebody wanted to do a dual-use attack on digital signature that is used for both authentication protocols and possibly considered legal signature operations (implying intent, agrees, approves, and/or authorizes) ... they get a virus in the servers authentication protocol ... that sends out legal transactions in lieu of random data. The countermeasure for being tricked into signing fraudulent transactions as part of authentication protocols ... is to 1) read every bit before signing or 2) automatically append a legal disclaimer to the random bits that says that the whatever that is being signed has not been read and the signature is specifically intended to NOT imply intent, agrees, approves, and/or authorizes.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sun, 08 Aug 2004 17:36:20 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
that doesn't mean that the law that they pass conforms to any commonly accepted business practice ... and/or will even standup in court in the event of litigation.
It is possible for laws to sanction business practices that previously weren't sanctioned.
All of that is true. I have said a lot of things in support of digital signatures.
What i've said is that when relying parties have access to the real information in online operations ... then certificates are redundant and superfluous.
The issue that i've constantly raised is that certificates were specifically designed for the offline credential problem ... where the certificates/credentials are better than nothing.
The issue is trying to apply offline credential based model to environments that are rapidly becoming online authentication based model. Typically there can be significantly greater risk mitigation with the online authentication based model ... where every transaction passes through the legal & financially responsible authoritative agency.
The primary purpose for the offline credential based model is the unavailability of online connectivity and/or the cost of doing every operations online. The problem that the offline credential based model infrastructure is facing is that 1) online connectivity is becoming ubiquitous and 2) the cost of online operations is drastically falling.
The significant change in online availability and cost is greatly diminishing the market niches that the offline credential based model was designed to address.
Furthermore ... the inclusion of an certificate in an online authentication based model operation can be trivially shown to be redundant and superfluous.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sun, 08 Aug 2004 17:46:58 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
It was designed to address a very specific problem. It is somewhat analogous that because 18wheel trucks and two-seater sports cars run on the same road then two-seater sports cars can do everything that an 18wheel truck can do. they were each designed for specific purposes.
CAs and certificates were designed to address a situation where the relying party had no recourse to the actual information ... either because the connectivity didn't exist or that online operation was too expensive for what was being done.
The people that claim responsibility ... say that the original design point/justification for certificates were offline email. In the early '80s the traditional email operation involved dialing your local "electronic post office" ... exchanging email and then hanging up. There wasn't ubiquitous connectivity and even when you were actually connected to you local "electronic post office" ... it didn't mean that it was connected to anything else.
the environment was significant amount of store&forward where connections were brought up momentarily ... some available data exchanged and the link dropped. this applied to not only the end client machines ... but also many of the intermediate server machines.
So you are reading the email offline and the problem is how do you know that it is really from the person that it claims to be from. CAs, PKIs, and certificates were designed to address that offline email problem that existed in the early 80s. Just because it is a perfectly good solution for that problem doesn't necessarily mean it is good for anything else at all.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sun, 08 Aug 2004 18:53:03 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
so there was greater financial risk to all the legally liable and financially responsible trust institutions ... compared to having the legally liable and financially responsible trust institution perform online authentication and authorization on each individual transactions. Being able to perform online authentication and authorization on every individual transaction reduces the financial risk exposure to the legally liable institutions. The issue is the increased cost trade-off of using the online authentication based model (compared to the offline credential based model).
For legal signatures ... relying parties have to trust the actual, specific digital signature. CAs are providing certificates (targeted for use in offline environments where the relying party can't actually directly contact the authoritative agency) that certify the public key ... in a contractual relationship with the public key owner.
In traditional business process, there is no contractual obligation between the run of the mill TTP PKI/CAs and the relying party ... with respect to the certification that the CAs have performed for the key owner. NOTE: That doesn't prevent governments from passing laws that state there are implied obligations ... even when explicit ones don't exist.
In any case, in contractual situation that relying party wants to know about the trust in the specific digital signature on a specific contract ... which is something that the TTP PKI/CAs aren't even doing; they are certifying the public key ... not actual digital signatures.
As included in a previous post
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
there is some amount of work going on under the heading of non-repudiation. Some amount of the non-repudiation discussions are on topics that have a large overlap with legal signature requirements.
They can take various kinds of forms where trusted parties (analogous to notaries) are digitally signing contracts or transactions that have already been signed. This is the analogy to the notary function in the real world where the notary is actually certifying a specific legal signature.
Something similar shows up in the EU standard for the FINREAD
terminal.
https://www.garlic.com/~lynn/subintegrity.html#finread
The issue supposedly is that current PC technology can't be
reliably trusted to perform and/or even be involved in the digital
signing of financial transactions. A FINREAD terminal is specified as
reliably and trusted displaying the actual transaction to be signed
(as opposed to a virus infected PC putting up on the screen a
different value for the transaction than the one that actually gets
signed). Furthermore the FINREAD has a trusted PIN entry interface ...
so that there is no possibility of PCs infected with keyloggers and
are able to submit transactions to external cards for signatures w/o
the owners knowledge.
Basically the fundamental structure of digital signature is
• something you have authentication
supposedly the private key that performs the digital signature exists
uniquely in something you possess. The bare-bones digital signature
demonstrates nothing more than you possess the private key ... which
is something you have authentication.
The base, bare bones existence of a digital signature has absolutely no other meaning than you are in possession of the private key that performs the digital signature operations ... and therefore only demonstrates single factor something you have authentication. There are no magic properties ... and no manner of certificates from any number of TTP PKI/CAs can give a digital signature more meaning than that.
So how do you create more meaning ... real fundamental meaning has nothing at all to do with the TTP PKI certification authority certifications of public keys.
So you embed a private key inside a hardware token and have some trust agency certify the hardware token (which has nothing at all to do with certifying the public key).
Then you get a hardware token that won't do the digital signature unless
it gets the correct PIN. You then have some trust agency certify that the
hardware token will never divulge that private key and will only work with
the correct PIN. You know sort of have the basis for two factor authentication
• something you have (the hardware token which uniquely contains the private key)
• something you know (the hardware token only works with the correct PIN).
So what problems are there in the EU with respect to valid legal
financial contracts. The point-of-sale terminals might give you some
indication. The point-of-sale terminals have certified security
modules. You swipe your card thru the terminal (that is something you
have authentication). You then enter you PIN in the terminal (that is
something you know authentication). The terminal then displays
the amount of the transaction and asks if you agree with the
amount. You press YES ... the authentication operations aren't the
thing that creates the valid contract ... it is your pressing YES on a
certified terminal indicating intent, agrees, approves, and/or
authorizes, which is the basis of the valid legal signature. It
isn't the authentication operations that create the basis for a legal
signature ... it is some explicitly required human operation that
indicates intent, agrees, approves, and/or authorizes.
So the EU FINREAD terminal standard is designed to implement something similar to the point-of-sale terminals ... supporting certified security modules, two factor authentication (with chip cards performing digital signatures in the place of magnetic stripe for something you have authentication, certified chip cards that require correct PIN which then implies something you know authentication), certified PIN entry key pad, display certified to correctly display what you are about to sign, and a question/response about do you really want to sign what has been displayed (which provides the basis for intent, agreement and/or approval for a legal signature ... separate from the issue of two factor authentication).
so what is the problem with the current EU FINREAD terminal standard? The point-of-sale terminal security module can prove that a certified point-of-sale terminal was used for each legal transaction. The EU FINREAD terminal currently just specifies the operation of a correctly certified terminal ... it doesn't currently require that a FINREAD terminal was actually used for any transactions.
One way to make the current EU FINREAD terminal standard equivalent to point-of-sale terminals from the standpoint of the consumer financial institution being able to rely on it being a "real" FINREAD terminal used in the transactions ... and not a counterfeit FINREAD terminal ... is to have all the FINREAD terminal digitally sign all transactions after they have been digitally signed by the user's chipcard.
Then the consumer's financial institution gets a financial transaction that has first been digitally signed by the user's chipcard followed by the digital signature of the whole combined thing by the FINREAD terminal. The consumer financial institution has
1) certified the user's hardware token as two factor authentication 2) registers the certified hardware token public key 3) certifies the FINREAD terminal as meeting the EU FINREAD standard, including executing the process required to indicate intent, agrees, approves, and/or authorizes as the basis for legal signature 4) registers the certified FINREAD terminal public key
So being able to pull up the hardware token public key from the account record is sufficient to verify the first digital signature and demonstrate two factor authentication (something you have and something you know).
However, it then requires pulling up the FINREAD terminal public key and verifying the FINREAD terminal's digital signature in order to establish legal signature (i.e. something was done that demonstrates human intent, agreement, and/or approval).
Point of sale terminals both provide the infrastructure for providing a high level assurance about two factor authentication ... and the same process can be used with certificate-less digital signature chipcards.
The EU FINREAD terminal standard also provide the infrastructure for providing a high level assurance about two factor authentication ... and can be used with certificate-less digtial signature chipcaards
Point of sale terminals provide human interaction that is the basis for indicating intent, agrees, approves, and/or authorizes that is the basis for legal signature.
The EU FINREAD terminal standard also provide the infrastructure for indicating intent, agreement and/or approval that is the basis for legal signature.
It is possible to prove every transaction that a point of sale terminal was used for.
It is currently supported that there is proof when a FINREAD terminal was used.
One way of also proving that a FINREAD terminal was used was to have the FINREAD terminal also digitally sign the certificate-less digital signature transaction.
Note that some of the non-repudiation descriptions have processes similar to point-of-sale and the EU FINREAD terminal standard as approaching being able to establish human intent, agrees, approves, and/or authorizes. In effect both the point-of-sale terminal operation and the EU standard specified for FINREAD operation is certifying the transaction as to the human operations have been performed that demonstrate intent, agrees, approves, and/or authorizes. In some sense, both the point-of-sale terminals and the FINREAD terminal are sort of operating as a kind of notary with regard to the certification of the legal signature.
Now, the CA public key certification has no certification for
1) the nature or assurance of the environment housing the private key
2) whether the existence of a digital signature can be interpreted as one-factor authentication, two-factor authentication, and/or even three-factor authentication
3) nothing about actual application of any real digital signature and whether it remotely even meets any minimal requirements to be considered legal signature.
these are all useful things to know when calculating risk, assurance, and/or level of trust.
some random past EU FINREAD standard references:
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
https://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
https://www.garlic.com/~lynn/aadsm15.htm#40 FAQ: e-Signatures and Payments
https://www.garlic.com/~lynn/aadsm16.htm#9 example: secure computing kernel needed
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
https://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
https://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
https://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN Encryption security, possibly
https://www.garlic.com/~lynn/2003h.html#29 application of unique signature
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sun, 08 Aug 2004 18:59:20 -0600Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
verisign then bought the root dns (domain name infrastructure) server company.
supposedly verisign could enhance their root dns operation to have people who register domain names ... also register a (naked) public key at the same time ... and then support all sorts of certificate-less online authentication based models ... but they haven't yet.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: /. passwords - 64 characters, changed daily? Newsgroups: alt.folklore.computers Date: Sun, 08 Aug 2004 21:01:49 -0600well, i couldn't resist the reference
from a long ago and far away april 1st effort:
https://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
https://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.
https://www.garlic.com/~lynn/2001d.html#53 April Fools Day
about this time (circa 1984) we tried to make the case that if you were going to require people to change their 8 digit passwords every month that
1) that they should also require that all physical locks be required to be rekeyed twice a month and people issued brand new keys for the rekeyed physical locks.
2) frequent changes in passwords will result in forcing people in writing the information down and leaving it laying around. fewer changes was actually more secure because of the human factors issue.
... of course i've done a bunch of postings on the desirability to
convert authentication paradigms from shared-secret to
non-shared-secret authentication based models:
https://www.garlic.com/~lynn/subintegrity.html#assurance
https://www.garlic.com/~lynn/subpubkey.html#privacy
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates Newsgroups: sci.crypt Date: Sun, 08 Aug 2004 21:49:04 -0600actually there may be some semantic confusion resulting from the use of the word signature in the term "digital signature".
as discussed in the previous post ...
https://www.garlic.com/~lynn/2004i.html#24
the verification of a digital signature can be used to assume one-factor, two-factor, and/or possibly three-factor authentication.
at the simplest, the verification of a digital signature can imply
that you uniquely possess a specific private key ... and therefore
being able to generate the specific digital signature represents
• something you have authentication (i.e. you have the private key)
the simple knowledge that you might possess a specific private key, by
itself doesn't impart a high level of confidence and/or represent much
of any assurance ... since there are a broad range of implementations
for housing a private key with a verying degrees of security and
assurance feature ... none of which is imparted thru simple knowledge
of private key possession and/or what a certification authority does
in certifying your public key.
so a a serious business operation dealing in matters of real risk and financial exposure ... is interested in exactly how much assurance there might be around such a private key.
the stuff done by the certification authorities might be considered in the minor leagues of certification ... from the stand point of serious risk and assurance.
so a real business operation will possibly certify ... not the public key ... but the characteristics of the physical housing that contains a private key. they are also likely to be interested in certifying the environment in which digital signatures are performed.
so you might find a real business operation requiring that the
public/private key be physically generated inside a EAL4-high hardware
token where it is practically impossible for the private key to ever
leave the hardware token. then when the business operation verifies
a digital signature ... it starts to know something of real importance
• something you have authentication .... both the private key and an
EAL4-high hardware token compo
getting a little more serious ... the business operation gets a
certified hardware token that not only has all the previous
characteristics ... but also requires a PIN to operate. In that
situation when the business operation verifies a digital signature it
has some assurance about two-factor authentication
• something you have authentication ... both the private key and
an EAL4-high hardware token combo.
• something you know authentication ... some required PIN
Now ... having gotten something that is digitally signed ... with the
above known and certified characteristics (with or w/o a certificate
certifying the public key) ... it still doesn't tell the business unit
anything about how the digital signature operation was performed and
whether there is sufficient criteria to meet legal signature
standards. In fact, this particular digital signature in no way
conveys anything pertaining to meeting legal signature standards
... at least not comparable to what you have in point-of-sale
terminals and/or the EU FINREAD standard ... as to presenting
certified information to a human and asking them if they agree and
requiring them to perform some physical operation indicating
agreement.
so the simple comparison model is that a hardware token performing a digital signature is higher assurance with repsect to something you have authentication (that the swipe of a magstripe card ... which has shown to be pretty vulnerable to counterfeiting) ... so if such a a digital signature hardware token is used in place of a magstripe card at point-of-sale terminals and other locations ... the level of assurance would be improved. however, it would still be an instance of something you have authentication. there is no fairy godmother to wave her magic wand to make a digital signature something that it isn't.
the next simple comparison model is that the person enters a PIN at the terminal ... which is directly presented to the hardware token ... and in now way involves any other part of the infrastructure. The existing PINs are effectively shared-secrets between the person and their financial institution. However, a PIN that is presented to something the person owns ... is a secret ... but not a shared-secret. >From the certified operation of the hardware token it can be assumed that the correct pin was entered ... not because the infrastructure can check the pin ... but they can infer the correct pin from the way that the certified hardware token responds.
so with these two changes ... we replace the existing shared-secret
and magstripe-based two factor authentication
• something you have (magstripe card)
• something you know (pin)
with higher assurance PIN-secret and digital signature hardware token ...
however it is still two factor authentication
• something you have (hardware token)
• something you know
Now, at least from the point-of-sale and EU FINREAD standard ... the
generation of the digital signature hasn't demonstrated any human
intent, agrees, approves, and/or authorizes ... sort of the
basis for legal signature ... it purely has established two factor
authentication.
what the current point-of-sale and EU FINREAD standard requires is that
1) a certified interface present the information that is to be agreed to,
2) the person is asked if they agree, and
3) they are required to perform some action to indicate agreement.
The certified business operation of the point-of-sale terminal (or EU FINREAD terminal) provides the basis for believing that there was human intent, agrees, approves, and/or authorizes ... not the generation of a digital signature as part of one-factor or two-factor authentication.
In effect, the point-of-sale terminals and the EU FINREAD standard are trusted automated devices that are performing notary-like certification of the actual transaction. The digital signature isn't the legal signature operation ... it is the two-factor authentication function. The certified method that the terminal operates is the basis for legal signature ... not the application of a digital signature.
Now, it is possible that such certified terminals could also apply a digital signature as proof that they had performed their function. However, this isn't the person's digital signature ... and it has nothing at all to do with the PKI CA function of certifying a public key ... it is the certified business terminal certifying that the legal signature process was performed (which is a process where the human is expressing that they agree and/or approve what they have been presented with).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/