Re: X.509 and ssh

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.

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.

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
transactions.

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
information

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
public key).

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
transmissions.

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
certificates).

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: PKI: the end... The end of SSL, X.509 certificates, digital signature ... PKI is a business process that makes use of asymmetric key ... use of the "private key" are met, then a relying party may infer from ... use of the registered public key to verify a digital signature. ...(sci.crypt)

Re: General PKI Question... > encrypt the message with the intended recipient's public key....digital signature authentication...Certificates were somewhat the "letters of credit" analogy (from the ...(microsoft.public.security)

Re: What is a Certificate?... > of a prevalent public key infrastructure for end users. ... > signed certificates (or certificates that cannot be verified by one ... keys that have to be loaded in the relying party's trusted public key... where a relying party...(comp.security.misc)