Subject: Re: PKI International Consortium

From: [email-masked]
Date: Sat, 3 Apr 2004 12:57:02 MET

Hi all,

In line with Arshad's comments, I think there's some kind of misunderstanding 
in this discussion. It seems that we're confusing Identity and Attributes (or 
privileges). It is reasonable to think that one entity (anything that can have 
a certificate) should have only one Identity (and therefore, only one Identity 
Certificate). There are reasons that may justify having more than one 
Identity, and I will come to that later, but let's assume for now that only 
one Identity is enough.

What has been mentioned in this thread is the need to have several (identity) 
certificates for different purposes. Therefore, each of these "identity 
certificates" will be "industry-specific" and will have different associated 
semantics depending on the "industry" or purpose. In this way a "Financial 
identity certificate" would mean "The cert holder has an associated account in 
bank X and blah, blah". On the other hand my university certificate would 
state that I am "professor of the Computer Science Department".  Well, in my 
opinion these are not "identity certificates" but "attribute certificates". 

The newest version of X.509 provides a more suitable solution because it 
clearly defines a framework where identity and attribute certificates, 
although related, can be independently managed. That recommendation defines 
new types of authorities, Attribute Authorities (AA), for the assignment of 
privileges. It also defines the Source of Authority (SOA) as the ultimate 
authority to assign a set of privileges. Additionally, it provides a 
foundation to build a Privilege Management Infrastructure (PMI) that contain a 
multiplicity of AAs, SOAs and final users.

So, summarizing, if the idea is to have "context-sensitive identities", 
then "Attribute Certificates" linked to a single "Identity Certificate" are 
the best solution.

There are, however, reasons to have more than one identity certificate, but 
these are related to privacy, anonymity and sometimes legal reasons.

cheers,
Antonio Maña.

-- 
                                                           ___
      /---------------------------------------------------/   |
     /            _   ,                                  / /| |
    /   Dr. Antonio Mana Gomez  eMail: [email-masked]   / / | |
   /                                   [email-masked]   / /  | |
  /             http://www.lcc.uma.es/~amg            / /__ | | __
 /---------------------------------------------------/_//  ||_|/  |
     /  University of Malaga.  Computer Science Dept.  /   |  /   |
    /    E.T.S.I.Informatica.        Desp. 3.2.7      / /| | / /| |
   /               Campus de Teatinos.               / / | |/ / | |
  /               29071 MALAGA (SPAIN)              / /__|   /  | |
 /-------------------------------------------------/_// /|__/   |_|
    /           Phone: (+34) 95 213 71 42            / /  _
   /            Fax: (+34) 95 213 13 97             / /  | |
  /      Alternative  Phone: (+34) 95 213 41 86    / /___| |
 /------------------------------------------------/________|

> 
> I am in complete agreement with you, Lynn.  An industry-specifc
> identity should be designed to perform only a single function -
> authenticate the holder of the credential.  Authorization must
> ALWAYS be determined by the context that has successfully
> authenticated the entity - and those authorization rules must
> always be owned and controlled by the context owner.
> 
> There are some assumptions I make wrt industry-specific identities
> (not exhaustive):
> 
> a) They are used only in an online context; while certificates
>     can be used perfectly well offline too, the RP has greater
>     assurances when used only within online contexts.  Given the
>     nature of the always-online Internet and the services that are
>     being built on top of it, this is not an unreasanable assumption
>     anymore;
> 
> b) The single credential for the individual will suffice regardless
>     of the value of the transaction; this implies that the level of
>     assurance that needs to be built into that credential is high,
>     thereby increasing the initial cost of issuance.  However, since
>     that cost is spread out across an entire industry (hopefully, for
>     a very long duration) the actual cost borne by the industry per
>     credential will be lower than for any individual company within
>     that industry. The advantage for any given company to sign up to
>     this model?  All companies within that industry have the same level
>     of assurance in the credential for any level transaction.  (There
>     are other advantages too).
> 
> c) Since the credential is industry-specific, each industry will come
>     up with its own identifier per entity (besides the unique certificate
>     DN in the credential) that will be completely unrelated to other
>     identifiers in other industries.  This, coupled with more secure
>     practices in systems management, data-management & software
>     development will eliminate the privacy issues.  It will make no
>     difference whether you know my Social Security Number, birthdate
>     or my mother's maiden name, because modified business practices
>     (based on these new credentials) will eliminate the value of this
>     data to identity thieves.  Will other data become just as valuable
>     to the thieves?  Almost certainly, but they're also going to have
>     to steal the physical device that stores my industry-credential
>     along with the PIN that I carry in my head to unlock the device.
>     The risk is never eliminated, but the probability of damage is
>     reduced.
> 
> I do not deny that there are lots of other issues that need to be
> addressed (I'm in the middle of writing a much more comprehensive
> treatise to discuss these), however, given the losses borne by
> consumers (ultimately) - $53B in 2003 according to the FTC
> http://www.ftc.gov/opa/2003/09/idtheft.htm, I believe the issue
> has become costly enough to consider a radical overhaul of America's
> identity infrastructure.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> 
> 
> [email-masked] wrote:
> > 
> > 
> > 
> > it isn't necessarily just authentication that a relying party may have to
> > worry about with regard to the operation that they might be trusting the
> > certificate for .... but also things like authorization. the concept of a
> > certificate is that the relying party can trust the certificate in an
> > offline environment w/o necessarily any recourse to any additional
> > information.
> > 
> > the issue of recourse to additional information may because of things like
> > 
> > 1) privacy .... the early x.509 "identity" certificates were found to
> > represent signficiant privacy compromise, especially when broadcasting all
> > of the place. as a result, there was retrencement to relying-party-only
> > certificates .... where it was sufficient to authenticate the entity as
> > being authorized to perform some set of operations against some account
> > record.
> > 
> > 2) value ... the transaction is of sufficient value and/or complexity that
> > it is worthwhile to perform a online transaction (as opposed to an offline
> > operation purely relying on the contents of a certificate).
> > 
> > Note, however, that majority of relying-party-only certificates were used
> > in operations involving some value and therefor justified an online
> > operation with access to timely and/or aggregated information (aka
> > sufficient funds to actually cover a financial transaction).
> > 
> > 3) authorization ... the issue may not have anything at all to do with your
> > identity, but whether or not you can be authenticated (not identified) as
> > being an authorized employee or an authorized individual to perform
> > transactions against a specific bank account. Just because I can proov I'm
> > John Smith ... isn't sufficient to establish that I'm an authorized
> > employee of any specific corporation and therefor entitled to enter an
> > employee only area.
> > 
> > It isn't context-sensitive identity infrastructure ... they require
> > context-sensitive authorization (although sometimes there is significant
> > confusion and institutions build identity infrastructures that are totally
> > orthogonal to their need for authenticationa nnd authorization
> > infrastructures).
> > 
> > In many of these situations, then stale, static certificates can be totally
> > redundant and superfluous ... either because they are providing information
> > that has no direct bearing on the operation being performed by the relying
> > party and/or because the relying party will be doing an online operation
> > with the authoritative agency providing real-time and/or aggregated
> > information (not possible with a stale, static, offline certificate).
> > 
> > 
> > [email-masked] on 4/2/2004 2:39 pm wrote:
> > 
> > I would concur with you, Steve, that a single certificate that serves all
> > purposes, is neither practical nor desirable.  (Although I must confess
> > to occassionally dreaming of such a utopian environment, sometimes).
> > 
> > However, I believe, it is reasonable - assuming appropriate policy,
> > process, implementation and most importantly, cooperation - to have
> > industry-specific identities that may serve us all better.  ("Identity
> > Firewalls" - http://www.strongauth.com/newsletters/2003Jan17.html).
> > 
> > Companies waste far too much time and money today, building
> > duplicate identity infrastructures - and consequently tying their own
> > hands with context-sensitive identities - because it appears to be the
> > path of least resistance to them.  But as the cost of identity theft &
> > of managing those numerous identity infrastructures surpasses the
> > perceived savings from using this path of least resistance, companies
> > will be forced to rethink that strategy.
> > 
> > Arshad Noor
> > StrongAuth, Inc.
> > 
> 
> 

------------------------------------------------------
Mensaje enviado desde el Servidor de Correo del
Departamento de Lenguajes y Ciencias de la Computacion
de la Universidad de Malaga
------------------------------------------------------

---

From: Eric Norman <[email-masked]>
Date: Sat, 3 Apr 2004 14:35:50 -0600 (CST)

> then "Attribute Certificates" linked to a single "Identity Certificate" are

If a relying party needs to know that I possess certain attributes, and
if I can present an "Attribute Certificate" that convinces them that I
do indeed possess those attributes, then what purpose is served by also
having me present an "Identity Certificate"?

> these are related to privacy, anonymity and sometimes legal reasons.

And I'm considering the possibility that there might be reasons to have
fewer than one identity certificate.

Eric Norman

	"Congress shall make no law restricting the size of integers
	that may be multiplied together, or the number of times that
	an integer may be multiplied by itself, or the modulus by
	which an integer may be reduced".

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 2004 10:22:31 -0400

>having me present an "Identity Certificate"?

Eric, recall that an attribute cert does not contain a public key, so 
presentation of an attribute cert does not provide a secure 
association between the presenter and the cert.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 2004 11:15:59 -0400

>Identity, and I will come to that later, but let's assume for now that only

See the recent National Research Council report: "Who Goes there? 
Authentication Through the Lens of Privacy" for a detailed discussion 
of why there is not really ONE identity for an individual, in the 
sense that we're discussing here.

Steve

---

From: Arshad Noor <[email-masked]>
Date: Tue, 06 Apr 2004 22:33:08 -0700

Antonio, some comments inline.

> opinion these are not "identity certificates" but "attribute certificates". 
	By proposing identity firewalls between industry-specific certs,
	I did not imply that any attributes would be associated with the
	identity (other than the basic DN, public key, key usages, etc).
	Although, each industry will almost certainly have some basic
	attributes implied, the advantage for the industry would come
	from having the minimum information in the identity cert to
	assure an RP of the identity, and leave the RP to address what
	information they needed to have to make authorization decisions.

	So, one could get oneself a Financial industry credential, for
	instance, by going through the industry's issuance process, and
	yet not have a single bank/brokerage account at all (not very
	useful, I realize - nonetheless that is the premise).

	This individual, armed with the Financial credential, can now
	approach any financial institution that honored the credential,
	and open an account.  However, depending on the context of the
	account & the transactions the individual may wish to carry out
	against that account, the financial institution may want to
	determine a number of attributes about that individual before
	granting him/her that privilege.

	But the authorization process - which, as you rightly point out,
	now depends on the attributes associated with that individual -
	should be completely distinct from the identification process,
	and must be in the control of the context owner.

> then "Attribute Certificates" linked to a single "Identity Certificate" are 
	While Attribute Certficates appear to have some appealing
	characteristics, there are a number of competing technologies
	that may appear less daunting to corporate developers currently.

	LDAP-based Directories, for instance, allow a rich set of ACI's
	that can be used to build authorization frameworks.  Since a
	vast majority of authorization decisions will occur within
	"closed" networks, it may turn out to be far more cost effective
	to build such frameworks out of LDAP-based Directories than AC
	based infrastructures.  It is difficult enough getting companies
	to deploy regular PKI's correctly - and use them appropriately -
	without adding the complexity of Attribute Cert infrastructures.

	I realize that there may be situations where AC's may be more
	effective, but I haven't seen a convincing business example that
	cannot be implemented more effectively - and just as securely -
	with LDAP-based Directories, at lower costs.

Arshad Noor
StrongAuth, Inc.

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 7 Apr 2004 10:34:38 +0200

Arshad,

>useful, I realize - nonetheless that is the premise).

Absolutely, this is BTW already a reality in Scandinavia.

>granting him/her that privilege.

I would extend this to include *any* relying party that is prepared
to trust FI-issued credentials.  e-governments are the first to make
use of this.

Now, to the more general use of FI-issued identity credentials.
The need for certificates specifying employment or similar is
greatly exaggerated which is proven by the fact that the current
"authentication standard" (userid/password), does not force you
to specify "John Doe, Marketing, IBM, Armonk, US" but rather
"JohnDoe34" (and maybe a domain) as the various backend
systems already have all other information needed to authorize
access to the different internal systems.

The use of employment-style certificates outside of the company
border is never going to happen on a wider scale because that idea
is conceptually completely flawed.  Well, an IBM company badge
may indeed give you 10% discount at Tony's Pizza, but that's about it.

>with LDAP-based Directories, at lower costs.

I agree 100%.

rgds
Anders R

---

From: Arshad Noor <[email-masked]>
Date: Wed, 07 Apr 2004 20:40:35 -0700

> Absolutely, this is BTW already a reality in Scandinavia.
	If there are any pointers to websites that describe how
	Scandinavia implements this, Anders, I'd appreciate it.
	Thank you.

> to trust FI-issued credentials.  e-governments are the first to make
	I would specifically NOT, Anders.  Here's why.  One of the
	biggest reasons why identity theft is so prevalent today, is
	because of the inappropriate use of identity data for secondary
	uses.  If a specific industry credential were restricted by
	policy and contract, to only companies within that industry,
	the consequences of a compromised credential is restricted to
	only uses within that industry.  Thus, if a FI credential was
	compromised, only the holders banking, brokerage, insurance
	uses might get affected.  The credential that identifies them
	to hospitals, doctors, pharmacies would not.  Neither would the
	credential identifying them to schools, colleges & professional
	associations.  Thus the term "Identity Firewall".

	Even though it is technically, as well as contractually,
	possible for cross-industry uses, by deliberately putting up
	protection barriers between industries, we prevent the
	domino-effect of the compromise of a credential.

> may indeed give you 10% discount at Tony's Pizza, but that's about it.
	In fact, it should not be allowed to happen.  If an airline, a
	hotel or a store wished to give specific company employees a
	discount, let them rely on the Retail Industry credential, or
	issue their own certificate to be stored on the RI smartcard
	or other crypto token.  The principle is the same - if we do
	not allow compromises to cross industry boundaries, then the
	damage is limited to only that industry.

Arshad Noor
StrongAuth, Inc.