Lynn, Relying-party certificates applied to the described scenario would add a $5-$20 RA cost per user and add extreme user-inconvenience in the [very likely] case a user would need to go to multiple e-government portals. That is, relying-party-only PK schemes, be it account or certificate-based, are not candidates for e-governments communicating with citizens.
In your earlier posting you claimed that account-based schemes could do the same thing as certificate-based dittos; Could you please provide some more data to support this view by applying your thinking to the described TTP-based scenario? Anders ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Anders Rundgren" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 20:04 Subject: Re: Confusing Authentication and Identiification? [EMAIL PROTECTED] on 6/22/2003 1:01 pm wrote: Lynn, May I interrupt your crusade against X.509? I would like to know what you consider redundant in an X.509 certificate. Is it the account number (Subject DN)? Is it the public key? Is it the extension pointing to an OCSP responder? Or is is rather the CA signature and associated path-validation (and build) that you consider a problem? Anyway, disregarding the fact that account-based infrastructures have little support in current SW platforms, how would an account-based infrastructure be implemented for an e-government scenario where several millions of citizens (having a state- defined "account number") are served by thousands of independent "e-services"? The X.509 version of this is running in Sweden and uses a number of independent TTP CAs (mostly banks) to provide certificates with the proper "account number". Anders ============================================================ In the relying-party-only certificates that the financial institutions went to in the mid '90s after the retreat from the forey into identify certificates from the early 90s .... the certificate contained an account number and a public key. In the business process analysis, a relying party only certificate is appended to a digitally signed transaction that is sent back to the relying party. Doing an end-to-end business process analysis: 1) the relying-party had the original copy of the relying-party-only certificate stored in the account record 2) for 8583 financial transactions, it was realized that the payload of a typically certificate was 10 to 100 times larger than the transaction itself (aka a certificate containing only an account number and a public key was ten to one hundred times larger than the base transaction payload) 3) the typical signed transaction already contained the account number, making the account number also in the relying party only certificate redundant and superfluous 4) since this was a relying-party-only certificate, and only the account number was present, it was was necessary to retrieve the actual account record in order to perform any processing (the certificate just contained a redundant index, i.e. the account number, to retrieve the actual information that was either a) a serious privacy violation to include in the certificate and/or real-time and/or aggregated information that could be loaded into a stale, static certificate built at some point in the past 5) the account record contained the original copy of the certificate, including the public key. so the only other piece of information in a relying-party-only certificate was the public key .... but for relying-party-only transactions with relying-party-only certificates, it was necessary to read the account record that contains the original of the relying-party-only certificate, including the public key. That made transmitting the other piece of information in the certificate, the public key also redundant and superfluous (since it could be found in the account record). So tt was trivial to show that for relying-party-only certificate that is was possoble to either 1) compress the relying-party-only certificate to zero bytes since it only contained redundant and superfluous information that was easily found elsewhere or 2) recognized that the relying-party had the original copy of the relying-party-only certificate that would be read with the account record. sending a copy of the relying-party-only certificate to the public key owner so the public key onwer could return the copy of the relying-party-only certificate to the relying-party on every transactions (especially in cases where the size of the relying-party-only certificate was ten to hundred times larger than the size of the base transaction) when the relying-party had the original of the relying-party-only certificate. This could be treated that the relying-party always had the original of the relying-party-only certificate (if you will, effectively cached) .... so it was redundant and superfluous for the public key owner to return a copy of the relying-party-only certificate to the relying-party which had the original of the relying-party-only certificate. so the issue is that the vast majority of electronic transactions that occur in the financial infrastructure (well over 90%) have SW support for account-based infrastrcutre. There is some amount of internet related SW that aren't well integrated into the fundamental core-infrastructure that tend to be offline PKI oriented rather than online, account, core-business process oriented; possibly since a lot of the internet related SW have been produced by PKI oriented vendors that are interested in pushing their products. lots of past descriptions of the relying-party-only certificate end-to-end business process scenario http://www.garlic.com/~lynn/subtopic.html#rpo specific past threads regarding relying-party-only certificate end-to-end business process description which you participated in: http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost http://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda) http://www.garlic.com/~lynn/aadsm11.htm#19 IBM alternative to PKI? http://www.garlic.com/~lynn/aadsm11.htm#21 IBM alternative to PKI? http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II http://www.garlic.com/~lynn/aadsm12.htm#22 draft-ietf-pkix-warranty-ext-01 http://www.garlic.com/~lynn/aadsm12.htm#26 I-D ACTION:draft-ietf-pkix-usergroup-01.txt http://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment Transaction? http://www.garlic.com/~lynn/aadsm12.htm#41 I-D ACTION:draft-ietf-pkix-sim-00.txt http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda) http://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
