Subject: RE: The Bank-model Was: Employee Certificates - Security Issues

From: "Särs, Camillo" <[email-masked]>
Date: Wed, 9 Oct 2002 10:52:33 +0300

>I can have an individual certificate 'J Adrian Pickering' that 
>I obtain, perhaps issued by a government authority much like a passport. 

In that case, you would only want to ever use that certificate in use cases
where an official proof of citizenship is required.  Any use beyond that use
case violates the principle of least authority.  It also exposes you to may
privacy risks.  In my layman interpretation of EU privacy directives, it may
also be illegal.  (Admittedly, I blatantly disregard the fact that even some
EU efforts in the above direction exist.)

> When I work for Company X in role Y, the Company issues me with an
appropriate 
> attribute certificate. The two, when used together, are applied to Company 
> transactions and are understood by the recipient to mean 'this 
> individual has signed this transaction on behalf of company x in their 
> role as y'. 

This model unnecessarily ties two unrelated facets of your identity to each
other.  If used as such, when you sign something on behalf of company x, you
are as a matter of fact *also* attesting to your citizenship in country z.  I
fail to see why this would be necessary or even desired.

> This is just like a traditional legal document where an 
> individual signs and it is endorsed by the company seal.

This is *incredibly* unlike traditional legal documents.  It is a brilliant
example of why comparing PKI with traditional signatures proves why "analog
<-> digital" analogies are so dangerous.

In many jurisdictions, there is little formal requirements on an individual
signature.  There may be requirements on a company seal.  But I digress.

If I work for Company X in role Y, I would expect the company to issue me
with an appropriate identity certificate [possibly anonymous].  The company
might choose to initially require me to present a government issued identity
certificate to establish my "true identity", but beyond that point my
citizenship in "z" is fairly irrelevant to the company. I would also be
granted an attribute certificate for role Y, tied to identity X.  All this on
the assumption that the company would use X.509-type identity certification.

In reality, in my current roles, I would probably have to have several
identity certificates.  My "identity" varies depending on whom I am talking
to.  Right now, I am writing this email as a personal message in my role as
security researcher.  I would prefer not to sign such a message with an
identity certificate that would also be used to sign official company
statements, because the deployed X.509 S/MIME infrastructure does not support
attribute certificates.

The entire concept of trying to issue an "identity certificate" that is
useful in many contexts seems misguided to me.  Such a certificate would
quickly grow to become a dossier.  Personal dossiers are necessarily highly
confidential.

> I am still free to sign 'cheques' with my personal certificate whether I'm
in 
> the employ of the company or not.

I would not sign cheques with a passport [pardon the bad analogy].  Actually,
it seems fairly evident from litterature that cheques need not be tied to
identities in any meaningful way.  Cheques are only concerned with the matter
of credit.  If I would create a [public-key based] system which attests to
valid credit without using identities, it would serve me well.

> Apologies in advance if I'm beating an old drum,

Apologies in advance if I'm doing the same.

Regards,
Camillo Särs
-- 
Camillo Särs <[email-masked]>          http://www.iki.fi/ged/
Senior Security Researcher, F-Secure Corporation  http://www.F-Secure.com

          F-Secure products: Securing the Mobile Enterprise

---

From: [email-masked]
Date: Wed, 9 Oct 2002 08:35:06 -0600

to some extent the PKI model is patterned after offline credit cards of the
'60s ... except substituting offline electronic bits in place of plastic &
paper. Except for legacy compatibility, the infrastructure migrated to a
online, electronic model in the '70s ... while PKI in the '80s somewhat
took a step backward to an offline, electronic model. Part of the '80s PKI
issue was addressing offline email (download email, hangup need some way to
authenticated w/o having any sort of online connectivity).

In the 90s there was some activity expanding certificate information for
the business market to emulate signing limit checks .... and various pieces
of that information has migrated to some of the attribute certificate
efforts. The point of the signing limit checks was to provide some means to
distribute/allow certain employee purchasing capability while still
limiting some of the earlier fraud activities (letter head or employee ID
based, w/o incuring the overhead of purchasing department approval).

The relative benefit of the signing limit checks was that there was some
small control on the total number such checks a person might posses ...
while current attribute certificate technology bascially allows an
attribute certificate to be re-used an unlimited number of times. However,
even in the case of signing limit checks ... there was still fraud
appearing using multiple such checks to bypass total aggregate controls
(aka a person using 200 $5000 limit checks to make million dollar
purchases). In part, the migration to purchase cards was in response to the
type of fraud with (attribute certificate analogous) signing limit checks
.... using the online electronic model enables (real-time) aggregation &
velocity controls (aka X amount total per month, etc) in addition to
optional other controls available from level3 data .... merchant, merchant
location, SKU.

Straight attribute certificate could be a return to just letterhead type
fraud ... or with a little additional information, they could approximate
checks with signing limit type fraud .... although in some ways the
repeated use of an attribute certificate is simpler than fraud involving
the repeated use of signing limit checks.

At its simplest, the financial industry X9.59 standard adds the benefit of
digital signature authentication & integrity to existing payment cards
(credit, debit, purchase, stored-value) within the context of existing
online electronic business controls .... w/o having to take a
step-backwards to an electronic, offline model.

misc.
http://www.garlic.com/~lynn/subtopic.html#privacy
http://www.garlic.com/~lynn/subtopic.html#fraud
http://www.garlic.com/~lynn/subtopic.html#rpo
http://www.garlic.com/~lynn/index.html#x959

In that case, you would only want to ever use that certificate in use cases
where an official proof of citizenship is required.  Any use beyond that
use
case violates the principle of least authority.  It also exposes you to may
privacy risks.  In my layman interpretation of EU privacy directives, it
may
also be illegal.  (Admittedly, I blatantly disregard the fact that even
some
EU efforts in the above direction exist.)

appropriate

This model unnecessarily ties two unrelated facets of your identity to each
other.  If used as such, when you sign something on behalf of company x,
you
are as a matter of fact *also* attesting to your citizenship in country z.
I
fail to see why this would be necessary or even desired.

If I work for Company X in role Y, I would expect the company to issue me
with an appropriate identity certificate [possibly anonymous].  The company
might choose to initially require me to present a government issued
identity
certificate to establish my "true identity", but beyond that point my
citizenship in "z" is fairly irrelevant to the company. I would also be
granted an attribute certificate for role Y, tied to identity X.  All this
on
the assumption that the company would use X.509-type identity
certification.

statements, because the deployed X.509 S/MIME infrastructure does not
support
attribute certificates.

> I am still free to sign 'cheques' with my personal certificate whether
I'm in
> the employ of the company or not.

I would not sign cheques with a passport [pardon the bad analogy].
Actually,
it seems fairly evident from litterature that cheques need not be tied to
identities in any meaningful way.  Cheques are only concerned with the
matter
of credit.  If I would create a [public-key based] system which attests to
valid credit without using identities, it would serve me well.

Regards,
Camillo Särs

---

From: [email-masked]
Date: Fri, 11 Oct 2002 15:17:52 -0600

semi-related posting in spki mailing list
http://www.garlic.com/~lynn/aadsm12.htm#33 two questions about spki

---

From: "Hamrick, Matt" <[email-masked]>
Date: Sun, 13 Oct 2002 15:34:19 -0400

-----BEGIN PGP SIGNED MESSAGE-----

Alzo Spracht Anders Rundgren:
>Matt,
>There is a short explanation and that is that a trivial thing like
>a purchase order involves at least three parties (purchaser,
>purchaser organization and supplier) while PKI only supports
>two parties (end-entity and relying party).

Okay... this is totally understandable. There were many such
discussions in the CORBASec community when talking about
client-server technologies like SSL/TLS.

>The Enterprise model does not take this in account which is
>the reason why few if any business system vendors support
>the Enterprise model.

>The Bank model addresses this by using multiple more
>or less independent PKIs.  The Bank model needs as a
>minimum one X.509 certificate and key per organization.
>Due to the Bank model's "non-personal" way of working,
>it is seldom relying on X.500/LDAP-support except for
>internal use.  UDDI registries are probably more
>conformant with future needs of the Bank model.
>The Bank model minimizes the need for publishing (or
>leaking) information concerning employees, as a key element
>of banking is, and has always been, client integrity.

UDDI registeries seem to have similar problems to X.500/DAP/LDAP
directories. The primary one being a name-space issue. When there are
more than two entities that want to interact, the semantics of naming
issues can get complicated. With DAP/LDAP, most of the naming issues
tend to be structural; some people want RDNs to be "rich" with a
highly branchified DIT, other people want a flat naming structure.
With UDDI, naming issues seem to incorporate more functional aspects,
leading to even more confusion when more than two parties
interoperate. It's my belief that the fundamental flaw with web
services is the lack of a canon for the semantics of meta-data in
UDDI. But, then again, I haven't really looked at v3 of UDDI, and
it's a little off-topic anyway.

I think I'm tracking you on the whole enterprise-model/bank-model
thign, but I'm somewhat confused still about one point. When a
digital bearer instrument (such as an electronic purchase order)
leaves an orgainization, it if is shrouded in the bank's keys in such
a way that the keys of the individual inside the bank that
origininated the transaction is unseen, why should we care what the
bank's internal DIT schema looks like? Or rather, it seems to be an
issue only if there's delegation going on, which is what you seem to
be arguing against.

>The Enterprise model is based on the defunct X.500 vision
>where we all would be a part of a giant PKI and published
>in a globally accessible directory.  This is would be OK
>if "e-business" were equivalent to sending signed and
>optionally encrypted e-mail, using Outlook etc.
>But, AFAIK, this is miles away from where the
>e-business industry in general is headed.

Aye.. 'twas a bit of a pipe dream to think that we would all "PEMify"
ourselves into a global PKI. It would be nice if it was doable, but
clearly it would officially require EVERYONE in the world who wanted
to participate to adhere to the same or similar CPs if not CPSes. I'm
not entirely certain that I would go so far as to say that the
"enterprise model" is based on X.500, but clearly the concept of the
global X.500 is dead.