Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before

[Anne & Lynn Wheeler]

At 02:29 PM 12/25/2003 +1300, Peter Gutmann wrote:
>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 [0]), 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 majordomo at metzdowd.com