Re: Uploading to Asimov

[lynn@garlic.com]

Paul Schlyter wrote:
> A digital signature can be forged as easily as an MD5 hash.  To
> really guard against deliberate tampering with the data, you need
> more than that: you need a PKI, i.e. a digital certificate signed by
> a CA you trust.

you need to be able to validate a digital signature with a public key
that you trust. this can be totally independent of whether you involve
digital certificates and/or certification authorities.

the technology is asymmetric key cryptography; what one key (of a
key-pair) encodes, the other key decodes. this is to differentiate from
symmetric key cryptography where the same key both encrypts and
decrypts.

there is a business process called public key ... where one key (of a
key pair) is designated as public and freely distributed. the other key
(of a key-pair) is designated as private, kept confidential and is
never divulted.

there is a business process call digital signature ... where the hash
of some message or document is calculated and then encoded with a
private key. the recipient then can recalculate the hash, decode the
digital signature with the (corresponding) public key and then compare
the two hashes. If they are the same, then the recipient can conclude:

1) the contents have not been modified since the digital signature was
generated
2) "something you have" authentication, aka the originator had access
and use of the corresponding private key.

the normal public key infrastructures have recipients keeping trusted
public keys in their own trusted public key repository and/or accessing
an online trusted public key repository.

digital certificates somewhat were targeted at the offline email
environment of the early 80s (a paradigm somewhat analogous to the
"letters of credit" from the sailing ship days). the recipient dials
their local (electronic) post office, exchanges email, hangs up and
then is potentially confronted with first time email with a total
stranger.

Digital certificates provided a means for a recipient to determine
something about the originating stranger in first time communication.
Institutions called certification authorities were defined that
generated digital certificates. An applicant provided some information
to the certification authority along with their public key. The
certification authority validated the information and the public key
and loaded it into a message called a digital certificate ... which was
digitally signed by the certification authority.

In the first time communication with a stranger scenario ... the sender
generates a message, digitally signs the message ... and then transmits
a combination of 1) the message, 2) their digital signature, and 3)
their digital certificate.

The recipient now first process the certification authority's *message*
... aka the digitally signed digital certificate. They hopefully have a
copy of the certification authorities public key available to them to
validate the digital signature (on the digital certificate ... just
like they would do normal digital signature validation using public
keys from their trusted public key repository). If the digital
signature on the digital certificate (message) validates ... then the
recipient can retrieve the (sender's) public key from the digital
certificate and validate the digital signature on the transmitted
message.

There is a fundamental issue that the whole certification authority and
digital certificate infrastrucutre is based on the recipient having
access to trusted public key repository for validating digital
signatures (which can be the direct digital signatures or they can be
the certification authorities digital signature on the stylized
messages called digital certificates).

Fundamentally the infrastructure is based on the ability to validate
digital signatures on messages w/o the requirement for having
certification authorities and digital certificates. Once you have an
infrastructure of trusted public key repositories and the ability to
directly validate digital signatures ... then you can incrementally add
the stylized digitally signed messageds (called digital certificates
created by certification authorities) which can be validated using the
underlying infrastructure for directly validating digital signatures
(in this case the certification authorities digital signatures on
digital certificates ... to address the first time communication
between strangers scenarios).

In the early 90s, certification authorities were looking at generating
x.509 identity certificates ... where the information included in the
digital certificate was identity information. In many cases, the
certification authorities couldn't completely predict what set of
identity information a recipient (also called relying party) might be
interested in. As a result, there was somewhat of a direction to
grossly overload a x.509 identity certificate with enormous amounts of
personal information.

By the mid 90s, some institutions were realizing that x.509 indentity
certificates, grossly overloaded with enormous amounts of personal
information represented significant privacy and liability issues. These
institutions somewhat regressed to something called a
relying-party-only certificate ... basically containing somesort of
database index and a public key.
http://www.garlic.com/~lynn/subpubkey.html#rpo

However, it became trivial to demonstrate that relying-party-only
certificates were redundant and superfluous. If an institution already
has a long established relationship management infrastructure that they
use as a repository of information about the parties they deal with
.... then they can include the party's public key in the same
repository.

By its nature, a relying-party-only certificate implies that the
recipient, rather than obtaining the information about the originating
party from the digital certificate ... they instead obtain the
information from their long established relationship management
information (the digital certificate only contains a pointer to the
entry in the relationship management infrastructure). However, in any
sort of business process, the actual digitally signed message will have
also indicated who the originator is ... allowing the same entry to be
accessed w/o the use of the digital certificate. Futhermore any digital
signature on the actual message can be validated with the public key
registered in the relationship management infrastructure.

The corollary to such digital certificates being redundant and
superfluous is that their design point is for first time communication
between two strangers (the letter's of credit paradigm from the sailing
ship days) where the recipient has no other recourse for information
about the sender (either online or offline). By definition, the relying
party scenario ... the recipient already has an established
relationship with the originator ... invalidating the fundamental
design point originally established as to the purpose of digital
certificates.

In any case, the fundamental building block for public keys and digital
signatures ... is the recipient has access to a repository of trusted
public keys. In the direct scenario, the recipient has the originator's
public key and directly validates the digital signature on the message.
In the scenario to address the first time communication between
strangers ... the recipient's trusted public key repository includes
some number of certification authority public keys ... for use in
validating the certification authority digital signatures on the
stylized messages called digital certificates.