X.509 and ssh - Page 3

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Re: X.509 and ssh

Richard E. Silverman sez:
Quoted text here. Click to load it

Well... it's in my other post, but in reality DNS as it is works for
large number of users. DNSSEC implementation can be orthogonal to
the above, it's things like political quagmire that really kill
such proposals.

As far as the chain of trust goes, if you've paranoid security
requrements you'll probably want to obtain the key out of band,
directly from the issuer, regardless of how many digital
signatures there are on somebody's DNS, LDAP, SSH, etc. servers.

OTGH, it is not clear what one would hope to achieve by hijacking
someone else's ssh server -- about the only thing they can get is
some poor shmuck's username and password, and said poor shmuck
will probably immediately contact the admin of the real server
when he finds out his password no longer works.

In reality, the amount of work required to set it up is way
beyond the average skript kiddie's ablility and the return
is uncertain at best. A professional will probably find an
easier way in while a skript kiddie will stick to the worms
-- IOW, the situation we already have.

The speed at which a mistyped command executes is directly proportional
to the amount of damage done.                                       -- Joe Zeff

Re: X.509 and ssh

Quoted text here. Click to load it

issuer? is that issuer of digital certificate? or issuer of
public key? or issuer of something else?

nominally somebody is the key owner ... except in scenarios like key
recovery ... where an institution issues both the private and public
key to the individual.

there is the authoritative agency for some piece of information ...
like the domain name infrastructure is the authoritative agency
for domain name ownership.

certification authorities ... typically are business processes that
certify some information ... for situation where the relying parties
don't directly have the information themselves and lack any means of
directly contacting any authoritative agency responsible for the

finally, certification authorities might manufacture certificates ...
as a representation of the certification business process. this is for
environments where the relying parties are dependent on the
certification process (as in above where they don't directly have the
information themselves and/or have access to the authoritative agency
responsible for the information). this certificate/license/credential
paradigm has served the offline world for centuries. however, the
certificate/license/credential paradigm is rapidly becoming obsolete
as the world moves to online ... and relying parties are given direct
access to the authoritative agencies responsible for the information
and/or direct access to certification authorities.

some of the certificate/license/credential operations have attempted
to find market niches in no-value operations ... where the
infrastructure can't justify the expense of direct online operations
for relying parties. however, even this, no-value market niche is
rapidly shrinking as the cost of performing online operations rapidly

one of the situations is that the domain name infrastructure is the
authoritative agency for domain name ownership and relying parties are
all, already doing online operations with the domain name
infrastructure (it would be straight-forward to piggy-back additional
information along with the current online information flow).

part of the issue that somewhat obfuscates the fact that the trust
root for SSL domain name digital certificates is the domain name
infrastructure is some of the misdirection about any cryptographic
integrity of the digital certificates ... which is almost a minor nit
in the overall end-to-end business operations of the authoritative
agencies (aka domain name infrastructure) maintaining correct and
accurate information ... and the certification business operations
performed by certification authorities ... independent of the actual
manufacture of the actual digital certificates.

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

Re: X.509 and ssh

Anne & Lynn Wheeler sez:
Quoted text here. Click to load it

Doesn't matter whether it's a digital certificate, public key,
or a good old unix password. If you don't trust transmission
channels and you don't trust third parties you go personally
visit the guy and write it -- whatever it is -- down on a piece
of paper (to make sure the medium is virus-free). "Elements"
cigarette paper -- it burns leaving virtually no ash for CSIs
to recover.
See also "paranoid".

The most horrifying thing about Unix is that, no matter how many times you hit
yourself over the head with it, you never quite manage to lose consciousness.
It just goes on and on.                                  -- Patrick Sobalvarro

Re: X.509 and ssh

Quoted text here. Click to load it
I would like to use it the other way around. All users presenting a X.509
certificate issued by a trusted party can access the server. Then I only
need to install the root certificate of the trusted party on the server and
the user management  doesn't need to be done on that server but can be done


Re: X.509 and ssh

Quoted text here. Click to load it

but do you also need to install userid and/or any user specific
permissions on the server?

can any certificate from any trusted party be used to access the
server ... or can only specific entities with specific kind of
certificates from specific trusted parties be allowed to access the

i've frequently asserted that the stale, static certificates are
redundant and superfluous if

1) the server has to have some sort of table or repository for allowed
users ... i.e. for instance out of all possible entities getting
certificates from some set of trusted parties ... which specific
parties are actually allowed to access the system and/or possibly
which permissions are allowed specific parties. this is kerberos type
protocol (also used in windows platforms). one of the counter
scenarios is that anybody with a certificate issued by an allowed
trusted party can have access to your system (regardless of who they
are). of course, then you may have a table of just those entities that
can have access to your system; however, it you have table of which
specific entities ... and potentially their permissions, then the
certificates are again redundant and superfluous).

2) the server can have access to the same table or repository
maintained by the trusted party (since typically a trusted party
issuing certificates needs some sort of table or repository that
provide some information about the entities for which they are issuing
certificates). on trivial example of this is the RADIUS protocol
originally developed for giving modem server/concentrators (router
type devices) access to the repository of entities, the associated
authentication, allowed permissions, and possible accounting
information (authentication, authorization, accounting).

the trivial scenario for certificates is where you don't care about
distinquishing between individuals ... that you treat all individuals
exactly alike, don't actually need to know who they are ... and just
need to know that they are member of the set of allowed individuals
(this is the offline physical door badge access system) ... and that
are only dealing with a specific trusted party that will only be
issuing certifcates for the set of your allowed individuals.

the original offline door badge systems were only a slight step up
from the physical keying (i.e. the badges and the keys both
represented "something you have" authentication as well as the means
of permissions/authborizations ... aka access). however, these early
badges, while somewhat harder to counterfeit than physical keys
... still provided no individual differentiation.

in nearly the same time-frame as permissions were starting to be added
to badges (allowing different badges to have potentially unique door
access permissions), online systems door badge systems were also
appearing. the value infrastructures fairly quickly migrated to online
operation ... the badge was solely "something you have" autnetication
... and specific entity permissions (for specific door access)
migrated to online information (rather being implicit in the badge).
misc. past posts regarding 3-factor authentication

the offline badge systems quickly become relegated to no-value
infrastructures (as value infrastructures migrated to online badge
systems that were rapidly decreasing in costs).

the x.509 identity certificates somewhat saw the resurgance in the
offline door badge acces paradigm from this earlier era (for no value
operations).  you also saw some organizations pushing x.509v3
extensions for encoding permissions ... as a return to the brief
period where door access permissions were encoded in the badge before
the advent of online access systems took over for infrastructures with
value operations (and the badge become purely authentication and all
permissions and authorization characterists were encoded separately in
online infrastructures).

this is the scenario where certificates become redundant and
superfluous for operations of value. the ability to generate a digital
signature implies the possesion of the corresponding private key (as
"something you have" authentication). the verification of the digital
signature is done with a public key stored with the permissions and
authorizations for the entity.

misc past posts characterizing public key systems as "something you
have" authentication ... aka an entity uniquely possesess a specific
private key
http://www.garlic.com/~lynn/aadsm18.htm#23 public-key: the wrong model for email?
http://www.garlic.com/~lynn/aadsm22.htm#5 long-term GPG signing key
http://www.garlic.com/~lynn/2000f.html#14 Why trust root CAs ?
http://www.garlic.com/~lynn/2005g.html#0 What is a Certificate?
http://www.garlic.com/~lynn/2005i.html#26 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#36 Improving Authentication on the
http://www.garlic.com/~lynn/2005j.html#0 private key encryption - doubts
http://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS
http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL
being used
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without
their private keys)
http://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for
CISSP exam ?
http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
http://www.garlic.com/~lynn/2005m.html#27 how do i encrypt outgoing email
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005m.html#45 Digital ID
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline
http://www.garlic.com/~lynn/2005n.html#39 Uploading to Asimov
http://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for offline
http://www.garlic.com/~lynn/2005o.html#9 Need a HOW TO create a client
certificate for partner access
http://www.garlic.com/~lynn/2005o.html#17 Smart Cards?
http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be
forced to sign a document etc - Tax Declaration etc etc etc
http://www.garlic.com/~lynn/2005p.html#32 PKI Certificate question
http://www.garlic.com/~lynn/2005p.html#33 Digital Singatures question
http://www.garlic.com/~lynn/2005q.html#13 IPSEC with non-domain Server
http://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance
http://www.garlic.com/~lynn/2005s.html#42 feasibility of certificate based login
(PKI) w/o real smart card
http://www.garlic.com/~lynn/2005s.html#43 P2P Authentication
http://www.garlic.com/~lynn/2005t.html#32 RSA SecurID product
http://www.garlic.com/~lynn/2005v.html#5 famous literature

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

Re: X.509 and ssh

Quoted text here. Click to load it

Then all you need to do is arrange the small matter of managing a PKI
alongside SSH.

Somehow I think this isn't going in the right direction :-).


Re: X.509 and ssh

Peter Gutmann wrote:
Quoted text here. Click to load it

I couldn't help but come across this cynical naysayer (habitual at that,
reading through prior posts).

"all you need to do is arrange the small matter of managing a PKI
Quoted text here. Click to load it

As if to say its complicated? Surely, it is, if you don't understand or
study it -- like anything else.

As a matter of fact, creating your own CA can be as simple as a few
openssl commands, or combining them into a couple scripts (one to create
the CA, another to sign certs), and answering the identification
questions (even that can be automated). One can issue certificates, or
sign reqs in mere seconds.

With a large set of machines, this SURE beats random public keys by
themselves (which are far, far, FAR more difficult to keep track of)
when in you are inside of a large organization or computers or otherwise
have a large number of client machines to administer (image a world
where https site used only byte/hex string keys). The only time the
contemporary PKI public key byte/hex string is overall
easier to use (verify communications) -- is when one only has a few
machines that need to communicate with each other -- unless some (always
risky and poor-scalability) trusted-keys replication is used.

Moreover, x509 certs (and constructed CAs) instantly lend themselves to
a whole host of other secure AND trust applications, https, ldaps,
smtps, ftps, imaps (to name a few), mail signing / encryption, software
signing. When you extend their reach out to all these other forms of
communication, and used by computer laymen, old-fashioned random public
key strings is simply not at all feasibile.

Anyone who claims that that x509 is disadvantaged compared to plain PKI,
is simply demonstrating that they have no practical or level experience
with BOTH technologies. That really shows like sore thumb to those of us
who do have both exeriences.

The inability to present a balanced view of two arguments is highly
detrimental only to ones own credibility, especially when combined with
one-sided cynicism and hyperbole where they are trying to persuade
undecided minds into adopting their beliefs.

People aren't truly persuaded by another other single persons opinion -
they are are much more persuaded by practical experience.

Re: X.509 and ssh

My deepest, deepest apologies, I misquoted the wrong text and person.
This was not meant to be directed toward Peter or anyone specifically on
this thread.

Quoted text here. Click to load it

Re: X.509 and ssh

Ken Johanson sez:
Quoted text here. Click to load it

That tends to work well when you're your own sysadmin. When you're
connecting to swervers fubared by other people, it's a different

(I'd rather use a self-signed cert than copy authorized_keys all
over the place every time, myself, but it's my network and I know
what I'm doing.)

Q276304 - Error Message: Your Password Must Be at Least 18770 Characters
and Cannot Repeat Any of Your Previous 30689 Passwords           -- RISKS 21.37

Re: X.509 and ssh

Quoted text here. Click to load it

one of the issues from x.509 identity certificates from the early 90s
was the eventual realization that certificates potentially grossly
overloaded with personal information represented significant privacy
and liability issues.

as a result, in the mid-90s you saw the introduction of
relying-party-only certificates ...

where the only unique information in the certificate was some sort of
account number (that could be used to index a respository where the
actual entity information resided, including the original issued
public key information, along with that public key) and a public key.

an entity created some sort of message or transaction, digitally
signed the transaction and appended the RPO-certificate. It was
trivial to show for these scenarios that the appended certificate was
redundant and superfluous.

I got a lot of flack in the mid-90s for demonstrating that appending
such certificate was redundant and superfluous. The conventional
wisdom at the time was that appendidng certificates was required for
everything and if you voiced any sort of opposing view, you were a
heretic doing the work of the devil. One of the lines was about
appending certificates to retail payment transactions would bring the
business process into the modern era. My counter-argument was that the
purpose of appending certificates to payment transactions was to
provide sufficient information for offline authorization ... and, as
such was actually a return to the 50s era, predating online

This is the business process analysis of appended certificates
following the offline credential model or the letters of
introduction/credit from the sailing ship days (dating back at least
several centuries). The credential/certificate paradigm is useful in
offline scenarios where the relying party.

1) doesn't have their own information about the other party

2) doesn't have any online access to trusted authorities for
information about the other party

3) must rely on prepackaged, stale, static credential/certificate
about the other party rather than having online access to realtime

when we were called in to work with small client/server startup
that wanted to do payments on their server and had this technology
called SSL ...

we had to work out the business process details of using SSL
technology for payments ... as well as doing walkthru audits of these
emerging operations calling themselves certification authorities.

for the original payment gateway, for using SSL between the server and
the payment gateway (for payment transactions), one of the first
things we had to do was specify something called mutual authentication
(which hadn't yet been created for SSL). However, as we flushed out
the business process of servers interacting with the payment gateway,
we were keeping tables of authorized merchants and the gateway and
gateway specificate information loaded at each merchant. By the time
we were done with the process, it was evident that any certificate use
was also totally redundent and superfluous (purely a side-effect of
using the crypto function that were part of the SSL library).

The payment gateway had registered information (including public keys)
of all authorized merchants and all authorized merchants had
configuration information regarding the payment gateway (including its
public key). There was absolutely no incremental business process
advantage of appending digital certificates to any of the

The other part of stale, static, redundant and superfluous
certificates, at least related to payment transactions was that a
typical retail payment transaction is on the order of 60-80 bytes.
The RPO-certificate overhead from the mid-90s was on the order of
4k-12k bytes (i.e. appending stale, static, redundant and superfluous
digital certificates to payment transaction was causing a two orders
of magnitude payload bloat).  Somewhat as a result, there was an
effort started in the financial standards organization for
"compressed" digital certificates ... with a goal of reducing the
4k-12k byte overhead down into the 300 byte range. Part of their
effort was looking at eliminating all non-unique information from a
RPO-certificate issued by a financial institution (CPS, misc.  other
stuff). I raised the issue that a perfectly valid compression
technique was to eliminate all information already in possesion of the
relying party. Since I could show that the relying party already had
all possible information in the digital certificate, it was possible
to reduce the digital certificates. Rather than claiming it was
redundant and superfluous to attack stale, static digital certificates
to a transaction, it was possible to show that it was possible to
attach zero-byte digital certificates to every transaction (for a
significant reduction in the enormous payload bloat caused by digital

Another model for certificates ... with respect to thhe emulation of
credential/certificates in the offline world (where the relying party
had no other mechanism for establishing information in first time
communcation with total stranger), was the offline email model from
the early 80s. The relying party would dialup their local (electronic)
post office, exchange email, and hangup. They potentially then had to
deal with frist time email from a total stranger and no way of
establishing any information about the sender.

During the early establishment of electronic commerce, I had frequent
opportunity in exchanges to refer to the merchant digital certificates
as comfort certificates.

Stale, static digital certificates are a tangible representation of a
certification business process. In the offline world, certificates and
credentials were used as a representation of such certification
business processes for the relying parties who had no direct access or
knowledge regarding the original certification process. These stale,
static certificates and credentials provided a sense of comfort to the
relying parties that some certification process had actually occured.

One of the things that appears to have happened with regard to
physical certificates and credentials ... is that they seemed to have
taken on some mystical properties totally independent of the
certification process that they were created to represent. The
existance of a certificate or credential no convey mystical comfort
... even though they purely are required for representation of the
certification process ... for relying parties that have no other means
of acquiring information about the certification process.

Another example of such credentials/certificates taking on mystical
comfort properties are the diploma mills ... where the pieces of
parchment produced by diploma mills seem to take on attributes totally
independent of any educational attainment that the parchment is
suppose to represent.

An issue, is that in transition to online paradigm, it is possible for
relying parties to have direct online real-time access to the
certified information ... making having to rely on the stale, static
representations of credentials and certificates, redundant and

However, there is an enormous paradigm change from an offline-based
paradigm ... when the majority of people may still draw great comfort
from artificial constructs that emulate the offline
credential/certificate paradigm ... to an online-based paradigm
dealing with realtime information and realtime business processes.

One of the big PKI marketing issues has been "trust". However, the
actual trust has to be in the certification process ... where any
certificate is purely a stale, static representation of that
certification process for use by relying parties that have no other
means of directly accessing the information.

As the world has migrated to more and more online ... that is somewhat
pushing the X.509 and PKI operations into market segments that have no
online mechanisms and/or can't justify the costs associated with
online operation. However, as online becomes more and more ubiquitous
and online costs continue to decline, that market segment for x.509
and PKI operations is rapidly shrinking (needing stale static
certificates as representation of some certification process for
relying parties that otherwise don't have direct access to the
information). Also part of the problem of moving into the no-value
market segment, is that it becomes difficult to justify any revenue
flow as part of doing no-value operations.

a slightly related commented on some of the PKI operations attempting
to misuse constructs with very specific meaning

slightly related set of posts on having worked on word smithing both
the cal. state and federal electronic signature legislation

a collection of earlier posts in this thread:
http://www.garlic.com/~lynn/2006b.html#37 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#12 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#13 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#16 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#37 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#39 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#13 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#14 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#16 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#17 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#18 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#27 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#29 X.509 and ssh

misc. past posts mentioning the enormous benefits of zero byte
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs
XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs
XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about
Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security
http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to
broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and
http://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud - Case #3 -

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

Re: X.509 and ssh

Anne & Lynn Wheeler wrote:
Quoted text here. Click to load it

"potentially" seem really vague to me the way you use it. The fact is,
very few fields are actually required by CAs -- and the ones that are
required are the ones needed to establish the identity being claimed
(given name, location, email) (to distinguish one John Doe from
another), and also the endorser cert / chain.

Put simply, these 'superfluous' (as you claim) fields are nothing, if
not essential. As essential, as the information you see on another
person's drivers license or passport -- including the endorser's own
(should-be) hard-to-duplicate insignia (which btw is far easier to
duplicate than x509 endorsements)). As essential, as the ID present when
you conduct an in-person transaction, or get aboard an airplane.

Do you disagree with this simple premise, that certain minimum
fields/data are *completely* essential to establish ID and trust? Or can
I just write you a check for $100 and claim that a1b2c3d4 is my real
public key / authentication code??

Quoted text here. Click to load it
And they fit a very real world need. Delegated/subordinate signing
authority are fully necessary for scalability reasons. Imagine having to
go to your country's capital to get a passport.

Quoted text here. Click to load it

But redundant to what? Are you claiming that for each secure message
that needs to be verified, some traceability (either by session or
certificate presentation) is NOT needed??

Let me write you 100 $100 checks... will you cash them all and hands me
the goods based on my self-generated, unvouched public key? Really?

Quoted text here. Click to load it

I might believe you, given a concrete example.

  One of the lines was about
Quoted text here. Click to load it

You are implying that a cert must be attached for message. That is not
true. SSL establishes sessions, where in the cert / keys are exchanged
only at the beginning of the session. There is no "KB's worth of
superfluous bytes" as you claim below, and certainly none of those are
wasted in the case where identity must be assured.

Quoted text here. Click to load it

And it is now. In fact its been available for many years ago, and
happens to be used heavily in finance and government and military
comms.. But you continually recite these antiquated use scenarios
instead of something current (I imagine because you wouldn't have a
sustainable argument against it anymore, or just because you have not
been recently hired to 'audits' or 'consulting')

However, as we flushed out
Quoted text here. Click to load it

A daunting - in fact impossible task in the modern world where financial
and other institutions have hundreds or thousands of third parties to
deal with. In fact this is a shining example of the value of the x509
signing model. In the same way that we need appointed govt officials to
verify and issue (certify) personal *and* businesses identification.

I think you just disproved your own point by mentioning the existence of
a registry at each company. Anyone who has truly implemented that model
on a large scale has become painfully aware of the scalability and
security problems (decide when to add and revoke compromised keys and
how validate new ones when the issuer's old one is compromised)

  There was absolutely no incremental business process
Quoted text here. Click to load it

Your keyword "was" is interesting. Tell me if you think that holds true
*today*, with SSL/TLS. You *can* answer this just with a simple yes or no.

   Somewhat as a result, there was an
Quoted text here. Click to load it

So many uses of the word "was"...

Anne and/or Lynn have recited so many perceived "drawbacks" to x509 in
general, even in light of their usage in just about every modern
security / identity communication system of late. But what
*constructive* suggestions to improve the supposed deficiencies, have
they offered? What specific technology are they claiming is a
good/better replacement (some patent-pending technology of theirs
perhaps?)? And why do they so repeatedly recite "used to be"
limitations, but not also mention (or show awareness of) the current
state of the art fully address those?

Re: X.509 and ssh

Quoted text here. Click to load it

http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh

the issue in the early 90s with x.509 identity certificate standard
... appeared to be that personal information in a certificate seemed
to be a valuable business niche for certificates ... and some of the
emerging things called certification authorities ...  which were out
to sell these x.509 identity certificates started down the road that
the more personal information included, the greater the value of the
certificate (and the implication that they could charge more).

that trend somewhat created the realization in a number of
institutions, that certificates, grossly overeloaded with personal
information, gave rise to significant privacy and liability issues
... and contributed to the appearance of the relying-party-only
certificates in the mid-90s.

the original x.509 identity certificate paradigm seem to assume a
total anarchy where the x.509 identity certificate would be used for
initial introduction (like the letters of credit/introduction example)
between totally random strangers. as such, the respective entities as
individual relying parties, had no prior information about the other
party. In such a wide-open environment, it seemed necessary to pack as
much information as possible into the certificate.

however, the retrenchment to the relying-party-only model, placed all
the actual entity information in a repository someplace with just an
account number for indexing an entity's repository entry. however, it
was then trivial to demonstrate that attaching relying-party-only
digital certificates to signed operations (sent off to the relying
party) was redundant and superfluous .. since the relying party would
have access to all the requiered information and didn't require a
digital certificate to represent that information.

the other approach was to trivially demonstrate that there was no
information in such certificates that wasn't also contained in the
corresponding repository certified entry. in which case, if it could
be shown that the relying party had access to the repository certified
entry, then it was trivially possible to eliminate all fields in the
certificate resulting in a zero-byte digital certificate ... which
could be freely attached to everything.

in any case, the trivial case of a relying-party-only certificate is
where the institution that is acting as the relying party is also the
institution responsible for certifying the information and issuing a
digital certificate (representing that certifying process).

in an online environment ... replying-party-only model was extended,
so that if the information could be accessed by other parties (that
weren't directly responsible for the certification and issuing a
digital certificate, representing such certification) using purely
online realtime transactions, then the use of stale, static
certificate as a representation of some certified information (in some
repository) becomes redundant and superfluous (when the entities have
direct and/or online, realtime access to the original information).

the shrinking market for the offline credential/certificate market
(and any electronic analogs) is market segment where it isn't possible
to have online access to the real information and/or the value of the
operation can't justify (the rapidly declining) online access costs
(aka certificate moving further and further into the no-value market

part of this is the comfort that people have in the (physical) offline
credential/certificate model ... being accostomed to working in an
online environment ... and therefor not having direct, realtime access
to the actual information. The physical offline credential/certificate
provides them with a sense of comfort regarding some certification
process as actually having taken place (and which they have no means
of directly validating). They then have achieve similar comfort to
find an electronic certificate analog to these offline
credential/certificate constructs. However, it is normally trivial to
show that realtime, online direct access to the certified information
is at least as valuable ... and frequently significantly more valuable
than relying on a stale, static digital certificate (modulo the
scenario for which credentials/certificates were originally invented,
the place where the relying can't access the real information).

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

Re: X.509 and ssh

If you can't answer to (but only delete and ignore) the obvious
questions that were posed to you, then there is no conversation to he had.

And you are *still* referring to what was, instead of now, and
distorting things merely to support your side (statements like "grossly
overloaded" and "was redundant and superfluous" (again without an
example) which are as much balderdash as saying that your drivers
licensee being overloaded just because it makes you accountable and
traceable to everyday people you may encounter).

If you don't like it, then don't use certs. For now, they're optional --
(unlike your drivers license)... even though they are far and away and
growing as the most used system for secure internet protocols, whether
issued by the CAs that you despise, or by your own personal CA.

Quoted text here. Click to load it

Re: X.509 and ssh

Ken Johanson wrote:
Quoted text here. Click to load it

http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#31 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#34 X.509 and ssh

so the stale, static, offline credential, certificate, license, diploma,
letters of credit, letters of introduction methodology have served a
useful business requirement in the physical world for centuries, namely
providing a mechanism to represent some information to relying parties
who have had no other mechanisms for accessing the actual information.

digital certificates are just electronic analogs of their physical world
counterparts, meeting the same business requirements ... namely
providing a mechanism to represent some information to relying parties
who have had no other mechanisms for accessing the actual information.

so in the mid-90s there were efforts looking at chip-based, digital
certificate-based driver's licenses ... as a higher valued
implementation for better trust and operation.

however, it ran into some of the similar retrenchments that faced x.509
identity certificates ... even the physical drivers license contain
unnecessary privacy information ... like date-of-birth, creating
identity theft vulnerabilities.

the other value proposition justification was that high value business
processes .... like interaction with police officers supposedly could be
better trusted using the higher value and higher integrity chip-based
driver licenses incorporating digital certificate technology.

however, police officers at that time were already in transition to much
higher value online transactions. rather than simply relying on the
information in a driver's license ... the driver's license simply
provided an index into the online repository ... and the police officer
used it to do realtime, online accesses the online respository,
retrieving realtime information for authenticating and other wise
validating the entity they were supposedly dealing with. Any information
(other then simple repository lookup value) in the drivers license,
became redundant and superfluous.

All the higher value driver license related operations, were moving to
online, realtime operation ... leaving any information content
requirements for driver licenses to no-value operations that couldn't
justify an online operation.

If you are faced with a situation where the driver license has very
defined use (say a trivial barcode to index a repository that contains
your complete history and numerous biometric mechanisms for validating
who you area) ... then any additional feature of a drivers license for
use in no-value operations ... needs to be financially justified by the
no-value operations (since they are redundant and superfluous for all
the higher value business processes that can justify doing realtime
online operations).

The online characteristic can also be used to help address some of the
existing identity theft vulnerabilities related to driver's license. For
instance, an individual can authorize ... in a manner similar to how
they might digitally sign an x9.59 transaction

... a transaction that answers yes/no to whether they are at least 21
years old. the actual birth-date never has to be divulged ... the
certification authority just responds yes/no in a manner similar to how
certification authorities response approved/declined to existing
realtime, online financial transactions.

This is sort of the set "FAST" transaction proposals by FSTC
http://www.fstc.org /

that could even ride the same 8583 rails as existing financial
transactions ... but in a manner similar to answer yes/no to financial
transactions (w/o disclosing things like current account balance or
transaction history) ... could answer yes/no to other kinds of

some other past posts mentioning the digital certificate model for
drivers licenses from the mid-90s ... and why it sort of evaporated.
http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy
http://www.garlic.com/~lynn/aepay2.htm#position AADS NWI and XML encoded
X9.59 NWI
http://www.garlic.com/~lynn/aepay4.htm#comcert5 Merchant Comfort
http://www.garlic.com/~lynn/aepay6.htm#itheft "Gurard against Identity
Theft" (arrived in the post today)
http://www.garlic.com/~lynn/aepay12.htm#3 Confusing business process,
payment, authentication and identification

http://www.garlic.com/~lynn/aadsm5.htm#ocrp3 Online Certificate
Revocation Protocol
http://www.garlic.com/~lynn/aadsm7.htm#idcard AGAINST ID CARDS
http://www.garlic.com/~lynn/aadsmail.htm#liability AADS & X9.59
performance and algorithm key sizes
http://www.garlic.com/~lynn/aadsm11.htm#37 ALARMED ... Only Mostly Dead
http://www.garlic.com/~lynn/aadsm11.htm#38 ALARMED ... Only Mostly Dead
... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#4 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#5 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm14.htm#13 A Trial Balloon to Ban Email?
http://www.garlic.com/~lynn/aadsm15.htm#1 invoicing with PKI
http://www.garlic.com/~lynn/aadsm17.htm#47 authentication and
authorization ... addenda
http://www.garlic.com/~lynn/aadsm19.htm#48 Why Blockbuster looks at your ID
http://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet
security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on
high-assurance certificates
http://www.garlic.com/~lynn/2001.html#62 California DMV
http://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001k.html#6 Is VeriSign lying???
http://www.garlic.com/~lynn/2001l.html#29 voice encryption box (STU-III
for the masses)
http://www.garlic.com/~lynn/2001n.html#56 Certificate Authentication
Issues in IE and Verisign
http://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002n.html#40 Help! Good protocol for
national ID card?
http://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all
equally secure?
http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs',
how curruptable are they to
http://www.garlic.com/~lynn/2003m.html#21 Drivers License required for
http://www.garlic.com/~lynn/2004i.html#4 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005i.html#33 Improving Authentication on
the Internet
http://www.garlic.com/~lynn/2005l.html#32 More Phishing scams, still no
SSL being used
http://www.garlic.com/~lynn/2005t.html#6 phishing web sites using
self-signed certs
http://www.garlic.com/~lynn/2005u.html#37 Mainframe Applications and
Records Keeping?
http://www.garlic.com/~lynn/2006.html#37 The new High Assurance SSL

Re: X.509 and ssh

Anne & Lynn Wheeler wrote:
Quoted text here. Click to load it

These descriptions certainly implies that x509 certs are "stale, static,
offline credential", again your presentation would lead readers to
believe that (and interpret "stale" as derogatory and diminished value)
this is all the are. In fact, and as you know (but do not present in
balance, on the same sentence, (eg "The static/offline and not live
portion of the certificates"), certs *can* be checked for their validity
during session initiation or periodically, using CRL and OCSP protocols.

This too is a contrast to the (arguable much more stale/static) simple
PKI systems that store trusted keys locally, but have no way to check
some authority to know if those keys were compromised. Again your broke
your own line of argument, where you claim that local "registries" of
trusted key are adequate and state that certificate data (which contains
essential revocation/OCSP URLs) are merely superfluous.

Quoted text here. Click to load it

Is this the only example you can provide, because it's clearly wrong...
Your DOB is *essential* because an entire array of public service
require knowledge/verification of your DOB before you are eligible for
services (over-18 and over-21 activities in the US, and senior citizen
eligibility for services, to name just a few) -- and also because your
DOB helps distinguish one Lynn Wheeler from another.

x509 and personal IDs have not been used because of cost and because of
administrative concerns by govt, and because of portion of the
population believes then should be anonymous and un-trackable of they so

However this tide is changing - even with proposals to leave those
people in an optional state, other will choose to use digital ID system
because they make *guarantees* against ID theft that paper, passports,
certificates and drivers licenses cannot (including but not limited to
mere photo-copy duplication). Give the choice, I certainly would pick
the digital certificate with 2 factor authentication, compared to
paper/plastic photo ID and payment cards. The paranoid will not, so be
it (they lament having to be registered/traceable with govt but expect
to drive motor vehicles too).

Quoted text here. Click to load it
This is correct.

Quoted text here. Click to load it

You fail to see the point, the non-digital ID can be forged. This is
*diminished* value. I can masquerade as Lynn Wheeler using my fake ID,
and run red lights at your expense. This happens NOW.

and the police officer
Quoted text here. Click to load it

What you're really trying to propone (apparently) is that and single
user-id (drivers license #) is sufficient, without what you call
superfluous cert data (address, name, etc). Where this breaks down is if
the officer is offline, or the "registry" fails in any way. Central
registries also have complexity and scalability issues, especially when
they must convey all the detail (and not just revocation info) (vs
having all the static details contained inside the cert).

Again, using the trusty x509/SSL example, image if every SSL website
*required* contacting some registry(s) to get details of the company,
instead of conveying the relevant business details during SSL handshake
(eg inside the cert). The system would be both slower and more prone to
failure. And *yet* x509 does allow this to work if the com[pany and
client choose to have stricter requirements -- using meta URLs
referenced in the cert, and CRL/OCSP.

The REAL world example is when you buy something from someone, or when
you crash your car into someone else, and have to exchange
identification data. That person will not necessarily have access to the
registry service. Having all the essential ID data contained *inside*
the cert is purely necessary.

Would you buy something from someone of their ID papers contained *only*
their (supposed) ID #?? You would *not*.

Quoted text here. Click to load it

The identity theft vulnerabilities of paper and or digital ID system are
merely and artifact of modern day, primitive methods that credit cards
companies use to "authenticate" persons. Specifically, needing your DOB.
These artifacts will disappear with time (as vendors stop using them),
and, they need to access them with will NOT go away (using the very poor
DOB example you provided), because:

a) DOB is simply necessary for modern society
b) they will be registered in a non-permissive system anyway (they
already are)
c) the artifact DOB-type authenticators will stop being used (by law),
and those datums will become innocuous, as they should be. So DOB can be
used to validate your right to enter drink alcohol or gamble, etc, as it
should be and is now.

The permissive model you describe will ONLY be used/useful for things
that *require* permission, like financial transactions. But these datums
(bank account information) do not exist inside of x509 anyway -- only
essential and largely static *identification* data does (and limited at
that, i.e DOB is not required in a most certificates, unless you work
for certain high security agencies).

Put simply your proposing of a registry based system solve-all (where a
user IDs themselves by presenting ID# only) (where signed x509 cert data
is not needed) is flawed and fails by the same tokens you claim the x509
certs fail:

a) redundant over-the-wire transmission of static data when a local copy
can/should exist.
b) required equipment and connectivity to registry (and also *redundant*
registry trust/validation scheme (which x509/SSL already have solved))
c) requires all of the same semantics that x509 already provide for
integrity and authentication.

The permissive model you propose is *only* applicable to *permissive*
data (financial, etc). You're obviously implying that real word ID
information DOB specifically should permissive -- is false, or that
current x509 fields (which current does NOT include DOB) contains what
"should be" private data is false -- if you cause a car accident with
me, then I have complete and irrevocable rights to *positively* ID you
(name, address, DOB together uniquely ID a person in today
permanent-identifier*-less world) so that I can recoup damages (though
some privacy advocates would dispute this "right", they are the exception)

*What you have referred to as a user-id number (which links a person to
the registry) already exists as an RFE, an extended attribute in x509,
where the cert can record and carry your life-long unique identifier.
This too, is nothing less that essential. Again, if *nothing* else
existed in the cert except this permanentID (and all other data
including name had to be sent over the wire), then it *still* needs to
be signed by a trusted party for which I carry a trust store -- so that
I can validate your ID now (before you leave the scene of the wreck),
while I do not have access to the registry, and then get your details

So the x509 and signature system still serves and indisputable purpose,
and clearly having additional fields also in the cert, such as your
*static* name, is fully reasonable (to most people).

Re: X.509 and ssh

Ken Johanson wrote:
Quoted text here. Click to load it

http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#31 X.509 and ssh

this was the physical world scenario from the 50s ... by the 60s you
were starting to see (at least) business countermeasure to this scenario
in the offline market, where business checks had a maximum value limit
printed on the check (i.e. the check wasn't good if the individual wrote
it for the limit).

the embezzler countermeasure was to create a 100 checks for $100 each
... in order to get the $10,000 (or 200 checks of $5000 each for $1m).

the issue was trying to limited the authority of any one individual. an
individual might have a $1000 total budget ... but trying to control it
... they would provide the individual with checks, no one such check
could exceed $100. The actual problem was to try and keep the individual
within their budget. The problem with the offline model was that
individual, single (even authenticated) transactions didn't aggregate.

This is where you got the online credit card model in the 70s. The
consumer would do a transaction with the merchant ... and the merchant
would forward the transaction to the responsible (certifying authority)
institution for authentication and authorization. The merchant then got
back a declined or approved response ... indicating the transaction had
both been authenticated AND authorized (which was significantly more
valuable to the merchant than just authenticated by itself).

Because of the various vulnerabilities and exploits in the offline
credential/certificate model ... you saw businesses moving to online
business cards sometimes in the 80s ... but definitely by the 90s.
Instead of an individual being given a stack of checks, they were given
a corporate payment card. The corporate payment card had online business
rules associated with it for authorizing financial transactions (in
addition to authentication). The trivial business rule was whether the
transaction ran over the aggregated budget (i.e. the individual could do
any combination of transactions they wanted ... as long as they didn't
exceed some aggregated limit ... something that is impossible to do with
the offline, individual operation at a time, credential/certificate

One they got the aggregate budget/limit under control ... then they
could also add other kinds of real-time transaction rules ... use only
at specific categories of merchants, use only at specific set of
merchants, use only for specific SKU codes, etc) ... the online paradigm
not only provides the realtime aggregation function (not possible with
the old-fashion, offline certificate/credential paradigm) as well as a
variety of much more sophisticated rules (which can be dynamically
change by time or other characteristic).

What you have is the issuing financial institution as the registration
authority and certifying authority. The financial institution performs
the public key registration (typically defined as RA functions in the
traditional Certification Authority paradigm) and then certifies the
information. However, instead of actually issuing a certificate ... the
institution specifies that it is only in support of online, realtime
transactions (since there are numerous kinds of threats, exploits, and
vulnerabilities that have been eliminated that you typically run into
when you are dealing with an offline paradigm ... like inability to
handle aggregated transactions like the 100 $100 check scenario that
I've repeatedly used a number of times). The individual digitally signs
their individual transactions that is sent to the merchant ... as in the
x9.59 financial standard

it is not necessary to attach a digital certificate since it is required
that the merchant send it off to the financial institution
(certification authority) for both authentication (with the onfile
public key) as well as authorization (does it meet all the business
rules, including realtime business rule consideration). Since the
financial institution has the onfile, registered public key for
verifying the digital signature, it is redundant and superfluous to
require the attachment of any digital certificate (or at least any
attach digital certicate with non-zero payload actually carrying any
real information)

one of the requirements given the x9a10 working group for the x9.59
financial standard was to preserve the integrity of the financial
infrastructure for all retail payments.

A recent post about various kinds of financial transaction threats if
forced to fall-back to an offline, credential/certificate operation
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new
tenner (USD10)

a few misc. past posts showing crooks getting around any per check
business limit by going to multiple checks (as in your 100 $100 check
example) ... and the business world countering with real-time, online
aggregated transaction operation (making the offline
credential/certificate operation redundant and superfluous).
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
http://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop
http://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces
obstacles in PKI security adoption
http://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#240 Attacks on a PKI

http://www.garlic.com/~lynn/aadsm10.htm#limit Q: Where should do I put a
max amount in a X.509v3 certificat e?
http://www.garlic.com/~lynn/aadsm10.htm#limit2 Q: Where should do I put
a max amount in a X.509v3 certificate?
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead
... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead
... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm12.htm#20 draft-ietf-pkix-warranty-ext-01
http://www.garlic.com/~lynn/aadsm12.htm#31 The Bank-model  Was: Employee
Certificates - Security  Issues
http://www.garlic.com/~lynn/aadsm12.htm#32 Employee Certificates -
Security Issues
http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2001c.html#8 Server authentication
http://www.garlic.com/~lynn/2001g.html#21 Root certificates

Re: X.509 and ssh

Ken Johanson wrote:
Quoted text here. Click to load it

there tends to be a broad range of different applications. supposedly
one of the big drivers for certificate business in the mid-90s was in
conjunction with financial transactions. the example was a financial
transaction that is typically requiring 60-80 bytes ... and a large
contingent of the PKI industry behind appending certificates to such
transactions (as part of financial institutions paying $100 for digital
certificates for everybody in the country that might do a financial

it was possible to trivially show

1) that if the financial institution already had all the information,
then it was redundant and superfluous to attach a digital certificate to
such financial transactions

2) that the typical financial transaction was 60-80 bytes and the
payload overhead of having redundant and superfluous certificates was on
the order of 4k-12k bytes (representing a payload bloat of a two orders
of magnitude increase).

So in SSL, the overhead is theoritically front load for a session.
However, when we originally helping to patch together the actual
business process use of SSL

a lot of the SSL HTTP transactions were individual transactions (not KB

the original business justification for SSL digital certificates were
related to e-commerce ... and mentioned in the above references. The
process was that the merchant got their domain name in a certificate. As
part of the TCP/HTTP/SSL session setup, the person had typed in the
URL/domain name into the browser, the browser had contacted DNS to map
that domain name to IP-address, the browser contacted the webserver, the
webserver responded with certificate, the browser validated the
certificate and then check the typed in domain name against the domain
name in the certificate.

however, the majority of the merchants operating webservers discovered
that the SSL overhead increased overhead by a factor of five times
compared to running straight HTTP. As a result ... you saw almost all
merchants dropping back to using SSL for purely the payment/checkout
phase of electronic commerce. The problem is that the URL/domainname
that is typed in by the user is no longer checked against an SSL
certificate. What now happens is that the user clicks on a button
supplied by the webserver that generates the URL and domain name ...
which is then used to check against the domain name in the certificate
also supplied by the same webserver. The issue now is that the majority
of the ecommerce use in the world now violates fundamental kindergarten
security principles ... since the webserver provides both the URL and
the certificate that are checked against each other. It would take a
really dumb crook to not have a completely valid certificate that
corresponds to the domain that they provide in the button.

So the other issue was that HTTP (which SSL was a subset) had other
these truelly trivial transaction payloads ... and was using TCP
protocol for doing it. Now TCP has a minimum of seven packet exchange
for session setup (ignoring any added HTTP and/or additional SSL
overhead). One of the characteristics in these early days was that most
TCP implementations assumed few, long running sessions .... as opposed
to a very large number of extremely short transaction like operations.
One of the places that this appeared was in the linear list operation
supporting FINWAIT. There was a crises period as HTTP (& SSL) caught on
where numerous major webservers found that they were spending 99percent
of total cpu managing the FINWAIT list.

lots and lots of posts about SSL and certificates from the period

there is another issue somewhat involving the weak binding between
domain name and domain name owner. the issue is that many of the
certification authorities aren't the authoritative agency for the
(SSL domain name server certificate) information they are certifying.
much of the original justification for SSL related to mitm attacks was
various integrity issues in the domain name infrastructure.

the process tends to be that a domain name owner registers some amount
of identification information for their domain name ownership with the
domain name infrastructure. the certification authorities then require
that SSL domain name certificate applicants also provide some amount
of identification information. then the certification authorities
attempt to do the expensive, time-consuming, and error-prone process
of matching the supplied identification information for the SSL domain
name certificate with the identificaiton information on file with the
domain name infrastructure for the domain name.

as part of various integrity issues related to that process, there has
been a proposal, somewhat backed by the ssl domain name certification
authority industry that domain name owners also register a public key
with the domain name infrastructure (in addition to identificaiton
information). then future communcation can be digitally signed and
verified with the onfile public key. also the ssl domain name
certification authority industry can require that ssl domain name
certificate applications be digitally signed. then the certification
authority can replace the expensive, time-consuming, and error-prone
identification matching process with a much less-expensive and
efficient authentication process by doing a real-time retrieval of the
on-file publickey from the domain name infrastructure for verifying
the digital signature (in lieu of doing a real-time retrieval of the
on-file identificaiton information for the expensive, time-consuming
and error-prone identification matching).

the two catch22 issues here are

1) improving the overall integrity issues of the domain name
infrastructure lessons the original justification for ssl domain name

2) if the certification authority industry can rely on real-time
retrieval of publickeys from the domain name infrastructure as the
base, TRUST ROOT for all of their operations ... it is possible that
other people in the world might also be able to do real-time retrieval
of publickeys as a substitute to relying on SSL domain name

so there one could imagine a real transaction oriented SSL ... where the
browser takes the URL domain name and requests the domain name to
ip-address mapping. In the same transaction the domain name
infrastructure also piggybacks in the same transaction, any registered
public key for that webserver.

Now you can imagine that in the initial communication, the browser
includes the actual request, encrypted with a randomly generated secret
key, which is, in-turn encrypted with the onfile public key obtained
from the domain name infrastructure. This is all packaged in single
transmission set of to the webserver. If it becomes an issue, the
various SSL options can also be registered with the domain name
infrastructure (as part of registering the public key). This can be a
true SSL transaction and eliminates all the existing SSL protocol
chatter back and forth (and no digital certificate required)

so, if you start considering transaction efficiency ... there is the
issue of 7packet minimum for TCP sessions. VMTP specified a 5-packet
minimum exchange for reliable communication.

 From my RFC index.


1045 E
VMTP: Versatile Message Transaction Protocol: Protocol
specification, Cheriton D., 1988/02/01 (123pp) (.txt=264928)

as usual in my RFC index summary entries, clicking on the ".txt=nnn"
field retrieves the actual RFC.

However, when we were doing XTP protocol specification ... we actually
came up with a minimum 3-packet exchange for reliable transaction

lots of other posts mentioning the catch-22 issue for the SSL domain
name certification authority industry moving to higher integrity domain
name infrastructure operation
http://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation
checking capability
http://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key
Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An
http://www.garlic.com/~lynn/aadsm8.htm#softpki6 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop

http://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source
http://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source
crypto? (bad form)
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM
(was WYTM?)
http://www.garlic.com/~lynn/aadsm17.htm#18 PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against
Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#43 SSL/TLS passive sniffing
http://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the
session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at
MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
http://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet
security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE
Secure Email Technologies
http://www.garlic.com/~lynn/aadsm22.htm#0 GP4.3 - Growth and Fraud -
Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud -
Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#18 "doing the CA statement
shuffle" and other dances
http://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement
shuffle" and other dances
http://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
http://www.garlic.com/~lynn/2001l.html#22 Web of Trust
http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into
Browser Confuse Me
http://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks
http://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in
abscense of client certificates
http://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
http://www.garlic.com/~lynn/2002n.html#2 SRP authentication for web app
http://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all
equally secure?
http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs',
how curruptable are they to
http://www.garlic.com/~lynn/2003.html#63 SSL & Man In the Middle Attack
http://www.garlic.com/~lynn/2003.html#66 SSL & Man In the Middle Attack
http://www.garlic.com/~lynn/2003d.html#29 SSL questions
http://www.garlic.com/~lynn/2003d.html#40 Authentification vs Encryption
in a system to system interface
http://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses
malicious network traffic
http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model
(At least I hope it's new)
http://www.garlic.com/~lynn/2003p.html#20 Dumb anti-MITM hacks / CAPTCHA
http://www.garlic.com/~lynn/2004b.html#41 SSL certificates
http://www.garlic.com/~lynn/2004g.html#6 Adding Certificates
http://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005.html#35 Do I need a certificat?
http://www.garlic.com/~lynn/2005e.html#22 PKI: the end
http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and
interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005e.html#51 TLS-certificates and
interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005g.html#0 What is a Certificate?
http://www.garlic.com/~lynn/2005g.html#1 What is a Certificate?
http://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
http://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of
certificates & public keys securely
http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no
SSL being used
http://www.garlic.com/~lynn/2005i.html#3 General PKI Question
http://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the
http://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005m.html#0 simple question about
certificate chains
http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from
External CA
http://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a
secured P2P network
http://www.garlic.com/~lynn/2005t.html#34 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#9 PGP Lame question
http://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh
http://www.garlic.com/~lynn/2006d.html#29 Caller ID "spoofing"

Re: X.509 and ssh

Ken Johanson wrote:
Quoted text here. Click to load it

so there is some complete agreement with the SSL domain name
Certification Authority industry proposal to have domain name owners
register onfile public keys when they register domain names.

rather than just restricting the use of realtime, online, onfile public
key use to just validating digital signatures on communication with the
domain name infrastructure and for ssl domain name digital certificate
applications ... enable access to the online, onfile public keys
available to everyone in the world. Then everybody has online, realtime
access to the real public keys w/o having to resort to redundant,
superfluous, stale, static digital certificates ... and can also
optimize the SSL protocol chatter.
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh

another trivial case is the x9.59 financial standards protocol which was
designed to preserve the integrity of the financial infrastructure
for all retail payments. the paying entity has a pre-existing
relationship with their financial institution. the paying entity's
financial institution keeps some amount of information about their
account holders. one of the pieces of information about their account
holders, is the account holders' public keys. If the paying entity's
financial institution already has the registered public keys for all
their account holders (as well as other registered information), it is
trivial to demonstrate that it is redundant and superfluous to append
stale, static digital certificates to transactions sent to the paying
entity's financial institution for authentication and authorization.

so the next step is to trivial show that when the relying party has
direct access to the real information .... say in the case where the
authoritative agency for domain name ownership has onfile public keys
for the domain name owner and is willing to provide real time access to
such information, the stale, static digital certificates (representing
that registration and certification) is redundant and superfluous.

Another is any case, where a registration and certification authority is
providing for online real-time business processes in support of digital
signed transactions. If the relying party trusts a certification
authority to issue a stale, static digital certification that can be
used for authentication ... relying parties may find it even more
valuable if the certification authority would provide real-time
authentication and authorized transaction (even taking financial
liability) for digital signed transactions. Since they can be the same
registration and certification authority in both the offline, stale,
static digital certificate scernario (a credential/certificate
representing some real certification business process for purely
authentication) and in the real-time, online support of digitally signed
transactions (which can include authorization and liability in addition
  to the sense of any authentication).

It turns out that one of the shortcomings for accepting liability in the
financial transaction case with respect to the offline digital
certificate model ... is the one hundred checks of $100 each (i.e. the
digital certificate can emulate the business check scenario and say the
certificate is not good for any checks over $100) or two hundred checks
of $5000 each. The digital certificate just provides a method for
authenticating ... and potentially could include a maximum per
transaction limit (following the stale, static business check
methodology). However, the infrastructure was still vulnerable to
aggregation attacks ... and the countermeasure was online transactions
that supported not only per transaction rules but could also support
aggregation rules ... something not easily done or controlled with an
offline, stale, static paradigm.

The online, integrated authentication and authorization model could
provide both per transaction business controls as well as aggregated
business controls. Once you have an online, integrated authentication
and authorization paradigm ... it makes the offline, stale, static
processes redundant and superfluous.

Re: X.509 and ssh

Ken Johanson wrote:
Quoted text here. Click to load it

as stated in other post
http://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh

this was a real business fraud problem ... which businesses responded
with a stale, static credential/certificate (dating some number of
decades) in the form of a check embossed with a stale, static, per
transaction business rule embossed each such credentials (check) with
per transaction limit. some of the digital certificates for financial
purposes even proposed having similar stale, static, per transaction
business rule embosed in the electronic digital certificate (aka not
good for transactions with value greater than xxxx).

the problem that started being addressed sometime in the 80s with
payment cards that were used for realtime, online operation (where the
backend business rules could include a broad range of per transaction
specifications ... but there could also be aggregation business rules
... that representing real time rules spanning a collection of
transactions) ... was fraud being done by doing using 100 $100 checks or
possibly 200 $5000 checks (whatever the per transaction limit was).

the relying parties liked it much better because not only were they
getting realtime authentication responses back from the authoriative
agency (or certification authorities, if you wish), but they were also
getting back realtime authorization responses (which you couldn't do
using the offline stale, static credential/certificate paradigm)

for the various digital certificate-based financial transaction
proposals ... they went thru all the legacy business rule proposals that
had been used in stale, static credentials/certificates in the past.
however, it was trivial to show that such stale, static legacy
approaches couldn't address the aggregation countermeasures implemented
in online, realtime operations. furthermore, any authoritative agency
supporting such infrastructures could easily have all the information
necessary for both doing realtime authentication and realtime
authorization .... making any stale, static digital certificate
operation redundant and superfluous.

so the stale, static, offline credential, certificate, license,
diploma, letters of credit, letters of introduction methodology have
served a useful business requirement in the physical world for
centuries, namely providing a mechanism to represent some information
to relying parties who have had no other mechanisms for accessing the
actual information.

digital certificates are just electronic analogs of their physical
world counterparts, meeting the same business requirements ... namely
providing a mechanism to represent some information to relying parties
who have had no other mechanisms for accessing the actual information.

for business operations that have moved into an online paradigm with
realtime, online access to all necessary information ... the stale,
static digital certificate methodology represents an archaic, obsolete,
redundant and superfluous paradigm.

Re: X.509 and ssh

http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#31 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#34 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#35 X.509 and ssh

so another another scenario comparing online based transaction operation
and offline credential/certificate operation are door badge systems.

the legacy, oldtime door badge systems have been offline. as the higher
value online door badge systems came into being, the offline door badge
systems have moved into the lower cost market niche.

in the 3-factor authentication model

* something you have
* something you know
* something you are

an electronic door badge represents "something you have" authentication.
in the legacy offline door badge system, the badge would present some
unique information that validates a specific badge and differentiates it
from other badges (aka unique "something you have" authentication) and
then some other code that provides the basis for authorization decision
(by a specific door processor). before the introduction of online door
badge systems, the authorization information provided by the badge for
the offline paradigm was becoming more and more complex ... listing
specific classes of doors that were authorized and/or specific doors
that it was authorized. this overloaded the function of the badge with
both "something you have" authentication as well as providing
authorization information for the offline door badge processor.

with the introduction of online door badge, the construct served by the
badge could return to purely a unique "something you have"
authentication. The badge provides unique information to differentiate
itself from other badges; the online system looks up that specific badge
entry and finds the corresponding entity (associated with the badge),
including the entity's permissions and determines whether or not to
authorize the door to open. The online system typically can support a
lot more complex set of realtime permission rules ... compared to
features provided by offline door badge systems ... not only stale,
static per transaction rules,  but say a capability to raise an alarm if
the same "something you have" badge is used to enter multiple succesive
times w/o having been used for exits between the entries. This is
comparable to the richer set of features in online payment card
operation ... where set of authorization rules of an online paradigm can
include authorization spanning aggregation of transactions (like has an
aggregate set of transactions exceeded the entity's credit limit) as
opposed to single transaction operation.

now various door badge systems ... whether online or offline have tended
to implement static information to represent a unique physical object
("something you have" authentication). systems relying on static data
representation are a lot more vulnerable to evesdropping and/or skimming
and vulnerable to replay attacks (possibly with counterfeit/cloned badges).

a countermeasure to such skimming/evesdropping (in support of replay
attacks) is a badge with a chip that implements public/private key
technology. the chip has a unique private key which is used to digitally
sign randomly generated data. the relying party then validates the
digital signature (with the corresponding public key) as part of
establishing a unique token in support of a "something you have"
authentication paradigm.

the public/private key door badge, can be implemented in an offline door
badge system, where the door badge is providing both authentication and
authorization information. The chip in the door badge not only returns a
digital signature to the door reader but also a digital certificate. the
digital certificate contains the public key necessary to validate the
digital signature (performing the authentication part of the operation)
and the other information in the digital certificate provides the basis
for the door deciding whether or not to open (authorization). this
technology change is a countermeasure to various kinds of replay attacks
against offline door badge systems.

an online public/private key door badge system implementation doesn't
require a digital certificate since the online entry contains the public
key necessary to validate a digital signature (for a specific badge as
part of establishing a specific unique badge in support of "something
you have" authentication). the online entry also contains the permission
specifications in support of the realtime, online authorization rules.
in the higher value, online door badge system operation, any digital
certificate (providing information for both authentication and
authorization functions) is redundant and superfluous ... since that
information is part of the operation of the online door badge system
The online systems tend more sophisticated authorization rule
implementation, which tend to also be more valuable and more complex
than possible in an offline door badge system using stale, static
authorization rules.

The digital signature paradigm can be viewed as providing dynamic data
authentication countermeasure to skimming/evesdropping (and replay
attacks typically associated with static data authentication
infrastructures). However, the offline paradigm, using a digital
certificate tends to retain stale, static authorization rule
implementation. The transition to online operation can take advantage of
both the dynamic data authentication (provided by the digital signature
paradigm) and also dynamic authorization rules (provided by having
aggregated and realtime information available in the online system).

so the stale, static, offline credential, certificate, license, diploma,
letters of credit, letters of introduction methodology have served a
useful business requirement in the physical world for centuries, namely
providing a mechanism to represent some information to relying parties
who have had no other mechanisms for accessing the actual information.

digital certificates are just electronic analogs of their physical world
counterparts, meeting the same business requirements ... namely
providing a mechanism to represent some information to relying parties
who have had no other mechanisms for accessing the actual information.

a few past postings discussing the offline/online door badge system
http://www.garlic.com/~lynn/aadsm16.htm#12 Difference between
TCPA-Hardware and a smart card (was: example: secure computing kernel
http://www.garlic.com/~lynn/2003b.html#50 Authentication w/o user ids
and passwords
http://www.garlic.com/~lynn/2004j.html#15 US fiscal policy (Was: Bob
Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2006c.html#16 X.509 and ssh

Site Timeline