Re: TLS-certificates and interoperability-issues sendmail / Exchange / postfix ..

From: Anne & Lynn Wheeler (
Date: 04/03/05

Date: Sun, 03 Apr 2005 10:40:15 -0600 (Per Hedeland) writes:
> No, and since this is specifically *not* what I'm talking about,
> while you keep insisting that it is, I'm clearly not able to make
> you understand what I'm saying - regardless of the reason for that,
> I thus see no point in continuing this discussion.
> For anyone else that may have suffered through this thread, the
> point of my original post, now lost in the noise, was not primarily
> to assert that certificate validation doesn't happen, but to point
> out that it is in many cases quite feasible to make it happen even
> without certificates signed by "official" CAs.

note that the original basic public/private key business process use
of asymmetric key technology was that public keys could be openly
distributed (and used subsequently for validating digital signatures
generated with the corresponding private key).

the original PKI model was in the days of offline email (aka dial-up
the local electronic post office, exchange email, hang-up, process)
involving email between two parties that previously never had any
contact and that the recipient had not other recourse (like online
resource) to checking on the sender.

the basic mechanism is that the recipient has a trusted store of
public keys and their associations. in the pgp (and ssh and other)
model, this trusted public key store contains public keys of that the
recipient has previously "registered". in the pgp model, the recipient
validates digital signatures directly using public keys from the
trusted public key store.

this gets a little more complicated in the PKI model ... the
recipient's trusted public key store is now one-level (or more)

certification authorities set up business processes for registering
public keys (analogous to the business process that oridinary
individuals use for registering public keys in their trusted public
key store) ... they create these things called certificates ... that
represent some certification business process performed by the CA.
the certificates typically "bind" a public key and some information
about the public key owner in a string of bits, which are digitally
signed by the CA. this digital certificate is returned to the "key
owner". The key owner, at some point in the future, generates some
sort of message, digitally signs the message, and packages the
message, the digital signature, and the certificate for transmission.

the recipient gets this package triple, and validates the CA's digital
signature on the certificate (using the CA's public key from the
recipient's trusted public key store). the recipient then takes the
sender's public key from the digital certificate and uses it to
validate the digital signature on the actual message.

basically these (offline paradigm) digital certificate things are
analogous to letters of credit from the sailing ship days (when the
relying party/recipient had no previous interaction and/or no other
recourse to establish anything about the party they were dealing

For various processing reasons, many of the PKI implementations use
something called a self-signed certificate as part of registering a
CA's public key in the recipient's trusted public key store ... they
look and smell and have a format like a "regular" digital certificate
but are used in a totally different business process. The CA
self-signed digital certificates are part of the business process of
registering a public key in the recipient's trusted public key store
(analogous to the PGP model that directly registers senders' public
keys in the recipient's trusted public key store).

A big issue (in today's market) involving the recipient's trusted
public key store, is a) whether the recipient's trusted public key
store is part of a specific application and b) whether the application
comes preloaded with some number of trusted (certification authority)
public keys (on behalf of the recipient). Some number of certification
authorities have paid big bucks to application vendors to have their
public keys (whether they are packaged as a self-signed digital
certificate or not) preloaded in the application trusted public key
store shipped to consumers.

In the early '90s there was a big push for x.509 identity
certificates. Part of the problem was that there was no prediction (at
the time that the CA generated a digital certificate) ... what were
all the uses a digital certificate was going to be put to (what kind
of business process and what kind of identity information would be
meaningful to the recipient or relying parties). They also wanted to
charge $100/certificate/annum for each digital certificate issued
... so it wasn't going to be a common event. The result was a tendency
to grossly overload these identity digital certificates with
information ... in the anticipation that some relying party
(recipient) might find it useful for something in the future.

By the mid-90s, some number of relying party institutions were
starting to realize that such digital certificates, grossly overloaded
with information, represented a significant liability and privacy
exposure. You then started seeing some institutions (like financial)
migrating to relying-party-only certificates ... certificates that
basically only contained some sort of account number or other
identifier that could be used in a real-time lookup (recipient's local
database or other online operation).

An issue with relying-party-only digital certificates was that it was
trivial to show that they were redundant and superfluous. Normal
operation was that the identifier was also available in the body of
the basic, digitally signed message and the identifier would index
some sort of real-time record lookup (local and/or online) that not
only contained information about the sender ... but also the sender's
public key (i.e. the information base became a real-time trusted
public key store, in addition to all the other trusted information
that might be available).

In the financial arena for these relying-party-only certificates, the
consumer registers their public key with their financial institution
and their financial returns a digital certificate containing an
account number and the public key. at some point in the future, the
consumer generates a financial transaction and digitally signs the
financial transaction. The consumer then packages the financial
transaction, the digital signature, and the digital certificate and
transmits it to the financial institution. The financial institution's
record index (account number) that is in the certificate is duplicated
in the transaction. The financial institution receives the "package",
discards the digital certificate, uses the account number from the
transaction to retrieve the account record (including the consumer's
public key) and validates the consumer's digital signature using the
real-time retrieved public key.

One of the issue's from the mid-90s with these financial
relying-party-only digital certificates was that they were on the
order of 4k-12k bytes (just containing an account number and a public
key)while the basic financial transaction is on the order of 60-80
bytes. Not only was it trivial to show that these relying-party-only
certificates were redundant and superfluous, but their only apparent
purpose was to cause extreme payload bloat and increase the standard
financial message size by a factor of one hundred times.

The original SSL (TLS precursor) was part of browsers for
authenticating that the web server they thot they were talking to were
actually the web server they were talking to. The concern was over
integrity issues in the domain name infrastructure being subverted and
a browser getting redirected to a fraudulent web site (basically the
browser compared the domain name from what the typed in URL with the
domain name in the digital certificate presented by the web site).

some early history comments about SSL for e-commerce and
payment transactions:

basically browsers came preloaded with a large number of certification
authority public keys.

somebody would apply to a SSL domain name certification authority
providing a lot of identity information. The certification authority
then would contact the domain name infrastructure in an attempt to
cross-check the applicant's identity information with the identity
information on-file with the domain name infrastructure as to the true
domain name owner. This was an error-prone, complex, and costly

Somewhat from the certification authority industry there was a push to
improve the integrity and reduce the cost of SSL domain name
certification process, a proposal was that domain name owners register
a public key when they registered the domain name. Future communcation
with the domain name infrastructure would be digitally signed and the
domain name infrastructure would validate the digital signature with
the on-file public key (note: no digital certificates involved).

So SSL domain name certificate applicants would now digital sign their
application. The certification authorities then can do a real-time
retrieval of the on-file public key (from the domain name
infrastructure) to validate the digital signature on the SSL domain
name certificate application. This turns a costly, complex, and
error-prone identification process into a much simpler, cheaper and
less error-prone authentication process.

It does have sort of a catch22 for the certificaiton authority

1) improving the integrity of the domain name infrastructure for
the certification authority industry, improves the integrity
for everybody, mitigating the original justification for
SSL domain name certificates in the first place.

2) if the certification authority industry can do real-time retrieval
of on-file public keys, then supposedly so could everybody else
... eliminating the requirement for public key based infrastructure
based on stale, static, digital certificates. It would be possible to
simplify all the SSL handshake digital certificate related protocol
chatter at the start... and substitute a request to the domain name
infrastructure that returned the public key in the same transaction
that returned the domain name to ip-address response transaction.

for some topic drift ... the very latest, fresh off the press
domain name infrastructure RFCs

4035 PS

 Protocol Modifications for the DNS Security Extensions, Arends R.,
 Austein R., Larson M., Massey D., Rose S., 2005/03/25 (53pp)
 (.txt=130589) (Updates 1034, 1035, 2136, 2181, 2308, 3007, 3225,
 3226, 3597) (See Also 4033, 4034) (Refs 1034, 1035, 1122, 2181,
 2308, 2460, 2535, 3007, 3226, 3655)

4034 PS

 Resource Records for the DNS Security Extensions, Arends R.,
 Austein R., Larson M., Massey D., Rose S., 2005/03/25 (29pp)
 (.txt=63879) (Updates 1034, 1035, 2136, 2181, 2308, 3007, 3225,
 3226, 3597) (See Also 4033, 4035) (Refs 1034, 1035, 1982, 2181,
 2308, 2535, 2536, 2537, 2539, 2930, 2931, 3110, 3445, 3548, 3597,
 3658, 3755, 3757, 3845)

4033 PS

 DNS Security Introduction and Requirements, Arends R., Austein R.,
 Larson M., Massey D., Rose S., 2005/03/25 (21pp) (.txt=52445)
 (Obsoletes 2535, 3008, 3090, 3445, 3655, 3658, 3755, 3757, 3845)
 (Updates 1034, 1035, 2136, 2181, 2308, 3007, 3225, 3226, 3597)
 (See Also 4034, 4035) (Refs 1034, 1035, 2136, 2181, 2308, 2535,
 2538, 2845, 2931, 3007, 3008, 3090, 3226, 3445, 3597, 3655, 3658,
 3755, 3757, 3833, 3845) (DNS-SECEXT) (DNSSEC)

from rfc index

as always, clicking on the ".txt=nnnn" field retrieves the actual

An analogy for simple email authentication would be that when somebody
signed up with an ISP, they registered a public key ... which then
goes into the ISP's userid repository. All email is then digitally
signed ... and the recipient just has to contact the sender's ISP in
real time to get the sender's on-file public key. No digital
certificates are required (which were originall created in the early
80s to address the offline email scenario in situations where the two
parties had no prior contact and no other recourse to obtain
information about parties that they were dealing with for the first

There is no costly, complex and error-prone identification and
certification processes needed to proove that the person owning the
email account also owns a particular public/private key pair ... if
the public key registration is integrated into the business process of
creating an userid.

Anne & Lynn Wheeler |