Re: X.509 and ssh

Dimitri Maziuk <dima@xxxxxxxxx> writes:
Add DS record (like MX, for ldap directory server) to DNS. Include
host keys in host's ldap record.

We could do SPF the same way, too.

The problems here are opening ldap server to the world, replacing
verisign with ldap server's administrator, standardizing use of
encryption which may be illegal in some jurisdictions, etfc.
Never gonna happen.

you don't need to do encryption ... all you need to do is public key
and digital signature as part of authentication.

one of the issues when working x9.59 financial standard (aka the x9a10
working group was given the requirement to preserve the integrity of
the financial infrastructure for all retail payment transactions) was
being able to do simple authentication w/o requiring encryption and/or
other heavy duty operations.
http://www.garlic.com/~lynn/x959.html#x959

this resulted in simple digital signature on a retail payment
transactions ... and the signing entity having a public key on file
with their financial infrastructure.

one of the other issues has been a major exploit of retail payment
transactions is skimming the account number and using it in fraudulent
transactions (and all the references to data breaches and account
fraud, being able to do fraudulent transactions with harvested account
numbers)
http://www.garlic.com/~lynn/subpubkey.html#fraud

so the other part of x9.59 was a business rule that account numbers
used in x9.59 transactions were not valid in non-authenticated
transactions. this is the issue that account numbers are used in large
number of business processes (besides the basic transaciton) and
even if you were to bury the world under miles of encryption ..
you still couldn't eliminate account number leakage ... slightly
related post on security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

in the x9.59 scenario ... you is possible for the related account
numbers to leak all over the place ... and crooks still can't use them
in fraudulent financial transactions (that haven't been digitally
signed with the correct private key).

so some of the historical lore is that the original x.500 dap was
suppose to have lots of individual personal information. however,
having enormous amounts of personal information in one place and
publicly available is an enormous privacy issue. so along comes x.509
identity certificate ... that also can contain enormous amounts of
personal information ... but at least they aren't all located in one
place. however, by the mid-90s, you started finding institutions
realizing that even x.509 identity certificates with enormous amounts
of personal information were also a significiant privacy threat.
so you saw some retrenchment to "relying-party-only" certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

which basically only contained some type of account number and a
public key ... where all the personal information was kept by the
institution in the account record ... and not generally available.
however, it is trivial to demonstrated that such relying-party-only
certificates are redundant and superfluous ... if you ahve to access
the account record (which might only contains trivial amounts of
personal information ... like a userid's permissions or some such
thing).

the issue in domain name infrastructure ... is that it already
provides a mapping between a domain name and an ip-address ... and
that it provides real-time access and distribution of the same
information. including the public key along with the ip-address
doesn't increase the exposure. the domain name infrastructure has gone
thru a spate where the registered email addresses were being harvested
for spamming purposes ... and eventually got redacted (there also has
been some recent news articles that possible 1/3rd of information on
file with at the domain name infrastructure is incorrect ... possibly
increase the vulnerability to domain name hijacking).

publishing public keys isn't any more of a threat than blanketing the
world under digital certificates with the same public keys. it
isn't as if public keys are shared-secret authentication
http://www.garlic.com/~lynn/subpubkey.html#secret

where the same value is used for origination and authentication
(i.e. divulging a shared secret creates threat of impersonation).
public keys are purely used for authentication and aren't designed to
be useable for origination and impersonation.

recent posting on related aspects
http://www.garlic.com/~lynn/aadsm22.htm#17 Major Browsers and CAS announce balkenisation of Internet Security

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

Relevant Pages

  • Re: Freeze.Panes revisited
    ... account with your business name on it. ... She then deposits whatever she wants ... you have to personally initial their time sheets for every "in" ... > not had time to make copies of the keys for them yet. ...
    (sci.med.dentistry)
  • RE: Is SSH worth it??
    ... > Subject: RES: Is SSH worth it?? ... user account, I don't see where they would. ... how is having the text of your password stored in the Expect script ... better than having keys? ...
    (Security-Basics)
  • Re: win2003 File Server in a Workgroup -- User Access
    ... Run gpedit.msc again and take a look at the following keys: ... Also check the permissions that you set on your shared folders (give ... you can try using the guest account. ... a Win2003 File server SP1, ...
    (microsoft.public.windows.server.networking)
  • Re: cant install a new I.E
    ... >> removing the problem account, and checking the runonce keys? ... > As far as checking the renounce keys.. ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • [NEWS] A Cryptanalysis of the High-bandwidth Digital Content Protection System
    ... A Cryptanalysis of the High-bandwidth Digital Content Protection System ... preventing access to plaintext video data sent over Digital Visual ... The linked article will show that with the public and private keys from 40 ... * Clone any device with only their public key ...
    (Securiteam)