odd that you would say this. kerberos & radius are entirely account-based and so far as I can tell, these are the only (partially) successful authentication schemes in the enterprize. did u have something else in mind? ..tom > 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 > > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Saturday, June 21, 2003 22:29
> Subject: Confusing Authentication and Identiification? > > > Early in the x9.59 process there were a number of blatently erroneous > assertions that account-based represented a closed infrastructure while > certificate-based repesented an open infrastructure. > > Basically, in both account-based and certificate-based infrastructures ... > there can be public key owners, relying parties, and certification bodies. > An account-based infrastructure tends to provide online certification while > a certificate-based infrastructure tends to create stale, static copies of > information (kept in accounts by the certification authority) that can be > used in offline scenarios. > > In both account-based and certificate-based operations, you could have the > same exact information being certified, the same exact public key owners, > the same exact relying parties and the same exact certifying authorities. > > An account-based and certificate-based operation can be equally closed or > open based on the type of information being authenticated and the degree > of trust that the certifying bodies have among the population of relying > parties. The blatently erroneuous statement about account/certificate > operations differing by being closed/opened wasn't the differentiator; the > differentiator between account/certificate operations tends to be whether > it is an online operation vis-a-vis offline operation. > > The other scenario, was that some x.509 identitfy certiificate operations > fell into the trap of thinking that they could grossly overload > certificates with large amounts of identity and privacy information and > widely publish and distribute the information all over the world. As it > began to dawn on them that this probably wasn't a good thing, there was a > significant reduction in the types of information that might be published > in a certificate (many financial institutions retreating to a > relying-party-only certificate containing a public key and a customer > account number). As the types of identity and privacy information that > might be globally published became more & more restricted, effectively > certificates became more and more of a closed environment. In that sense, > the FSTC FAST paradigm actually represents more of an open infrastructure > than any of the privacy tainted certificate paradigms, since it is possible > for FSTC FAST to provide online response to an "over 21" assertion w/o > divulging the birth date, or to provide an online response to "pay $100" > assertion w/o divulging the account balance or the person's name or > address. > > The issue regarding account-based vis-a-vis certificate-based is one of > online vis-a-vis offline. However, a online infrastructure has some degree > additional latitude in validating various kinds of authenticated assertions > w/o unnecessarily divulging identity and/or privacy information which would > typically be found in a certificate-based implementation. > > In that sense, given any concern over not wanting wide-spread publication > and distribution of large amounts of identity and privacy information, an > online certification operation might be considered to be somewhat more open > than a certificate based information .... since it could perform more types > of (online) validations w/o unnecessarily widely publishing identity and > privacy information. The online paradigm tends to also deal with much more > dynamic data (like current account balance) which can be of much more value > compared to the offline paradigm (like whether or not a person did or > didn't have a specific bank account at some time in the past). > > somewhat related, the IETF AAA working group just published a new RFC > 3539 PS > Authentication, Authorization and Accounting (AAA) Transport Profile, > Aboba B., Wood J., 2003/06/20 (41pp) (.txt=93110) (was > draft-ietf-aaa-transport-12.txt) > > for a complete list of AAA working group RFCs go to > http://www.garlic.com/~lynn/rfcietff.htm > and select "Term (term->RFC#)" and then scroll down to > "Authentication, Authorization, and Accounting" > > Authentication, Authorization and Accounting > see also accounting , authentication , authorization > 3539 3127 2989 2977 2906 2905 2904 2903 > > past discussions of relying-party-only certificates: > http://www.garlic.com/~lynn/subpubkey.html#rpo > > misc. past threads with open/closed & aads/cads: > http://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1 > vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt)) > http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about > Digital Signatures > http://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die > http://www.garlic.com/~lynn/aadsm9.htm#cfppki9 CFP: PKI research workshop > http://www.garlic.com/~lynn/aepay4.htm#privis privacy issues > http://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards > http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... > RIP PKI .. addenda > http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... > RIP PKI ... part II > http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long) > http://www.garlic.com/~lynn/aadsm14.htm#16 Payments as an answer to spam > http://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of > digital certificate > http://www.garlic.com/~lynn/2001g.html#55 Using a self-signed certificate > on a private network > http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security > > -- > Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm > > > To remove yourself from this list send a message Unsubscribe to > [EMAIL PROTECTED]
