X.509 certs were designed to solve the problem of authenticating users to the global X.500 directory. So they're good at what they were designed for (solving a problem that doesn't exist ), and bad at everything else (solving any other sort of problem).
disclaimer: I never actually worked on either X.500 or X.509 standards ... however, I do remember an acm sigmod meeting circa '90 where somebody did characterize x.500 as a bunch of networking engineers trying to re-invent 1960s database technology. minor past refs:
http://www.garlic.com/~lynn/2002g.html#24 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002g.html#28 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#7 OCSP and LDAP
also, (not knowing about original intent of x.509) ... the PKI infrastructures I saw in the early to mid 90s ... had x.509 identity certificates that appeared to be populated with stale, static (and possibly subset) of information from a database entry .... targeted for use by relying parties in lieu of the relying parties actually being able to contact the real database (contained some piece of a x.500 directory entry that a relying-party could presumably use if they didn't have direct access to the x.500 directory).
the relying-party-only certificates of mid ot late 90s appeared to be much more of something that would authenticated an entity to a operational service .... having thrown out nearly all of the information that might be found in a database (especially anything that might possibly represent a privacy and/or liability issue) . However, relying-party-only certificates could still be shown to be redundant and superfluous ... aka if i'm sending a digitally signed transaction containing an account number (or other database indexing value) to a relying party having the database .... then appending any kind of certificate that contains a small subset of the complete information from the database entry (including any public key or authentication material) is redundant and superfluous.
the IETF OCSP standards work seems to be all about a real-time protocol that a relying party can use to check with a (LDAP?) database about whether the information that might be in a specific certificate can still be relied on. It has some of the flavor of a distributed filesystem/database cache entry invalidation protocol All of the CRL and OCSP stuff isn't about using the certificate for authenticating to an x.500 directory .... but whether the stale, static copy of information in the certificate is still good.
one of the PKI related efforts from the mid-90s specified adding a digital signature and a relying-party-only certificate to a iso8583 oriented financial transaction. It turns out that the typical iso8583 financial transaction eventually gets packaged as something like 60-80 bytes .... while the typically implemented relying-party-only certificate for this effort was between 4k bytes and 12k bytes. In this case, not only was the relying-party-only certificate redundant and superfluous but also represented a two orders of magnitude payload bloat.
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]