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

[lynn.wheeler@xxxxxxxxxxxxx]

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


sars. camillo <camillo.sars@xxxxxxxxxxxx> on 10/9/2002 1:52 am wrote:

>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 <Camillo.Sars@xxxxxxxxxxxx>          http://www.iki.fi/ged/
Senior Security Researcher, F-Secure Corporation  http://www.F-Secure.com

          F-Secure products: Securing the Mobile Enterprise