Re: X.509 and ssh
- From: Ken Johanson <ken@xxxxxxxx>
- Date: Tue, 11 Apr 2006 12:31:10 -0600
Anne & Lynn Wheeler wrote:
Ken Johanson <ken@xxxxxxxx> writes: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
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.
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.
"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??
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.
as a result, in the mid-90s you saw the introduction of
relying-party-only certificates ... http://www.garlic.com/~lynn/subpubkey.html#rpo
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.
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?
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.
I might believe you, given a concrete example.
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
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.
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 ... http://www.garlic.com/~lynn/aadsm5.htm#asrn2
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).
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
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
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
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).
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
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
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?
- Prev by Date: Re: Concatenated SSH tunnels
- Next by Date: Re: X.509 and ssh
- Previous by thread: Re: X.509 and ssh
- Next by thread: Re: X.509 and ssh