List of Archived Posts

2004 Newsgroup Postings (08/7 - 08/08)

Hard disk architecture: are outer cylinders still faster than inner cylinders?

Hard disk architecture: are outer cylinders still faster than inner cylinders?

New Method for Authenticated Public Key Exchange without Digital Certificates

Univac 9200, 9300: the 360 clone I never heard of!

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

Hard disk architecture: are outer cylinders still faster than inner cylinders?

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

/. passwords - 64 characters, changed daily?

New Method for Authenticated Public Key Exchange without Digital Certificates

Hard disk architecture: are outer cylinders still faster than

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:

Er, that's what the OS file system cache is for.  There's no good
reason to place that cache out on the disk where it can take
hundreds of microseconds to fetch (through the bus, the controller,
and the device driver) vs. a few microseconds in the cache.

the other is that for given amount of cache, single common global
cache outperforms local/partitioned caches (except for some
pathelogical cases where single sequential, non-use activity is allow
to overrun everything).

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
http://www.garlic.com/~lynn/subtopic.html#wsclock

random posts mentioning global LRU & local LRU replacement strategies
http://www.garlic.com/~lynn/94.html#1 Multitasking question
http://www.garlic.com/~lynn/96.html#0a Cache
http://www.garlic.com/~lynn/96.html#0b Hypothetical performance question
http://www.garlic.com/~lynn/98.html#54 qn on virtual page replacement
http://www.garlic.com/~lynn/99.html#18 Old Computers
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000f.html#34 Optimal replacement Algorithm
http://www.garlic.com/~lynn/2000f.html#36 Optimal replacement Algorithm
http://www.garlic.com/~lynn/2002c.html#49 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002o.html#30 Computer History Exhibition, Grenoble France
http://www.garlic.com/~lynn/2003f.html#55 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#55 Advantages of multiple cores on single chip
http://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004g.html#13 Infiniband - practicalities for small clusters

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

Hard disk architecture: are outer cylinders still faster than inner cylinders?

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:

Absolutely.  The only situation I can think of off-hand where placing large
amounts of cache right at the storage can at least *sometimes* make sense is
when that storage is concurrently shared among multiple hosts:  while there
are good algorithms for handling a shared cache that is distributed among
those hosts, a central cache, though slower, is simpler (though not that
much:  if you need to handle distributed locking anyway, you can piggyback a
great deal of the cache coherence activity on the lock messages) - and by
virtue of being centralized more efficient in space use (well, it's possible
to create a distributed shared cache that never holds more than a single
copy of a given datum to achieve equal space efficiency, but that adds yet
more complexity and maintenance overhead).

another problem is if you have file system level cache of any kind
... as well as any kind of outboard cache ... then the outboard cache
has got to be extremely large to provide any benefit. the issue is to
be in the outboard cache ... it has to have been pulled (or pushed)
thru the outboard cache by some system level operation ... in which
case such records are going to exist in the system cache. from then
on, for the record in the outboard cache to be of any benefit ... it
will need to have expired out of the system cache (otherwise the
outboard cache entry is redundant and superfluous). typically for
records to have expired out of the system cache ... and not out of the
outboard cache ... the outboard cache has to be significantly larger
than the system cache.

when I was working on the distributed lock manager for ha/cmp ...
http://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
http://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
http://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001j.html#47 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2002e.html#67 Blade architectures
http://www.garlic.com/~lynn/2002f.html#1 Blade architectures
http://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
http://www.garlic.com/~lynn/93.html#12 managing large amounts of vm
http://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
http://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
http://www.garlic.com/~lynn/2001n.html#78 Swap partition no bigger than 128MB?????
http://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#16 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#19 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
http://www.garlic.com/~lynn/2002f.html#20 Blade architectures
http://www.garlic.com/~lynn/2002f.html#26 Blade architectures
http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
http://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004h.html#19 fast check for binary zeroes in memory

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

New Method for Authenticated Public Key Exchange without Digital Certificates

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 -0600

note 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
http://www.garlic.com/~lynn/2004i.html#1
... this is respect to work i had done in ha/cmp
http://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
http://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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

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

Univac 9200, 9300: the 360 clone I never heard of!

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 -0600

jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:

It's true they had the same *user mode* instructions, but the architecture was
different at other levels, so a Spectra could never run a 360 operating system.

and 370s just barely ran 360 operating systems for at least a time
... and became less so over time ... if nothing else, device driver
issues became more and more of a problem ... however, the operating
systems attempted to mask as much of that as possible from application
programs.

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

New Method for Authenticated Public Key Exchange without Digital Certificates

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 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

Thank you again for the informations. Let me say, though,
some humble opinions and please correct me if they are wrong.
In order that the PK stuff functions in general, some authority
(somewhere) which common people can (would) trust is essentially
necessary for issuing certain certificates (in some way) on
which the trust between people, who don't otherwise know or
trust one another, could be built up. This implies that any
faults or human weakness (including frauds) associated with
such authorities and their ways of functioning are understood
to be the 'natural' risks involved in employing PK.

part I:

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"
http://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
http://www.garlic.com/~lynn/subpubkey.html#sslcert
when applied to this stuff some people call electronic commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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 | http://www.garlic.com/~lynn/

New Method for Authenticated Public Key Exchange without Digital Certificates

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 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

Thank you again for the informations. Let me say, though,
some humble opinions and please correct me if they are wrong.
In order that the PK stuff functions in general, some authority
(somewhere) which common people can (would) trust is essentially
necessary for issuing certain certificates (in some way) on
which the trust between people, who don't otherwise know or
trust one another, could be built up. This implies that any
faults or human weakness (including frauds) associated with
such authorities and their ways of functioning are understood
to be the 'natural' risks involved in employing PK.

ok, part II.

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:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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
http://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
http://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
http://www.garlic.com/~lynn/subpubkey.html#privacy

some general number of posts on exploits, vulnerabilities, threat
models, and fraud:
http://www.garlic.com/~lynn/subintegrity.html#fraud

some general number of posts on assurance
http://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 | http://www.garlic.com/~lynn/

New Method for Authenticated Public Key Exchange without Digital Certificates

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 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

Thank you again for the informations. Let me say, though,
some humble opinions and please correct me if they are wrong.
In order that the PK stuff functions in general, some authority
(somewhere) which common people can (would) trust is essentially
necessary for issuing certain certificates (in some way) on
which the trust between people, who don't otherwise know or
trust one another, could be built up. This implies that any
faults or human weakness (including frauds) associated with
such authorities and their ways of functioning are understood
to be the 'natural' risks involved in employing PK.

ok, part III

.... 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 | http://www.garlic.com/~lynn/

New Method for Authenticated Public Key Exchange without Digital Certificates

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 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

Thank you again for the informations. Let me say, though,
some humble opinions and please correct me if they are wrong.
In order that the PK stuff functions in general, some authority
(somewhere) which common people can (would) trust is essentially
necessary for issuing certain certificates (in some way) on
which the trust between people, who don't otherwise know or
trust one another, could be built up. This implies that any
faults or human weakness (including frauds) associated with
such authorities and their ways of functioning are understood
to be the 'natural' risks involved in employing PK.

... and possible part 4.

... 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
http://www.garlic.com/~lynn/aepay10.htm#53 First International Conference On Trust Management
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm14.htm#45 Keyservers and Spam
http://www.garlic.com/~lynn/2003f.html#45 Timesharing TOPS-10 vs. VAX/VMS "task based timesharing"
http://www.garlic.com/~lynn/2003l.html#43 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#46 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#53 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/aadsm17.htm#58 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#14 In Search of Eve - the upper boundary on Mallory
http://www.garlic.com/~lynn/aadsm18.htm#15 In Search of Eve - the upper boundary on Mallory

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

Hard disk architecture: are outer cylinders still faster than inner cylinders?

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:

IIRC IBM's inimitable C. Mohan detailed such a mechanism in one of his many
ARIES papers.  Was that yours?

i believe some amount of that was (re?)invented after i left.

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 | http://www.garlic.com/~lynn/

New Method for Authenticated Public Key Exchange without Digital Certificates

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 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

That in my view would convey the implication that one could
dispense with certificates at all and further that the
existence of the institutions CA is actually not justified.
From what you later explained I think that my said impression
of your sentence above is wrong and that anyway one 'needs'
some CAs (whatever the character string denoting 'CA' should
properly or reasonably be) in order for the whole to function.
(If this is still wrong, please kindly correct once again.)

there are frequently trust agencies .... which have nothing
at all to do with PKI oriented certification authorities.

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 | http://www.garlic.com/~lynn/

New Method for Authenticated Public Key Exchange without Digital Certificates

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 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

I am quite sure that there is some misunderstanding between
us. Whether 'certification authorities', 'certificate authorities',
'trust agencies', or 'X', etc...., one needs 'something' that
enjoys the trust of common people somewhere in the whole
mechanism that involves PK such that it functions in practice.
Is this right or wrong? If right, then that institution (or
institutions) by definition does 'certify' something, no
matter whether it directly certifies to the end users or not.
Am I right? Thanks.

the traditional public key certificates have been defined as
containing a public key and some information bound to that public key
... as certified by some certification authority.

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 | http://www.garlic.com/~lynn/

New Method for Authenticated Public Key Exchange without Digital Certificates

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 -0600

on 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 | http://www.garlic.com/~lynn/

New Method for Authenticated Public Key Exchange without Digital Certificates

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:
http://www.garlic.com/~lynn/index.html#glosnote

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 | http://www.garlic.com/~lynn/

New Method for Authenticated Public Key Exchange without Digital Certificates

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 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

As said previously, you (thanfully but unnecessarily) gives
too much infomrtions for my question(s). To repeat, what I
claimed is that there must be some institution (no matter what
its name actually is) that enjoys the trust of common people
(hence in this sense 'autoritative') and testifies the
correctness of certain essential information which assures
(directly or indirectly) the security of the user transactions
involved. That 'testifying' from it may not necessarily be
directed to the end user, I suppose. But anyway, some
'certificates' (in some form) are issued by that 'authority'
such that the whole system functions in practice. In this sense
one needs some 'certifying authority' (whatever it is called
actually).

which i interpret to mean that you have totally changed the context and
meaning of the original subject matter and extended it to imply that
you are referring to any situation where there might be some trust
agency that is somehow responsible for the integrity of some
information.

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
http://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 | http://www.garlic.com/~lynn/

New Method for Authenticated Public Key Exchange without Digital Certificates

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 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

Sorry for some (obvious) typos above.

Addendum: I guess that the said certifying stuff from the
said institution, even in case it is not directly seen by
the end users, is in most cases likely to be in the form of
a digital signature as commonly understood in the literature.

but as I interpret your context .... it is any certifying of any
information ... which may utilize a digital signature for

1) message integrity
2) authentication

a) the simple application of digital signature indicates to
the receiving party that the message has not been modified
during transmission (and/or since it was originally signed)

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 | http://www.garlic.com/~lynn/

New Method for Authenticated Public Key Exchange without Digital Certificates

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 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

In any case, I would think that some digital certificates
(in the commonly understood sense) are actually issued by
some institution(s) in the whole PK mechanism, even if these
certificates are in some cases not directly seen by the end
users. So some CAs issue certificates such that the PK
mechanism works. (In this sence I didn't change the context.)

the certificates in the context of digital signature public
certificates are issued in the sense that relying parties can rely on
the trust in the binding between the public key and the other
information that is contained in the digital certificate.

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 | http://www.garlic.com/~lynn/

New Method for Authenticated Public Key Exchange without Digital Ceritificates

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 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

(2) If one has other means to estabish trust, say for purpose of
discussion two firms that use paper-mails to exchange their public
keys (with handwritten signatures), then, assuming such handwritten
signatures are acceptable (without notary etc.), then of course
(trivially) the communication over the internet works properly. But
that is entirely not in the spirit of modern e-commerce, right?

you kept saying you were confused when i claimed that (public key
digital) certificates were redundant and superfluous in situations
where relying parties had recourse to direct online information. by
implication when relying parties have recourse to direct online
information ... they have *other* mechanisms for establishing trust.

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:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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 | http://www.garlic.com/~lynn/

New Method for Authenticated Public Key Exchange without Digital Certificates

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 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

It is surprising that you are accustomed employ so many words
instead of arguing very concisely and to the point. Note that
one could today do business even in the art of the 18th century,
employing nicely handwritten contracts, personal couriers etc.
But do we want to exploit the modern technologies to their
'maximum' potential? Do we ever desire to have agreements that
are online done and yet have the same legal value as paper
docuemnts? That means one needs PK with which to do digital
signatures (have contracts that are digitally signed). CA
performs clearly an essential role in enabling the deployment
of the modern possibilities for that. They are not redudant.
To refer to your own words 'stale static PK certificates' in
a previous post, that word 'stale' means the information could
be outdated, right? In particular, the PK of the partner that
one knows previously could eventually be outdated. So, at
least for new transactions of large financial value one
would need to assure beforehand that the PK is still valid and
not revoked in the meantime, right? How would you do that?
Per ordinary mail, or what? So you see that even with old
buisness partners one would resonably/sensibly need the services
of CA, not to mention new partners whose genuine PK one is not
sure to know without a CA in the 'general' case (again assuming
that one don't want to fall back to the old traditional
technologies). Isn't this every trivial and clear stuff?
Could you attempt to refute these points concisely?

There are surely cases one wouldn't necessarily need CAs,
but then there are also cases where one wouldn't even need
a formal contract at all. Some small contracts in a number
of countries are even today done verbally and completed with
a handshake. Thus your extreme deprecation of the role/value
of CA in the PK mechansim for modern e-commerce is totally
unjustified in my view.

Let me resume this way: Do we need digital signatures for
contracting or not? If yes, then the PKs involved have to be
certified. That's the raison d'etre of CAs. Without 'any' CAs,
one would have to fall back to the traditional pre-PK
technologies for that certification. But then do we even
need PK at all? We could certainly also sign contracts
manually, don't we?

I guess part of the problem is that my wife and i actually
participated in the creation, development, deployment,
and operation of what was going to become called e-commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

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
http://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:
http://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 theoritically 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:
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~