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

From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 08/08/04 

Date: Sun, 08 Aug 2004 23:27:11 +0200

Anne & Lynn Wheeler wrote:

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

I must admit that I haven't too much knowledge. But as
far as I know, digital signatures (of a certain quality)
has legal value in Germany that is equivalent to handwritten
signatures. There was a special law enacted to establish
that. Also there are a number of CAs doing business both in
Germany and in the world. Do you think that their clients
are all fools? (Or else how could these institutions exist
financially?)

Referring to eventual misunderstanding or the like in our
discussion, let me quote myself in an earlier follow-up:

    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.)

You apparently did attempt to correct me (with your follow-up).
So your view is no 'CA' at all is 'ever' necessary, isn't it?
Now, that couldn't be, even if it 'were' true that 99.9999 %
of transactions don't need CA. (For then 0.0001 % would 'need'
that.) Note also that, in case something, once certificated,
could be used for a very long time, the initial certification
isn't therefore dispensible.

[snip]

M. K. Shen

Relevant Pages

  • Proofs, burdens, abrahamic claims, and out-of-band data
    ... When you get a trust point certificates so you can tell if the site ... method that does not directly involve in-band transmission. ... The usual way to do out-of-band is to have the manufacturer of your ...
    (soc.religion.mormon)
  • Re: PGPsigs: the Choice of Con Artists
    ... They can insist whatever they want to insist but if I trust none of them ... You seem to have two problems: one is that you don't like the PGP signature ... signature or break public key encryption. ...
    (comp.os.linux.misc)
  • Re: Secrecy and user trust
    ... Aldo Foot wrote, On 09/04/2008 12:10 PM: ... secure distribution channel. ... The public key really must be distributed in a secure manner. ... Now if some time earlier Jane and I had met, and exchanged public keys and she felt that my signature was worthy of trust[1], and I had signed your key before giving it to Jim, then Jane would have SOME reason to trust that the key came from _WHO_ it claims to come from instead of some key that Jim generated to do a MITM attack. ...
    (Fedora)
  • Re: Proposal for a new PKI model (At least I hope its new)
    ... >>If we should trust these certificates, ... (Just as we should do for existing certificates issued by ... > level certificate to a small organization's PKI server in australia ... HTTPS is precisely so I don't need to trust DNS: ...
    (sci.crypt)
  • Trust in genealogical applications [Was: Re: How Should We Store Evidence in Genealogical Databases?
    ... All that the digital signature guarantees is that the data ... you have to make a decision on which party you trust. ...  Unless, of course, copies of the public key are also ... it can simply make use of existing key servers. ...
    (soc.genealogy.computing)