X.509 / PKI, PGP, and IBE Secure Email Technologies

[Anne & Lynn Wheeler]

Ed Gerck wrote:
> I think that's where PKI got it wrong in several parts and not
> just the CPS. It started with the simplest (because it was meant to
> work for a global RA -- remember X.500?) and then complexity was
> added. Today, in the most recent PKIX dialogues, even RFC authors
> often disagree on what is meant in the RFCs. Not to mention the
> readers.

the baseline analysis, threat/vulnerability models, etc ... start with
the simplest and then build the incremental pieces .... frequently
looking at justification for the additional complexity.

when doing the original design and architecture you frequently start
with the overall objective and do a comprehensive design (to try and
avoid having things fall thru the cracks).

i would contend that the issue with PKI isn't as much that they started
with simple and then did incremental piece-meal design (rather than
complete, comprehensive design) ... but they actually did design
something for a specific purpose ... and subsequently it was frequently
tried to force-fit it for purposes for which it wasn't originally
designed for.

for example the traditional business model tends to have relying parties
contracting directly with the parties they rely on (and there is
contractual obligation between the two parties). the evolution of the
trusted third party certification authority model violates most standard
business practices that have grown up over hundreds of years.

the trusted third party certification authority is selling digital
certificates to key owners for the benefit of relying parties. there is
a large disconnect where the parties that are supposedly going to rely
on and benefit from the digital certificates aren't the ones contracting
for the digital certificates. this disconnect from standard business
practices can be considered the motivating factor for the invention of
CPS ... even tho there may not be a direct business and contractual
relationship between the relying parties and the certification
authorities ... a CPS tries to fabricate a sense of comfort for the
relying parties. A contractual relationship would otherwise provide for
this sense of trust... the relying party pays the certification
authority for something, and the certification authority then has some
obligation to provide something in return to the relying party.
In most trusted third party certification authority operations there is
no legal, business or otherwise binding relationship between the
relying party and the TTP/CA ... it is between the key owner and the TTP/CA.

This could be further aggravated by RFC authors who possibly have no
familiarity with standard business practices and attempt to write
something just because they want it to be that way.

Another example could be considered OCSP. Basically digital certificates
are stale, static, r/o, armored copies of some information located
someplace. A business process model has relying parties, relying on the
information in stale, static, r/o copies of the information because they
have no means for directly accessing the real, original information
(basically the letters of credit/introduction from sailing ship days ...
aka offline with no local resources). OCSP provides for a online
transaction which asks whether the stale, staic information is still
usuable, attempting to preserve the facade that digital certificates
serve some useful purpose when there is online, direct access
capability. The alternative is to eliminate the digital certificates all
together and rather than doing an OCSP transaction, do a direct, online
transaction.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com