Re: X.509 and ssh




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

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.

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

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

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
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

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

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

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
https://www.financialcryptography.com/mt/archives/000694.html

slightly related set of posts on having worked on word smithing both
the cal. state and federal electronic signature legislation
http://www.garlic.com/~lynn/subpubkey.html#signature

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
certificates
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 Artifact...
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 Issues
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 authentication
http://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud - Case #3 - Phishing

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