ietf
[Top] [All Lists]

Re: PKIs and trust

2003-12-16 14:37:35
Al Arsenault;

The question, then, is, why do you call it "Infrastructure"?

PKI, as defined in the draft, is just a mission specific
structure, not an infrastructure.


AWA:

Well, from "The American HeritageR Dictionary of the English Language,
Fourth Edition
Copyright C 2000 by Houghton Mifflin Company.":  in fra struc ture:  (noun)
1. An underlying base or foundation especially for an organization or
system...

You should check the usage note section of the dictionary. It
eventually says the organization or system should be society
or, at least, large enough.

So a PKI is an "infrastructure" for an organization or system; namely, the
organization or system that uses it.  There's no requirement that a
particular "infrastructure" support the global internet, or any global
community for that matter.

I didn't say it need to be "global" or world wide.

But, it should be large enough, trust relationships within which
is not single threaded and is complex.

Then, there can be no PKI standard, I'm afraid, though there can be
PKI software/hardware standard.

AWA: We agree.

OK.

Now, that being said: there can be no single standard.  What there can be
(and is) is a framework of standards, which can then be selected/tailored
for the appropriate use.  The US Government and Canadian Government have
sets of different standards for PKI (e.g., "Rudimentary assurance", "basic
assurance", "medium assurance", "high assurance", ...; Class 1, Class 2,
Class 3, Class 4).  VeriSign and others offer different classes of PKI
support to their commercial customers.  You pick what's appropriate, given
your specific application, environment, personnel, physical security, other
requirements, and acceptable cost/benefit tradeoffs.

The problem of people working for PKI is that they tend to
neglect easier alternatives.

Societies need infrastructures for security, not necessarily
public key ones.

When users have to have real time communication with CAs, which
is almost always the case, it is a lot easier, simpler, more
efficient (and, thus, a lot more secure) to use shared key
cryptography.

Shared key cryptography must also be tailored for each mission.
However, it is so simple that it does not need complex standard.
E.g., because it is real time, we don't need time stamps for certs
nor CRLs. We can just say, "use plain password" or "use challenge
and response", which is more useful than a complete, if ever, set
of some PKI standard.

Note that I know KDCs dedicated to KDC function is just as
useless as CAs dedicated to CA function. But, credit card
company is a KDC to manage user accounts.

So, no, there will never be a "single PKI" for the Internet, the universe,
or likely for an entire nation.  Nor should their be, IMNSHO.

How do you think about "secure DNS" as a PKI? DNS may be
claimed to be an application by itself. However, as DNS is
used for many different real applications, I think it is too
generic to be useful.

In most, if not all, cases, actual applications/business processes
requires realtime communication with CAs that shared key cryptography
is just enough.

For example, if I use PK based certs for my bank account, I can
withdraw cash from my accunt as many times as I want, unless
remaining credential in my bank account is reduced in real time,
which means I must communicate with my bank as CA, which should
better be KDC.

AWA:  Well, Lynn Wheeler would be happy to hear that!  If you're not
familiar with Lynn, he works for First Data Corp. and is one of the prime
pushers behind the ANSI X9.59 standard, also known as "Account Authority
Digital Signatures" or AADS.  Basically, it assumes that for each account
you have (e.g., credit card account), there is an account authority (e.g.,
the credit card processor; like, say, his company) which holds the public
key for you, in your account record.  Whenever you want to execute a
transaction with your card, you digitally sign it.  The merchant sends the
whole transaction to the account authority, which verifies the digital
signature as part of the rest of the processing.  The account authority does
the real-time check of the digital signature, your account balance, purchase
limits, etc. and gives an approval or rejection based on the total picture.

I don't know Lynn. But, he might feel unhappy to hear that, when
communication is required in real time, shared key cryptography
works a lot better and we already have the global infrastructure
of banks and credit card companies.

Can I have a mail address of him?

My response to your point is the same as it is to Lynn: that's appropriate
for SOME applications.  If what I'm doing is exchanging S/MIME e-mail, which
has nothing to do with financial transactions, there's no reason to use the
AADS structure or anything else.  All I want to know is that the mail came
from you; not whether it's okay to ship you a new DVD player because the
money has been transferred to me.

I just presented a paper on Dec. 15th that, if an attacker have a
cert with which 1M JPY (100K USD) transaction is allowed, he can
use it 1,000 times a second for 1,000 second from 1,000 different
locations, without causing noticable amount of traffic (if a
transaction consumes 1KB, aggregated traffic is merely 8Mbps for
1,000 second) total damage of which is 100T USD, a lot more than
enough to ruin the world economy. Note, of course, that CRLs are
not expected to be issued so frequently.

And, it is just reported today that, on Dec. 14 in Germany, three
people performed false transactions of net auction for 2 hours,
total damage of which is 130M EURO.

So, it is dangerous to the world economy to have security
infrastructure without real time communication for things
with monetary values.

The problem of the world of capitalism almost everything has
monetary value.

Different solutions for different applications. Use what's appropriate. I
think that your comment about "most, if not all, cases,
applications/business processes requires realtime communications with CAs"
is thus incorrect.

If a case involves on-line money, real time communication is
always required. Most, if not all, cases do.

                                                        Masataka Ohta





<Prev in Thread] Current Thread [Next in Thread>