Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #3299

Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked

Show key headers only | View raw

Terje Mathisen <"terje.mathisen at tmsw.no"> writes:
> The real question is this:
>
> Given Secure DNS, there is absolutely no real reason for having a a
> totally separate mechanism, with 200+ CAs all getting a _lot_ of money
> for issuing SSL certificates:
>
> Each and every DNS domain name registered with a Secure DNS
> certificate could/should also be _the_ CA for all servers in that
> domain.
>
> The main problem with this approach is probably that it would remove a
> huge source of income for the CAs: Back in 2009 Netcraft reported that
> the number of such certificates passed 1 million.

re:
http://www.garlic.com/~lynn/2011k.html#63 Somewhat off-topic: comp-arch.net cloned, possibly hacked
http://www.garlic.com/~lynn/2011k.html#65 Somewhat off-topic: comp-arch.net cloned, possibly hacked
http://www.garlic.com/~lynn/2011k.html#67 Somewhat off-topic: comp-arch.net cloned, possibly hacked

Domain name CA industry is somewhat caught in catch-22, they need part
of DNSSEC where domain name owner registers public key as countermeasure
to domain name hijacking (and all future communication is authenticated
with the on-file public key) ... since critical part of their business
is matching information on certificate application with the information
on file at domain name infrastructure (as regard true domain name
owner). But once those keys are on-file and online available ... they
can be used in lieu of digital certificates
http://www.garlic.com/~lynn/subpubkey.html#catch22

the certification authority business tries to imply digital certificates
have some sort of mystical properties. their original design point was
electronic version of letters of credit/introduction (from the sailing
ship & earlier periods where relying parties would have no other
alternatives regarding first time interaction with complete stranger)
for the offline email of the early 80s (dial-up local postoffice,
exchange email, hangup, and have first-time email from complete stranger
that needs some sort of authentication).

for higher-value interactions, relying party has either local
information and/or access to online authority to obtain the information
(especially with ubiquitous internet connectivity).

typical non-CA operation, is relying party has trusted local store where
they retrieve on-file public key for authenticating digitally signed
information. 

for typical CA operation, relying party has trusted local store of CA
public keys (purely artifect side-effect stored in certificate format)
that is retrieved to verify the digital signature on an appended digital
certificate, then the public key is extracted from the appended digital
certificate to verify the digital signature on the actual message.

the root trust authority for relying parties is trusted local store of
public keys (wither it is the non-CA model or the CA model). In the DNS
case, each user has list of root domain name servers ip-addresses in
local store of trusted domain name servers. This local trusted store of
root domain name server ip-addresses is straight-forward extended to
have public keys in combination with the corresponding ip-addresses
(which would be required regardless of whether a non-CA or CA model was
used). lots of past posts of certificate-less public key discussions
http://www.garlic.com/~lynn/subpubkey.html#certless

in the mid-90s, the major certification authorities were circulating
busines plans on wallstreet that every person in the country would have
an annually renewed digital certificate @$100/annum (minimum $20B/annum
industry revenue). The claim was that it would be justified by the
financial industry requiring a certificate appended to every financial
transaction. The problem was that even abbreviated digital certificates
had payload size that was 100 times larger than existing payment
transaction payload ... and the processing MIPs for digital certificate
was 100 times larger than existing payment transaction processing ...
which was redundant and superfluous.

The design point for digital certificates was first time interaction
between complete stranger. Since consumers already had to have a
business relationship with their financial institution (that would be
processing the financial transaction) ... that having a 100 times
payload and processing bloat was redundant and superfluous ... all the
financial institution needed was to have their customer register a
public key as part of their account information.

In fact, for other reasons, the financial institutions (before realizing
the enormous bloat overhead) had already required that transactions have
appended digital certificates that were "relying-party only"
... i.e. specific to institution ... that included the customers account
number. There was just an artificial distinction that the bank customer
registered their account number and public key with a different
operation than opened the account. Showing that collapsing both the
account number and public key registration into single business
operation ... make it clear that appending digital certificates (on
every payment transaction) was redundant and superfluous (as well as
eliminated the 100* time payload and processing bloat) ... which shot
the $20B/annum industry business case.  some past posts discussing the
enormous bloat 
http://www.garlic.com/~lynn/subpubkey.html#bloat

The certification authority interests attempted to come back in
financial standards body with work item for "compressed"
relying-party-only digital certificates ... where information was
eliminated that was either 1) already in possession of the financial
institution or 2) was common to all relying-party-only digital
certificates. This was anticipated to possibly getting the payload bloat
down to only ten times existing payload transaction size. Instead of
showing that appended digital certificates were redundant and
superfluous, I showed that such digital certificates could be compressed
to zero bytes ... and that there could be mandatory append of zero byte
digital certificates on every financial transaction.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Somewhat off-topic: comp-arch.net cloned, possibly hacked "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-28 19:49 -0700
  Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked EricP <ThatWouldBeTelling@thevillage.com> - 2011-08-28 23:32 -0400
  Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked EricP <ThatWouldBeTelling@thevillage.com> - 2011-08-28 23:49 -0400
    Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-29 08:59 -0700
      Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked EricP <ThatWouldBeTelling@thevillage.com> - 2011-08-29 12:40 -0400
        Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-29 12:00 -0700
        Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-29 12:00 -0700
          Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked George Neuner <gneuner2@comcast.net> - 2011-08-29 21:31 -0400
          Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-29 22:12 -0400
            Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-30 09:38 -0400
            Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-30 10:51 -0400
          Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-30 13:53 +0200
            Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-30 06:59 -0700
              Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-30 10:23 -0400
                Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked kenney@cix.compulink.co.uk - 2011-08-31 08:04 -0500
                Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-31 10:26 -0400
                Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked nmm1@cam.ac.uk - 2011-08-31 18:58 +0100
              Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked nmm1@cam.ac.uk - 2011-08-30 14:58 +0100
              Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-31 10:25 +0200
                Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-31 10:01 -0400
                Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-31 12:15 -0400
    Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-29 08:59 -0700

csiph-web