Subject: RE: Employee Certificates - Security Issues

From: "Guida, Richard [JJCUS]" <[email-masked]>
Date: Fri, 4 Oct 2002 11:24:20 -0400

Thanks, Anders, always good to be forgiven, although I usually hope to get
that from a cleric.  I think it is safe to say we have a different
world-view on how electronic signatures are actually used in intracompany
and intercompany commerce.  Digital signatures remain the strongest method
for that purpose, but like any tool, a relying party can misinterpret or
misuse a received dig sig just as he/she can misinterpret or misuse any
other form of e-signature or wet signature (if we were to eschew a
technology just because it has the potential for misinterpretation or
misuse, life would be somewhat less interesting).  Regardless, one can use
certificates (as you know) for much more than just e-signatures - they can
also be employed for user authentication and data confidentiality.  I know
of no single credential type or infrastructure which supports all of those
functionalities in such a robust fashion.  I use my company-supplied
signature and encryption certificates (and of course the private keys
corresponding the public keys in those certs) dozens of times every day,
with many internal applications as well as externally facing ones, so the
technology is real and it has arrived.  So rather than theorizing about
things, let's see how the marketplace really evolves.  PKI was going to the
savior of us all (no), then it was deemed to be next to useless (also no),
the truth is inbetween.  As an engineer, I firmly believe that the devil is
in the details of any security infrastructure; with that in mind, PKI
affords the firmest foundation upon which to construct a security framework.
But like any foundation, one has to build appropriate structures on top of
it - like privilege management and authorization functionality - to have a
full solution.  Best regards -- Rich

Richard A. Guida
Director, Information Security (Medical Devices and Diagnostics)

Johnson & Johnson
One J&J Plaza, Room WH6132
New Brunswick, New Jersey  08933

E-mail: [email-masked]
Office:  732 524 3785

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Friday, October 04, 2002 10:37 AM
To: Guida, Richard [JJCUS]; [email-masked]
Subject: Re: Employee Certificates - Security Issues

Richard,

>Anders - forgive me but you have a simplistic and incorrect view of
>how things really work.  

I forgive you.  But don't forget that the outside world does not have
this granularity.  It is probably even more "simplistic" than I am :-)

>A digital identity certificate proves (to whatever degree the certificate
>policy underlying it affords) identity. 
>It does not prove authority to take an action. 

Agreed, but what about purchase orders to take a simple example.
If the partner (the employee's organization) is already a customer, I
would say that most orders would be expedited as the identity of
the employee is of secondary importance.  That the purchase order
was created on a market-place somewhere and that the employee
"forgot" to notify purchasing about it, is an example of a very low-
quality IT-architecture that I would not spend a penny on. 

That my company can sue me _after_ they filed for bankruptcy
due to my ordering of that big 4WD-car is a limited comfort. 
Using the Internet-bank model I would have not been able to do
this purchase at all.  It is always _much_ cheaper to solve
problems _before_ they are actually created :-)

cheers,
Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 4 Oct 2002 18:24:21 +0200

Richard,
I think you have mostly misinterpreted my messages.

Employee-PKI means (I do at least), that the employee has a certificate
that allows him/her to act on behalf on their employer.  This is
a fundamental characteristic of the US Federal PKI and commercial
efforts like Identrus.

What I'm saying is that this opens the organization to massive
and non-controllable attacks from disloyal employees etc.  It is a
smart as giving the entire work-force company credit-cards.  

Regarding the market, it is interesting to note that there is not a
business system maker of any significance that support a model
where the client's certificate and signature is a part of _outgoing_
messages.  In the same way as there is not a single bank in the
world that does this either.  And this fact is completely independent
of the availability of client-side PKI.

Note: Client-side PKI is absolutely not a bad idea, it is
the idea to hand over specific "company keys" to employees
that is not such a terribly good idea.

Anders

---

From: "Roberto Opazo" <[email-masked]>
Date: Fri, 4 Oct 2002 16:15:00 -0400

Hello everybody,

This tread is just showing some of the problems you can have when mixing a
public key certificate (PKC) with an attribute certificate (AC), the
solution is very ease: Do not do so.

RFC 3281 states:
“Some people constantly confuse PKCs and ACs.  An analogy may make the
   distinction clear.  A PKC can be considered to be like a passport: it
   identifies the holder, tends to last for a long time, and should not
   be trivial to obtain.  An AC is more like an entry visa: it is
   typically issued by a different authority and does not last for as
   long a time.  As acquiring an entry visa typically requires
   presenting a passport, getting a visa can be a simpler process.

   Authorization information may be placed in a PKC extension or placed
   in a separate attribute certificate (AC).  The placement of
   authorization information in PKCs is usually undesirable for two
   reasons.  First, authorization information often does not have the
   same lifetime as the binding of the identity and the public key.
   When authorization information is placed in a PKC extension, the
   general result is the shortening of the PKC useful lifetime.  Second,
   the PKC issuer is not usually authoritative for the authorization
   information.  This results in additional steps for the PKC issuer to
   obtain authorization information from the authoritative source.”

Now than we have a standard to solve this problem, lets use it!

We need applications using this standard, not another discussion to define a
new standard, to need again, applications using the new standard. We could
repeat this circle as many times as we want.

Best regards,

Roberto Opazo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Anders Rundgren
> Enviado el: viernes, 04 de octubre de 2002 12:24
> Para: [email-masked]; Guida, Richard [JJCUS]
> Asunto: Re: Employee Certificates - Security Issues
>
>
>
> Richard,

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 4 Oct 2002 22:58:09 +0200

Roberto,
May I challenge this a bit?

Assume that a purchaser had a PKC + AC where the AC in some
way says that the purhaser has a $1000 limt.  By doing multiple
purchases at $999 the purchaser made this information useless.

Static solutions to dynamic problems is not a "hit".

That's one reason why ACs are unlikely to become very important.

Another reason is that most sophisticated information systems today are
built on XML which is superior for ACs as there is both a human-
readable format (almost at least), and even more important, there is
the powerful  XML "Schema" language.

cheers,
Anders

----- Original Message ----- 
From: "Roberto Opazo" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 04, 2002 22:15
Subject: RE: Employee Certificates - Security Issues

Hello everybody,

RFC 3281 states:
"Some people constantly confuse PKCs and ACs.  An analogy may make the

   obtain authorization information from the authoritative source."

Best regards,

Roberto Opazo

---

From: Michael Ströder <[email-masked]>
Date: Sat, 05 Oct 2002 15:27:29 +0200

> purchases at $999 the purchaser made this information useless.

What does the $1000 limit mean? You did not specify the limit completely as 
you did not specify a business process behind it. Therefore I can't follow 
your argument.

> That's one reason why ACs are unlikely to become very important.

As I stated in a former posting quite a while ago there's not much sense 
putting a general $$$ limit into an AC. But I wouldn't conclude from this 
that ACs in general do not make sense. (I believe that ACs won't fly because 
we don't even have a seriously working X.509-based PKI for PKCs. But that'a 
another story...)

> the powerful  XML "Schema" language.

Blah... even if you're right the reduction of the business-oriented 
discussion to the long-lasting technical fight XML vs. ASN.1 only shows lack 
of conceptual ideas.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Sat, 05 Oct 2002 15:19:02 +0200

Anders Rundgren wrote:
> that allows him/her to act on behalf on their employer.

Nope!

As others already stated you're wildly mixing authentication and authorization.

BTW: Anders, go into a big group (e.g. consisting of around 300+ companies) 
and ask people for a general long-lasting definition of "employee" e.g. in 
opposite to external workers. You won't get a good definition.

>  This is

Don't know about 'US Federal PKI' but AFAIK 'Identrus' is not an employee 
PKI at all.

> smart as giving the entire work-force company credit-cards.  

Again: You're wildly mixing authentication and authorization.

Ciao, Michael.

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 5 Oct 2002 17:30:32 +0200

Hi Michael,

>As others already stated you're wildly mixing authentication and authorization.

I do, as I look on this from a real-world-perspecitive.

For typical, high-volume, day-to-day tasks in many commercial enterprises,
the concept of authorization is an internal issue.  E.g. purchase orders
and invoices are by [de-facto] definition "authorized".

That means that for receivers it does not really matter if an order
is signed by John Doe today, and by his replacement Jane Doe tomorrow.
What is important is that the organizational part of the identity
stays the same.  Sounds primitive?  As there is no X509-way to
express purchaser authority what else can you do?

However, by using the Internet-bank approach there is not a
chance for an unauthorized person to create a valid purchase
order.  By doing that, authorization can continue to [mostly]
be an internal issue, with the difference that it becomes
trustworthy as well.   This though excludes the use of true
end-to-end PKIs for employees like the ones represented
by the US Federal Agency and Identrus.

<snip>

cheers,
Anders