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 [EMAIL PROTECTED]