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
