Subject: RE: Employee Certificates - Security Issues

From: "Hamrick, Matt" <[email-masked]>
Date: Thu, 10 Oct 2002 16:50:19 -0400

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

Anders,
        I've just got to chime in here... A few things to consider:

1. It is generally not the case that anyone with a credit card with a
$1000 credit limit may repeatedly charge $999 with wild abandon.
Merchants who do not use an on-line credit card verification system
are severely limited by contract as to the types of charges that may
be applied to a particular account. Merchants with online credit card
verification systems are required by contract to check the available
credit on an account before accepting it as payment. To ignore either
contract point causes the MERCHANT to be stuck with the bill as the
settling banks will be more than happy to not reimburse merchants
that do not honor their contractual obligations with respect to
checking available credit.

It seems that if you have a PKI where an identity cert is issued to
an end entity, the use of that cert is STRICTLY to bind an electronic
representation of an identity to the public key associated with the
private key used in an authentication protocol. If you're creating
PKI where anyone with a PKC can charge up to $999 on an account with
a $1000 limit, well.. that's your own problem. My recommendation is,
"don't do that." It's as ridiculous as credit card companies assuming
that anyone with a signature is allowed to charge whatever they want.

2. Now lets assume that we have a system where a PKC identifies an
end entity (for some definition of "identification".) We could quite
easily establish a credit limit in the certificate, but I do rather
agree that this leaks too much information about the end entity, but
that's a privacy issue for another thread. Let's just say we want to
put it in an AC. Maybe we keep issuing these ACs every week or every
day or something. Inside the AC there might be a limited purchasing
authority attribute. It's important to note, that in relatively few
companies are general employees allowed to sign for the company. Most
companies I've worked for, contracts may only be signed by officers
of the corporation, or by their designated representatives. Were I
putting together a PKI/PMI for B2B, I would probably include a review
or financial controls process where a buyer would perform a search,
find the thing they're looking for, click on a button that says
"generate a sales contract" that includes a quote, a delivery date,
and an expiration date, then send the digital contract to whoever is
"up the food chain." That person would then authenticate the purchase
by issuing an AC that specifically references the contract.

While I agree with you that DTDs with XML are probably better for a
lot of reasons than asn.1 and BER encoding, I can't say that I
totally agree with the implicit argument that we shouldn't use X.509
ACs ever. (Some on this list might be snickering, because they might
have heard my statement at last years ISOC conference that X.509 was
totally inappropriate for use in constrained environments.)

3. XML is wonderful. XML is great. All hail XML, the ASCII of a new
millennium. It is a representation format, just like asn.1 and
BER/CER/DER/XER, etc The largest problem with XML is that it does
nothing to address the semantics of signature production. XML by
itself does not tell you what it means to be signed. X.509 is pretty
murky on some of the issues, but by repeatedly reading the
specification and reading the graffiti on the walls at IETF meetings,
you get the idea that a X.509 PKC is an identification vehicle, and
that most extensions or attributes are there primarily to support the
identification goals. XML DSIG is coming along, but it's still not
ready for prime time (if you disagree, let's start a flame war
somewhere else...) SAML also shows great promise. The Semantic Web
efforts show great promise. Personally, I look forward to the day
that we'll be able to replace asn.1/BER with something better. I'm
just not sure that XML is there yet.

- -----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Friday, October 04, 2002 4:58 PM
To: Roberto Opazo; [email-masked]
Subject: Re: Employee Certificates - Security Issues

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,

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,
> 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: "Anders Rundgren" <[email-masked]>
Date: Fri, 11 Oct 2002 21:12:56 +0200

Matt,
This thread has many issues.  What makes this so extremely
hard to discuss in a constructive way is the fact that by
looking at one issue at a time (like transaction limits),
you don't get the whole picture.

One issue is security.
One issue is privacy.
One issue is control of users.
One issue is archiving of operations.
One issue is PKI in conjunction with existing information systems.
One issue is compatibility with existing client-standards.
One issue is authority management.
One issue is TTP CA support.
One issue is user-convenience.
One issue is legal validity.

None of the issues above except for legal validity and security
[in the cryptographic sense only], are addressed by a static,
client-centric "enterprise model" according to the lines of the
US federal PKI and HEPKI to take some real examples.

I claim that the "bank model" as sketched in another posting has
_reasonable_ answers to all these issues and also allows a higher
flexibility by _simultaneously_ supporting a wide range of options
within a single organization. 

The bank model supports full-end-to-end-security-all-privacy-lost
for really important agreements, to the very elementary (but pretty
efficient) where outgoing data just gets a "stamp" of authenticy.
By building on the bank model, you don't have to have an answer
on how to handle every possible case (we already do?) as you can
adjust things with ease (well...) at the _server_ level.

Note: The bank-model was invented around 1700 and has recently
been recast into electronics.

cheers,
Anders

----- Original Message ----- 
From: "Hamrick, Matt" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, October 10, 2002 22:50
Subject: RE: Employee Certificates - Security Issues

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

Anders,