Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
next, previous
- home
- Is The Public Key Infrastructure Outdated?
- redundant and superfluous (addenda)
- Public Key Infrastructure: An Artifact...
- Public Key Infrastructure: An Artifact...
- Public Key Infrastructure: An Artifact...
- Public Key Infrastructure: An Artifact...
- Public Key Infrastructure: An Artifact...
- Public Key Infrastructure: An Artifact...
- Public Key Infrastructure: An Artifact...
- Public Key Infrastructure: An Artifact...
- Public Key Infrastructure: An Artifact...
- Thin PKI won - You lost
- Thin PKI won - You lost
Is The Public Key Infrastructure Outdated?
Refed: **, - **, - **
From: lynn@xxxxxxxx
Subject: Is The Public Key Infrastructure Outdated?
Date: Tuesday November 14, @11:05AM EST (#128)
Website: slashdot.org
from lynn@xxxxxxxx
for years, centuries, etc ... businesses have used account
records for binding of information regarding business processes. Many existing
business processes today even have online, real-time access to such binding
infrastructures ... and, in fact, require such real-time access. Many of these
existing acocunt-based binding infrastructures also include authentication
information and processes for non-face-to-face and face-to-face transactions ...
included are such things like passwords, mother's maiden name, PINs, SSNss,
signature cards, etc. Account Authority Digital Signatures
(AADS ... ref
https://www.garlic.com/~lynn/))
adds public key binding and digital signature
authentiction (for both message integrity as well as authentication) to these existing
business process, account-based, binding infrastructures. In fact, many of the
existing "PKI" deployments have actually used certificates as a front-end facade ...
and than fall-back on traditional account-based binding authentication for the real
operation. AADS just eliminates the duplication, superfluous and redundancy
introduced by the more traditional PKIs.
Is The Public Key Infrastructure Outdated?
Posted by CmdrTaco on Saturday November 11, @11:17AM
from the something-to-think-about dept.
dchat writes: Roger Clarke, Visiting Fellow, Faculty of Engineering
and Information Technology at the Australian National University
claims that the "Conventional, hierarchical PKI, built around the ISO
standard X.509, has been, and will continue to be, a substantial
failure", and then he goes on to explain why. I'd be interested in the
views of Slashdot users, as my organisation is contemplating
considerable investment in X.500 and PKI (including X.509). Lots to
read here.
redundant and superfluous (addenda)
Refed: **, - **, - **, - **
From: lynn@xxxxxxxx
Subject: redundant and superfluous (addenda)
Date: Thursday November 16, @05:17AM EST (#129)
Website: slashdot.org
to a large extent, certificates are an answer to offline electronic
authentication/security. compared to having no authentication/security
in an offline environment, having a copy of some (potentially really
stale) auuthentication/security information is better than nothing.
in that respect, certificates are analogous to the '60s "signing
limit" corporate checks. Printed on each check was the maximum value
that the check could be written for ... say $5000. The problem was
that they started finding people that covered $1m transaction by
signing 200 $5000 checks.
The 1990s online solution is corporate purchase cards ... a special
form of credit cards. Standard credit card is real time transaction
aggregation i.e. say an aggregate of credit limit of $50,000. To that
can be added additional business rules on each transaction. Credit
card transactions normally have had merchant type/code, merchant id,
store id and total transaction amount. Purchase card transactions now
carry SKU/item level detail (in addition to aggregate). Business rules
can be written about transactions at type of merchant (say office
stores), specific merchant, specific store and specific types of itmes
(only pencils and staples) and individual transaction amount (no more
than $20/day, no more than $500/month and only for pens less than $2
each). Also can do groups of account aggregation (all members in
deparment can't spend more than $250/day & only at office stores).
In any case, if it is really offline ... then the certificate 1960s
electronic offline paradigm is an improvement of no
authentication/security at all.
However, if it is a 1990s electronic online paradigm, then offline,
stale certificates repreasent a decrease in the level of
authentication/security that could be done. Or what may happen is an
attempt is made to implement both real online real security as well as
an offline certificate security ... and there is significant cost &
effort duplication (since the offline certificate effort is
redundant and superfluous when the real online security is being done anyway).
Public Key Infrastructure: An Artifact...
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 11/19/2000 08:28 AM
To: Ben Laurie <ben@xxxxxxxx>, Bram Cohen <bram@xxxxxxxx>,
obfuscation@xxxxxxxx, rah@xxxxxxxx, cryptography@xxxxxxxx,
cypherpunks@xxxxxxxx, dbs@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
oh yes, as to the other kinds of certificates.
basically this is an issue of trust establishment. there are various
forms of trust establishment, advertisement, brand, word-of-mouth,
previous history, etc ... not just BBB or consumer report like stuff.
Transactions are highly skewed ... with the majority of transactions having some
form of trust establishment not needing BBB, consumer report, etc. (i.e.
previous history, brand, etc)
on the internet, for the minority of transaction w/o other forms of trust
establishment and which would benefit from a BBB, consumer report, etc solution
... there can actually be two approaches:
1) offline paradigm; certificates are offline paradigm solution ... they've been
manufactured at some time in the past with potentially out-of-date and/or really
stale information.
2) online paradigm; a BBB, consumer report, etc online web site that gives
up-to-date, real-time information about a merchant. these would be well-known
web-sites and merchants could even have buttons that take the consumer to such a
web-site.
Some number of the certification, licensing, & trust organizations
have actually expressed preference for the online paradigm, in part
because it creates a tighter bound with the consumer, they have better
tracking of consumer reliance on their services, and the information
provided is current & up-to-date.
Public Key Infrastructure: An Artifact...
From: Lynn Wheeler
Date: 11/19/2000 08:29 AM
To: Ben Laurie <ben@xxxxxxxx>
cc: Bram Cohen <bram@xxxxxxxx>, obfuscation@xxxxxxxx,
rah@xxxxxxxx, cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
dbs@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
actually ... not really ... this was discussed early this summer as to what they
actually check ... and how trivial it is to fabricate necessary details to pass
such checking
random ref:
https://www.garlic.com/~lynn/aadsmore.htm#client3
in general it is sufficient to have registered any DBA name & have
a d&b entry plus some misc. other stuff ... all relatively easy to
establish. Since the DBA name & d&b entry aren't cross-checked
as part of the SSL certificate validation ... just the domain name in
the certificate against the domain name used ... you could be really
surprised at what comes up for DBA names.
I've had credit card statements that listed the DBA names which had absolutely
no relationship to the name of the store I had been to ... which i eventually
had to call both the credit card company/bank and the store to figure out what
was going on.
Ben Laurie on 11/19/2000 04:08:39 AM
The difference is that a CA _also_ binds the certificate to a legal
entity. When the fraud is discovered, the identity of the fraudster is,
too.
Cheers,
Ben.
Public Key Infrastructure: An Artifact...
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 11/19/2000 12:37 PM
To: Ben Laurie <ben@xxxxxxxx>
cc: Bram Cohen <bram@xxxxxxxx>, obfuscation@xxxxxxxx,
rah@xxxxxxxx, cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
dbs@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
specifically with respect to SSL server certificates ... their primary objective
was supposedly to overcome shortcomings in the domain name infrastructure
integrity (and as stated, most of the SSL server certificate issuing entities
actually also have dependencies on that integrity). Fixes for the integrity of
the domain name infrastructure ... eliminates the domain name infrastructure as
a business case/justification for the existance of those certificates.
Specifically with respect to SSL server certificate, the remaining issue is
possibly merchant/server trust (not trust with respect to internet operational
integrity ... but fusiness/fraud trust with respect to the business operation of
the merchant/server). Establishing that trust goes beyond just having the
comfort that if you are defrauded that you might be able to identify the guilty
party. That can be addressed with an online BBB &/or consumer report type of
service providing real-time information.
Eliminating both justifications for SSL server certificates ... then makes the
vast majority of the existing SSL server certificates redundant and superfluous
(and I believe would severely impact the business case justification for setting
up an operation to provide such a service).
Now this is applicable to the current existing dominant PKI deployment in the
world today (possibly accounting for 99.999999999% of instances where there is a
certificate transmitted and a client checks the contents of that certificate).
It possibly is not applicable to any other hypothetical PKI implementation which
may or may not currently exist.
Ben Laurie on 11/19/2000 05:03:20 AM
This is not a comment on the crapness of PKI, it is a comment on the
crapness of Verisign. The two are far from synonymous.
Don't get me wrong - I don't think PKI is a perfect solution by any
means - however, it gets us nowhere to attribute the faults of others to
PKI.
Cheers,
Ben.
Public Key Infrastructure: An Artifact...
Refed: **, - **, - **, - **, - **
From: lynn wheeler
Date: 11/20/2000 06:51 PM
To: Ben Laurie <ben@xxxxxxxx>
cc: Bram Cohen <bram@xxxxxxxx>, obfuscation@xxxxxxxx,
rah@xxxxxxxx, cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
dbs@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
as pure asside ... any SSL server certificate signed by any CA in my
browswer's CA list is acceptable.
for list of current valid signing CA's in a typical browswer see:
https://www.garlic.com/~lynn/aepay4.htm#comcert14
https://www.garlic.com/~lynn/aepay4.htm#comcert16
my broswer makes no distinction on which CA signed what ... and/or
even what they signed. If I get a certificate signed by any CA in my
browswers list that says foo.bar ... and I think i'm connecting to
foo.bar ... then the SSL connection will go thru.
given that the supposed justification for SSL certificates is
weaknesses in the domain name infrastructure integrity ... and they
beef up the domain name infrastructure integrity (in part so that SSL
certificate issuing operations ... like any from the above list
... can rely on domain names not having been hijacked) ... then it
eliminates that as a business case & justification for SSL
certificates.
There are a lot of short-comings of the existing SSL certificate
infrastructure. To a large extent, most PKI definitions are purely
hypothetical (there is the line someplace, in theory there is no
difference between theory and practice, but in practice there is)
... trivial example is that most PKI definitions include things like
CRLs for dealing with revoked or compromised certificates/private keys
... and yet the SSL infrastructure doesn't have any of that in it
(even tho client checking of server SSL domain certificates accounts
for 99.999999% of all such PKI operations that occur in the world
today).
Ben Laurie on 11/19/2000 05:03:20 AM
This is not a comment on the crapness of PKI, it is a comment on the
crapness of Verisign. The two are far from synonymous.
Don't get me wrong - I don't think PKI is a perfect solution by any
means - however, it gets us nowhere to attribute the faults of others
to PKI.
Cheers,
Ben.
Public Key Infrastructure: An Artifact...
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 11/22/2000 10:29 AM
To: "Arnold G. Reinhold" <reinhold@xxxxxxxx>
cc: Bram Cohen <bram@xxxxxxxx>, Ben Laurie <ben@xxxxxxxx>,
obfuscation@xxxxxxxx, cryptography@xxxxxxxx,
cypherpunks@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
the other scenerio that some certification agencies have expressed
(i.e. licensing bureaus, bbb, consumer report, etc operations) is
that in the online world ... that they would provide an online service
.... rather than certificates designed for an offline world. the
online website provides a superior experience, real-time information,
and a better binding between the certification agencies and the
relying parties (i.e. current use of certificates totally
disintermediate the certification authorities and the relying parties
.... except in the scenerio where the certification authority and the
relying party are the same ... in which case the certificates are
redundant and superfluous).
in the shopping experience trust establishment ... trust can be
established in a variety of ways, brand, advertisement, word-of-mouth,
previous experience, etc. certification trust is just one of the many
ways of establishing various kinds of trust. however, any
certification trust in the online environment could be better provided
by online certification delivery vehicle ... rather than an offline
(certificate) vehicle (which disintermediates the certification agency
and the relying party).
"Arnold G. Reinhold" on 11/22/2000 08:00:34 AM
At 1:59 PM -0800 11/20/2000, Bram Cohen wrote:
>On Mon, 20 Nov 2000, Arnold G. Reinhold wrote:
>
>> Perry's last sentence gets to the heart of the matter. If CAs
>> included a financial guarantee of whatever it is they are asserting
>> when they issue a certificate, then all these problems would go away.
>
>They aren't going to.
>
>-Bram Cohen
>
It's still early in the game to be so certain. But if you are right,
that in it self is an indictment of PKI. If there really is a market
for trust establishment and a form of PKI is the low cost producer of
trust, then someone should be able to make money by using their
expertise to assemble a technology suite and sell trust insurance
based on the spread between the risk perceived by the market and what
they know to be a lower risk. If such services never develop, it
either means there is no market or PKI doesn't have enough economic
impact to cover the costs of starting such a business.
Arnold Reinhold
Public Key Infrastructure: An Artifact...
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/23/2000 12:14 PM
To: Mark Scherling <mscherling@xxxxxxxx>
cc: Bram Cohen <bram@xxxxxxxx>,
"Arnold G. Reinhold" <reinhold@xxxxxxxx>,
Ben Laurie <ben@xxxxxxxx>, obfuscation@xxxxxxxx,
cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
Basically cetificates are an implementation of R/O partial replicated
distributed data that were intended to address availability of information in a
predominately offline environment.
In the SSL server certificates, distribution of CRLs tend to create a problem
for consumers because they aren't likely to want to see 99.99999999999999999999%
of the CRLs distributed and/or they aren't online at the time the CRLs are
distributed (and/or if done via email would create a horrible spam issue ...
every possible consumer in the world receiving email CRLs from every possile SSL
server certificate issuing CA).
The other solution is to go online and do real-time checks ... but doing
real-time checks invalidates basic design decision trade-offs associated with
choosing a R/O partial replicated distributed data implementation in the first
place.
A number of other efforts have looked at the trade-offs associated with large
distributed data implementations and have made various different implementation
decisions based on different criteria & requirements. Some of the partially
replicated data implementations have gone to the trouble if 1) truely offline,
R/O replicated data that has low change frequency, and possible adverse effects
of dealing with stale data is non-existent or 2) support R/W partial replicated
distributed data with various dictionary implemenations keeping track of the
"current" R/W owner.
However, in the case of both having R/O replicated distributed data and also
requiring online access ... creates a situation where the R/O replicated
distributed data implementation is redundant and superfluous (except in some
scenerios where the packet of R/O replicated distributed data is significantly
larger than the transaction to check on its staleness ... aka multi-megabyte
documents might be an example).
It isn't that you can't have perfect R/O replicated distributed data
implementation if there is also concurrent real-time access to the original data
... but that usually invalidates the design decisions trade-offs that justified
having a R/O replicated distributed data implemenation in the first place.
The degree of redundancy and superfluous becomes more significant as outlined in
the SSL server certificate case ... where 1) in large part SSL server
certificates are justified to address integrity weaknesses in the domain name
infrastructure, 2) SSL server certificate issuing agencies are dependent on the
domain name infrastructure as the authoritative source associated with proofing
information for issuing an SSL server certificate, 3) correcting integrity
weaknesses in the domain name infrastructure (needed by the SSL server
certrificate issuing agencies) by registering public keys with domains names, 4)
said registered public keys can both a) eliminate integrity weaknesses
justifying SSL server certificates and b) be distributed as part of domain name
server real time request to the client ... which then can be used in a much more
efficient SSL protocol implemenation.
A possibly better phrase is that in a large number of cases revokation isn't
practical w/o real-time access to the original data ... but real-time access to
the original data obsoletes the need for revokation (by obsoleting the necessity
for R/O partial data replication which might require revokation).
The issue in many scenerios isn't that revokation can't work ... it can work if
you have real time access to the original data ... which obsoletes the
requirement for R/O partial data replication which in turn obsoletes the
requirement for revoking R/O partial data replication. The ideal solution for
revokation is somehting of a catch-22 ... the ideal solution for revokation also
removes the requirement for revokation (somewhat analogous to the catch-22 for
solving the problem that SSL server certificate issuing agencies have with
domain name server infrastructure integrity issues ... the solution is also the
seed for obsoleting the need for issuing SSL server certificates).
Mark Scherling on 11/23/2000 09:24:51 AM
I would like to get further information as to why you don't think
revocation does not work? I'll admit that in the case of the
revocation of Sun's certificates, it was very apparent that the
notification process was weak. The other piece, the browser checking
of expired/revoked certificates is non-existent but if you properly
set up your application, it "should" check the revocation status of
both the CA certificate and the subscriber's certificate.
Your thoughts?
Bram Cohen wrote:
> On Wed, 22 Nov 2000 Lynn.Wheeler@xxxxxxxx wrote:
>
> > the other scenerio that some certification agencies have expressed (i.e.
> > licensing bureaus, bbb, consumer report, etc operations) is that in the
online
> > world ... that they would provide an online service .... rather than
> > certificates designed for an offline world.
>
> Yes, it seems fairly well established that revocations just plain don't
> work.
>
> Once again, the solution to the problems of offline operation appears to
> be online operation.
>
> -Bram Cohen
>
> For help on using this list (especially unsubscribing), send a message to
> "dcsb-request@xxxxxxxx" with one line of text: "help".
Public Key Infrastructure: An Artifact...
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/23/2000 06:39 PM
To: Paul Crowley <paul@xxxxxxxx.uk>
cc: Mark Scherling <mscherling@xxxxxxxx>,
Bram Cohen <bram@xxxxxxxx>,
"Arnold G. Reinhold" <reinhold@xxxxxxxx>,
Ben Laurie <ben@xxxxxxxx>, obfuscation@xxxxxxxx,
cryptography@xxxxxxxx, cypherpunks@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
the other way to look at it ... is why design something that is broken (i.e.
offline certificates in an online world) and then turn around it have to patch
it up (with various online CRLs) ... unless you are really interested in
featuring how broken something is.
there use to be a company that sold a lot of copying machines in the '80s ...
the product was one of the worst in the industry with regard to paper jamming.
they came out with a television ad campaign highlighting how easy it was to fix
paper jams in their product (compred to other products ... which of course you
hardly ever had to worry about fixing paper jams).
misc. refs:
https://www.garlic.com/~lynn/rfcietff.htm
select terms in the above and then select SPKI ... rfc2692 & rfc2693
in many cases ... the use of (offline paradigm) certificaets are
redundant and superfluous in an online environment ... much simpler to
just register a public key with the relying party or if you prefer
.... appended certificates, compressed to zero bytes ... significantly
reducing the problem of revoking information carried in the zero byte
certificate.
https://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2
https://web.archive.org/web/20010419074830/http://lists.commerce.net/archives/ansi-epay/199910/msg00006.html
in general
https://www.garlic.com/~lynn/
random. other
https://web.archive.org/web/20000226031418/http://weever.vic.cmis.csiro.au/~smart/tpki.html
Paul Crowley on 11/23/2000 03:15:52 PM
Lynn.Wheeler writes:
> The other solution is to go online and do real-time checks ... but
> doing real-time checks invalidates basic design decision trade-offs
> associated with choosing a R/O partial replicated distributed data
> implementation in the first place.
Have you looked at the design of SPKI CRLs? I think there are
possibilities in there that address the difficulties you raise.
Public Key Infrastructure: An Artifact...
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/25/2000 08:44 AM
To: John Kelsey <kelsey.j@xxxxxxxx>
cc: Bram Cohen <bram@xxxxxxxx>, "Arnold G. Reinhold" <reinhold@xxxxxxxx>,
Ben Laurie <ben@xxxxxxxx>, obfuscation@xxxxxxxx,
cryptography@xxxxxxxx, cypherpunks@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
public keys can be used to provide some degree of trust propagation
w/o the problems associated with shared-secrets ... independent of
key-exchange for session confidentiality.
certificates were designed to provide for offline trust propagation
(i.e. trusted 3rd party generating paper credentials in the days of
sailing ships ... for things like letters of credit).
two possible online scenerios for online trust propagation was online
domain name infrastructure providing public key as part of online
hostname resolution response ... and licensing/certification agencies
providing public key as part of a trust lookup.
trust propagation also works going from highly authenticated
environment ... which might register a public key with a relying
party; to a quickly authenticated environment remote, non-face-to-face
transactions with digital signature (the digital signature would be a
mathematical encapsulation of the authentication business process that
occured as part of public key registeration) . Asymmetric algorithms
have some advantages over traditional shared-secret algorithms in that
there can be lower maintenence expense at the relying party
(i.e. security exposure associated with divulging a shared-secret).
random refs:
https://www.garlic.com/~lynn/2000f.html#1
https://www.garlic.com/~lynn/2000f.html#3
John Kelsey on 11/24/2000 12:59:42 PM
At 04:47 PM 11/22/00 -0800, Bram Cohen wrote:
>On Wed, 22 Nov 2000 Lynn.Wheeler@xxxxxxxx wrote:
>>the other scenerio that some certification agencies have
>>expressed (i.e. licensing bureaus, bbb, consumer report, etc
>>operations) is that in the online world ... that they would
>>provide an online service .... rather than certificates
>>designed for an offline world.
>Yes, it seems fairly well established that revocations just
>plain don't work.
>Once again, the solution to the problems of offline
>operation appears to be online operation.
And the annoying thing about this is that once we go to
needing an online trusted third party to allow us to have
secure communications, we may as well chuck the public key
stuff and just use symmetric ciphers and the key exchange
protocols worked out ten or fifteen years ago. Which makes
me suspect that we're just not using public key mechanisms
very intelligently yet. We've realized that screws are
better for many jobs than nails, it's just that they're so
damned hard to hammer in....
--John Kelsey
Public Key Infrastructure: An Artifact...
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 11/27/2000 02:37 PM
To: "Arnold G. Reinhold" <reinhold@xxxxxxxx>
cc: cryptography@xxxxxxxx, cypherpunks@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
problem is that consumer don't normally know that they want to check on a
particular merchant's CRL entry until they realize that they want to go to that
merchant site. in general, the consumer's aren't going to want keep a local
(usenet) database of all CRL entries (however they are distributed) ... so it is
more likely the ISP would have to keep all the entries ... pushed into a
database ... and let the consumer do an online database lookup of the CRL
entries (effectively the local ISP is keeping cached copy of all entries ... and
uses usenet as the distribution infrastructure).
sometimes, usenet can take several hrs to a day to propagate ... so the person
may still want to do an online transaction against the agency that issued a
certificate
In which case, the local ISP would be considered a "stand-in" ... maintaining a
negative file ... and returning positive answers if there isn't a match in the
negative file for the online transaction ... in which case the consumer may
still want to do another online transactions against the master file (located
somewhere in the internet).
Given that online transactions are being performed ... then it may even be more
straightforward to use domain name infrastructure to manage distribution and
management of cached entries. It has a somewhat better online transaction
semantics than usenet (already). However, since this is turning into online
transaction infrastructure ... it is then possible to eliminate both the
certificates and CRLs totally and just use the straight-foward domain name
infrastructure.
back again to certificates typically being redundant and superfluous in an
online infrastructure.
"Arnold G. Reinhold" on 11/27/2000 07:53:35 AM
At 11:17 AM -0800 11/23/2000, Lynn.Wheeler@xxxxxxxx wrote:
>Basically cetificates are an implementation of R/O partial replicated
>distributed data that were intended to address availability of
>information in a
>predominately offline environment.
>
>In the SSL server certificates, distribution of CRLs tend to create a problem
>for consumers because they aren't likely to want to see
>99.99999999999999999999%
>of the CRLs distributed and/or they aren't online at the time the CRLs are
>distributed (and/or if done via email would create a horrible spam issue ...
>every possible consumer in the world receiving email CRLs from every
>possile SSL
>server certificate issuing CA).
Sounds like a job for Usenet.
Arnold Reinhold
Thin PKI won - You lost
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/15/2000 11:01 AM
To: Camillo Särs <Camillo.Sars@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
PKIX-List <ietf-pkix@xxxxxxxx>
Subject: Re: Thin PKI won - You lost
in retail electronic transactions ... not only is "identity" fairly
irrelevent ... it represents privacy compromise
that is one reason that some of the european parties a couple years
ago went to relying-party-only certificates ... we've been able to
show for 3-4 years that using certificate compression techniques that
such certificates can be highly compressed to zero bytes (redundant
and superfluous to repeatedly resend copies of information to the
relying party that has the original copy of the information).
the real issue is does any of the transactions have to be offline. the
analogy is the business paper checks of the '60s that had signing
limits ... until they found that people were signing 200 individual
checks to achieve their results.
certificates (of whatever kind) represent offline trust propagation
between entities with no prior business relationship. as online
becomes more & more prevalent and online costs drop, the threshold
justifying not doing things online is dropping. the typical current
day replacement for the '60s signing limit paper checks is a corporate
purchase card, akin to a form of (online, electronic) credit card,
that in addition to the familiar credit limit (i.e. real time
aggregated balance), also can have business rules about things like
merchant type, specific merchant, merchant location, and SKU (product)
codes.
x9.59 (financial industry standard for all electronic account-based
retail transactions) addresses all of this.
the response (to the merchant) doesn't currently have to be signed for
authentication purposes because it comes in via a trusted network. One
could imagine migration to a non-trusted network implementation for
the response ... reguiring signed authentication. However, because of
the required prior business relationships there isn't a requirement
for offline trust propagation, the public key of the responding
merchant financial entity is simply installed at the merchant
(possibly in a manner similar to the way that root public keys are
delivered in browsers, but under somewhat more strict business
controls).
one way of characterising a much thiner form of PKI uses highly
optimized compression techniques for redundant and superfluous
information transmission reducing certificate to zero bytes in
cases of online transaction between entities with prior business
relationship (i.e. in the retail transaction scenerio, there is a
consumer instruction to the consumer's financial institution, and the
response is an instruction from the merchant's financial institution
to the merchant).
the transaction value threshold for offline trust propagation
involving certificates that haven't been compressed to zero bytes is
dropping as online becomes more & more ubiquitous and the
corresponding cost of online drops.
Camillo Särs on 12/15/2000 04:46:17 AM
I tend to agree with you. For most on-line transactions, the concept
of "identity" is fairly irrelevant - the real issue for the relying
party is the authorization to perform an action. Once the high-level
legal trust relationships exist [Read: "If you cheat, we will sue you
out of business."], the remaining issues are mostly about transferring
authorization - delegation - and avoiding fraud by the users.
Thin PKI won - You lost
From: Lynn Wheeler
Date: 12/15/2000 11:03 AM
To: Camillo Särs <Camillo.Sars@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
PKIX-List <ietf-pkix@xxxxxxxx>
Subject: Re: Thin PKI won - You lost
the response (to the merchant) doesn't currently have to be signed
for authentication purposes because it comes in via a trusted network.
One could imagine migration to a non-trusted network implementation
for the response ... reguiring signed authentication. However, because
of the required prior business relationships there isn't a requirement for
offline trust propagation, the public key of the responding merchant
financial entity is simply installed at the merchant (possibly in a manner
similar to the way that root public keys are delivered in browsers,
but under somewhat more strict business controls).
of course one could quibble whether the above referenced signed
response is a thin certificate or not. it could look & taste like
a thin certificate ... the primary business difference between a thin
certificate and a signed transactions ... is one (the certificate) is
signed before the transaction (and might possibly be used for multiple
transactions) and the other (signed transaction) is specific to the
current transactions. In effect, the thin certificate has the liable
party signing something for offline trust propagation that they might
not have exact knowledge of before hand. As a thin PKI makes more
& more of the transition to online ... it eventually crosses the
business line from doing pre-authorized signatures to signing the
actual transactions.
AADS Postings and Posting Index,
next, previous
- home