Re: New Method for Authenticated Public Key Exchange without Digital Certificates

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 08/08/04 

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 theoritical, 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 certficates (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) today's
e-commerce trust between two arbritrary 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 stangers in the transaction ... it is to
improve the authentication in non-face-to-face environment.

the primary parties involved in 99.9999 percent of today's 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
theoritical 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 defintions 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 definitly 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 mearly 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,
agreement, and/or approval ... 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 proove 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-repudation bit set
... then the digital signature could be interpreted as a legal
signature and shift the letal burden of proof (in retail ecommerce
scenarios) inovlving 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 existance
for the consumer that has the non-repudiation bit set ... and replace
whatever certificate the consumer had chosen to attack with the
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 therefor can't
be relied on to give evidence as to intent, approval, and/or agreement
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 liablity 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 onwer ... 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 that contractual relationship, the relying
party isn't a part of. Therefor 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 is 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 notarys 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-repudation threads and the issues involved for establishing a legal
signature with the demonstration of intent, agreement and/or approval.
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/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001g.html#1 distributed authentication
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
http://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#15 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#42 Beginning of the end for SNA?
http://www.garlic.com/~lynn/2002d.html#16 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#41 Why?
http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#29 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
http://www.garlic.com/~lynn/2002e.html#58 O'Reilly C Book
http://www.garlic.com/~lynn/2002f.html#10 Least folklorish period in computing (was Re: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002f.html#23 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002f.html#45 Biometric Encryption: the solution for network intruders?
http://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002j.html#24 Definition of Non-Repudiation ?
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002k.html#42 MVS 3.8J and NJE via CTC
http://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ?
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
http://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#36 (OT) acceptance of technology, was: Convenient and secure
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
http://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
http://www.garlic.com/~lynn/2002p.html#23 Cost of computing in 1958?
http://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003.html#29 Message (authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003e.html#47 Public key and the authority problem
http://www.garlic.com/~lynn/2003f.html#35 Public Encryption Key
http://www.garlic.com/~lynn/2003f.html#37 unix
http://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003h.html#18 Authentication protocol
http://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN Encryption security, possibly
http://www.garlic.com/~lynn/2003h.html#29 application of unique signature
http://www.garlic.com/~lynn/2003h.html#38 entity authentication with non-repudiation
http://www.garlic.com/~lynn/2003h.html#42 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs
http://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
http://www.garlic.com/~lynn/2003k.html#6 Security models
http://www.garlic.com/~lynn/2003l.html#65 Strength of RSA with known plain-text
http://www.garlic.com/~lynn/2003m.html#38 Questioning risks of using the same key for authentication and encryption
http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003o.html#22 securID weakness
http://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop identity fraud
http://www.garlic.com/~lynn/2003o.html#44 Biometrics
http://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication?
http://www.garlic.com/~lynn/2003p.html#11 Order of Encryption and Authentication
http://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?
http://www.garlic.com/~lynn/2004.html#29 passwords
http://www.garlic.com/~lynn/2004e.html#20 Soft signatures
http://www.garlic.com/~lynn/2004h.html#13 Two-factor Authentication Options?
http://www.garlic.com/~lynn/2004h.html#30 ECC Encryption 

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

Relevant Pages

  • Re: selfcert and new image or pc
    ... G'day "prisma", ... including CPU serial numbers and OS install keys. ... and you minimize your need for new certificates. ... When I get a new computer my signature is lost and I ...
    (microsoft.public.office.developer.vba)
  • Re: selfcert and new image or pc
    ... G'day "prisma", ... including CPU serial numbers and OS install keys. ... and you minimize your need for new certificates. ... When I get a new computer my signature is lost and I ...
    (microsoft.public.word.vba.customization)
  • Re: Certificate attributes for Smart Card Logon
    ... signature but also email encryption! ... If you enable the Smart Card Logon, Client Authentication, and Secure ... controllers each already have their own certificates. ...
    (microsoft.public.windows.server.security)
  • Re: Digital verification of authentic documents ?
    ... The first one is a credit reference agency. ... signatures made with the issued certificates are legally ... binding under English law just like a physical signature. ... there are no organisations issuing legally valid PGP keys. ...
    (comp.security.misc)
  • Re: OT Why is the fax machine not dead
    ... Laws, case law, commercial practices, and bureaucratic rulebooks are slowly starting to recognize digital signatures using PKI certificates from a 'recognized' certificate storehouse. ... Lotsa companies with Fed contracts already routinely do contracts and PO's with electronic sigs, ...
    (alt.home.repair)
Loading