Re: PKI: the end

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

Date: Mon, 21 Mar 2005 13:23:01 -0700

"" <> writes:
> Today, PKI rely on primary numbers. Humans don't know how to
> calculate primary numbers. We humans don't know nothing about
> primary numbers. We can only take all numbers in a range (from
> 10000000000 to 999999999999) and validate if some of those numbers
> are primary nums.
> One day someone figure out how primary numbers work: it will be the
> end of PKI. The end of SSL, X.509 certificates, digital signature
> and encryption as we know it.
> Are there algorithms for digital signature and encryption which
> doesn't require private/public key pairs? That doesn't rely on
> primary numbers? I know for HMAC, enything else?

PKI is a business process that makes use of asymmetric key
cryptography (aka something is used for encryption, something else is
used for decryption and it is difficult to determine the something
used for encryption based on either the encrypted information and/or
what is used for decryption).

the fundamental business process for PKI is taking a asymmetric key
pair, that one of the keys is consistently kept private and the other
key is allowed to be public.

assuming that the fundamental business processes for protecting and
use of the "private key" are met, then a relying party may infer from
the verification of a digital signature, something regarding the
access and use of the "private key" as satisfying some form of
3-factor authentication.

besides rsa ... fips186-2 also defines ec/dsa for digital signature
algorithm ... see nist digital signature standard reference for more

within the context of 3-factor authentication

* something you know
* something you have
* something you are

... misc. other posts

most deployed PKIs don't require people to memorize the private key,
so that eliminates "something you know" authentication. also most
deployed PKIs don't make the private key dependent on some biometric
characteristics ... which then rules out "something you are"
authentication. fundamentally that leaves the "private key" being
"something you have" authentication. Since a "private key" is just a
sequence of numbers ... they are somewhat prone to replication and
once that happens, it will be difficult to assert "something you have"
authentication. it is the business process of public/private key
infrastructure that takes asymmetric key cryptography and creates the
requirement that one of the asymmetric key pairs is to be uniquely
kept private.

as mention in other contexts: Do You Need a Digital ID? Do You Need a Digital ID? Do You Need a Digital ID?

one of the issues from the early 90s in associated with x.509 identity
digital certificates was that the descriptions frequently concentrated
on the process of a certification authority creating a digital
certificate and would totally gloss over the business process
foundation for public/private key infrastructures (establishing the
convention that one of an asymmetric key pair is to be kept uniquely

the business process foundation for public/private key infrastructure
and the convention for keeping one of the keys uniquely private, in
fact is totally independent of digital certificates. It is possible to
take an existing "something you know" (pin/password) authentication
infrastructure and substitute the registration of a public key in lieu
of a pin/password. it is then possible for the relying party to make
use of the registered public key to verify a digital signature.
Assuming that the other characteristics of public/private key
infrastructure has been met, then the relying party may infer that the
private key was accessed and used in an appropriate manner ... and
therefor there is "something you have" authentication (i.e. the
public/private key business process defining the unique access and use
of the private key).

in the above example, the fundamental foundation for public/private
key business process is that of maintaining the "private key" as
private (and has nothing at all to do with digital certificates).

as an adjunct to public/private key business process authentication,
there was a business process defined for digital certificates for use
in the scenario where the originating party and the relying party have
had no prior relationship and that the relying party has no recourse
to information about the originating party (either locally or by any
online mechanism). the digital certificate is an analogy to letters of
credit from the sailing ship days and were targeted at the offline
email environment of the early 80s; aka a call was made to the local
electronic post office, email exchanged, line was dropped and the
receiving party now must authenticate email received from a totally
unexpected source having no prior contact.

another issues raised with the identity digital certificates of the
early 90s was the problem that a certification authority would be
certifying various identity characteristics and including the
certified information in the digital certificate. for 3rd party
certification authorities who would be doing this process long before
any relying party was going to depend on the information and
furthermore, the 3rd party CAs might not have any fore-knowledge of
what relying parties there might be and what identity information they
might require ... there was a tendancy to start overloading identity
digital certificates with all possible identity information ... on the
off chance some relying party might find it useful for some purpose.

by the mid-90s, it started to become apparent that identity digital
certificates overloaded with all sorts of identity information
represented a significant privacy (and possibly liability) problem So
you saw, at least financial institutions, retrenching to
relying-party-only certificates

.... effectively containing nothing more than an account number and a
public key. however it was useally trivial to demonstrate that such
relying-party-only digital certificates were redundant and superfluous
... aka somebody registers their public key with the relying party,
the relying party records the public key in an account record,
generates a digital certificate and returns it to the key owner. The
key owner originates some transaction (that includes an account
number), digitally signs the transactions and packages up the
transaction, the digital signature, and the digital certificate and
sends the triple off to the relying party.

the relying party, receives the triple, extracts the account number
from the transaction, retrieves the account record (that includes the
public key) and verifies the digital signature with the public key.

the redundant and superfluous nature of such digital certificates in
financial transactions was further exasberated by the fact that a
traditional 8583 financial transaction has been on the order of 60-80
bytes. the typical redudandant and superfluous relying-party-only
digital certificates from the mid-90s were on the order of 6k to 12k
bytes. not only where such relying-party-only digital certificates
redundant and superfluous, their sole contribution in 8583 financial
transactions was to cause extreme payload bloat, increasing typical
transaction message size by one hundred times.

the funny thing that even today you run across descriptions referring
to digital signatures being created with digital certificates.

another example of digital certificates is their use in SSL operations

we were somewhat involved in putting together the business process
and various components of the use of SSL for this thing that was
going to be called electronic commerce:

thre predominate SSL use supposedly is a browser validates a digital
certificate (using a registered public key that is on file in a
trusted public key store maintained by the browser), then checks to
see if the domain name is the same that was typed into the browser aka
"is the website i'm visiting really the website i think i'm visiting".
the issue, at the time, were concerns with the integrity of the domain
name infrastructure.

well, it turns out that a typical certification authority isn't
actually the authority for the information being certified. in the
case of domain name SSL certificates, the certification authority has
to contact the domain name infrastructure to validate the entity
applying for a SSL domain name certificate, actually is associated
with that domain name (the same domain name infrastructure that has
integrity issues that give rise to the need for SSL domain name

so somewhat motivated by the certification authority industry there is
this proposal that when somebody applies for a domain name they also
register a public key. this will not only improve the integrity of the
domain name infrastructure but also reduce processing costs for the
certification authority. Currently, a certificate authority needs an
application to supply a bunch of identity information ... which the CA
then has an expensive and error-prone process cross-checking with the
information on file at the domain name infrastructure. If there was an
onfile public key, the SSL certificate applicant would just need to
digital sign the application. Then the CA retrieves the online,
on-file public key from the domain name infrastructure and validates
the digital signature (turning a complex, error-prone and costly
identification process into a much simpler, more reliable, and cheaper
authentication process).

a catch-22 for the certification authority industry is that if the CAs
can retrieve online, on-file public keys in real time from the domain
name infrastructure ... in theory there is nothing preventing
everybody else from also retrieving online, on-file public
keys. Registering public keys in an online, on-file repository goes a
long way to eliminating the original justification for having SSL
domain name certificates at all ... i.e. as per certification
authority industry

1) registering public keys (and using them in various business
processes) improves the integrity of the domain name infrastructure
(so that the certification authority industry can rely on it for
checking the owners of certificate applications). however, one of the
original justifications for SSL domain name certificates were concerns
about the integrity level of the domain name infrastructure. improving
that integrity reduces the justification for SSL domain name

2) everybody being able to retrieve online, on-file, registered,
trusted public keys from the domain name infrastructure can eliminate
the requirement for getting public keys out of stale, static,
redundant and superflous digital certificates.

Anne & Lynn Wheeler |

Relevant Pages

  • 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 ...
  • Re: REVIEW: "Biometrics for Network Security", Paul Reid
    ... the correpsonding public key is registered with the relying party ... pin to decrypt the software file in order that the digital signature ... place in a digital signature are digital certificates. ...
  • Re: REVIEW: "Biometrics for Network Security", Paul Reid
    ... the correpsonding public key is registered with the relying party ... pin to decrypt the software file in order that the digital signature ... place in a digital signature are digital certificates. ...
  • Re: X.509 and ssh
    ... was the eventual realization that certificates potentially grossly ... As essential, as the ID present when you conduct an in-person transaction, or get aboard an airplane. ... Or can I just write you a check for $100 and claim that a1b2c3d4 is my real public key / authentication code?? ... purpose of appending certificates to payment transactions was to ...
  • Re: Proposal for a new PKI model (At least I hope its new)
    ... CA/PKI scenario for SSL domain name certificates ... ... adequate authentication mechanism. ... the CA can retrieve the public key from the domain name ...