Subject: Re: Employee Certificates - Security Issues

From: [email-masked]
Date: Fri, 4 Oct 2002 07:31:45 -0600

there were (at least) 2-3 reason for relying-party-only certificates
(basically only an accont number and a public key .... and no other
information)

1) privacy .... even just a person's name (and no other information) is a
serious privacy concern for retail financial transactions .... EU directive
that electronic retail financial transactions sould be as anonomous as cash
.... any personal information in a certificate is major privacy issue.

2) liability .... your point ... that they wanted absolutely no
misunderstanding that the certificate would convey or imply anything ...
the certificate was purefly a convienient bit-string required for
conforming to COTS digital signature software (see #3)

3) most COTS easily available digital signature software required a
certificate to exist ... even tho the actual business process transactions
were online ... not offline ... so from a business and information flow ...
the existance of a certificate was redundant and superfulous ... purely an
artificial artifact of the COTS digital signature software that was easily
available.

insitutions doing online transactions between themselves and their member
entities (clients, account holders, employees, etc) will typically directly
refererence the actual trust repository .... a R/O, stale, subset copy of
such information is typically only useful for offline, low/no value
operaions (by definition, most value operations easily justify access to
near real time or aggregated data).

A simple example would be a supplier/customer relationship would be
embodied by an account record representing various things typically might
be found in contract T&Cs ... possibly limits, payment terms, negotiated
prices, volumes, etc.

Similar information might be for employees ... they could be given a
hardware token ... that for some no/low secure external doors .... operate
the unlocking of the door in offline mode (the existance of the token is
sufficient for unlocking low-security external door). Higher security
access is likely to migrate to things like online door access operation
that supports being able to fire & revoke access in real time.

[email-masked] on 10/3/2002 11.25 pm wrote

"I, the Company"

When employees have been equipped with digital certificates,
linked to the organization, interesting things happen: Employees
can now sign on behalf of the organization.  Due to the absence of
a generally understood X509 "authority" system, you can probably
sign whatever you want and an external receiver is meant to believe
that you have the right to do it.  This is probably as far from an
organization-adapted solution one can get (as organizations want to
have control over their internal and external actions), and is an
indication that this scheme is not suitable for large-scale deployment.

As a countermeasure one could think of having an
"authority control server" checking and logging all employee actions.
Unfortunately that does not work; if you have an employee certificate
you can fairly easy create messages that to receivers, look perfectly
valid without going trough the authority server.

Summary: An architecture that is fundamentally broken.
And, yes, I forgot to mention costs, privacy, archiving, and
the multitude of roots that you have to cope with.

Comments?

Anders Rundgren

---

From: [email-masked]
Date: Fri, 4 Oct 2002 07:54:24 -0600

there are two other scenarios given in
http://www.garlic.com/~lynn/index.html#aads

it is a traditional PKI but either

1) the Certification Authority is issuing a relying-party-only certificate
... however it is interested in saving bandwidth. It realizes that the
certificate will only be used in valid transactions with the institution
and that PKI allows for cached certificates .... so it pre-caches the
certificate original in the respective account record and saves the
bandwidth of sending a certificate copy back to the key-owner (and
eliminates the key-owner ever having to attach the certificate copy to a
transaction and return it to the certifying/relying party ... that already
has pre-cached the certificate original and therefor returning the
certificate copy to the entity that has the certificate original is
redundant and superfulous)

2) the Certification Authority is issuing a relying-party-only certificate
... however it is interested in saving bandwidth. It realizes that all the
fields in the certificate are already present at the relying/certifying
party and that there are PKI standards for compressing certificates. Using
the simple principle of knowledge compression, it is possible to "compess"
from the certificate fields that are already present at the
certifying/relying party. As a result, the certifying/relying party
compresses all duplicate fields from the certificate resulting in a zero
byte certificate. The key owner receives this zero byte certificate and
attaches it to every transaction.

Now as to the storage of the original certificate at the relying/certifying
party. Typically something like ASN.1 encoding is used for encoding the
certificate ... primarily for transmission and interoperability. However
since the relying/certifying party is just recording the information ....
after either 1) or 2) above ... the certifying party pre-decodes the ASN..1
encoding prior to storing the information (either 1) the original
certificate or 2) the individual fields).

anders.rundgren <[email-masked]> on 10/4/2002 3:15 am wrote:

No, the Internet-bank model does not require any "particular" client-
certificates, it is enough that you are recognized/accepted/trusted as
no traces of client certs ever leaves your bank.  You can use a "civil"
ID-card with no information about bank, employment etc.
A major Swedish bank is buying such from a TPP to take a example.
So could other organizations do as well.

---

From: [email-masked]
Date: Fri, 4 Oct 2002 13:32:33 -0600

the other way of looking at it ... is most certificates have been assumed
to be certifying something that an institution already knows (or has been
obtained by a TTP for use by other, relying parties).

In the case of a relying-only-party certificate ... where the institution
typically already has a business process in place that has vented the
information and it is stored in something like an employee record or a
client record .... or some similar type of record .... transposing a subset
of that information into a stale, r/o copy of such a record (aka into a
certificate) ... for their own use .... is frequently redundant and
superfulous and an artificial artifact of varous COTS digital signature
software that they might be using.

A r-p-o certificate needs little else than a reference to the account
record where the real, up-to-date information is stored ... and such
reference is aleady typically carriend in the main body of the signed
message and it is redundant to also carry it an additionally appended
separate signed message (called a certificate).
Additional information (other than a record locator) frequently can be
construed as a serious privacy issue (especially in consumer/retail
setting)

A non r-p-o certificate ... for others use,  is where some additional
information might need to be carried ... but that opens up the whole bag of
worms regarding privacy and liability and what if any (liability)
commitment is the certifying body making with respect to the information
carried in such a certificate ...

in otherwords

1) can i trust my own information that might also be carried in a redundant
& superfulous r-p-o certificate

2) what reason, if any, should anybody else trust any information carried
in a certificate (and if they were to construe any such information in a
financial/business setting is there implied liability)

one way of making sure there is no implied reliance on a r-p-o certificate
and therefor no implied liability (and/or even privacy exposure) ... is to
not actually every transmit such a certificate ... if it never actually
exists ... then it is hard for other parties to claim reliance (&/or
liability).

anders rundgren <[email-masked]> on 10/4/2002 10:24 am wrote:

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: Sat, 5 Oct 2002 20:32:34 +0200

Another thing worth mentioning in the context "employee
certificates", is extranet authentication.

As certificates do usually not contain "information" needed for
many relations, such data must be transferred out-of-band
or use POSTed HTML forms (where clients can fake the
information).

OASIS SAML and similar schemes allow information to
_securely_ be passed during authentication, where the information
may even be different for each extranet partner and relation.

So this, at one time considered "killer app", for employee
certificates is [also] mostly just a relic.

cheers,
Anders

---

From: "Guida, Richard [JJCUS]" <[email-masked]>
Date: Sun, 6 Oct 2002 17:19:23 -0400

Thanks for the suggestions, Anders, but I'm afraid life is a bit more
complicated than you posit.  Additionally, we do not want to tie our entire
security infrastructure (which the PKI underlies) to an outside source of
certificates.  We want to run our security infrastructure ourselves.  And I
think we have taken up enough bandwidth from others on this thread, so this
will be my last posting (and my apologies to those of you who have patiently
sorted through the e-mails wondering when the thread would be over; it is).
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: Sunday, October 06, 2002 10:00 AM
To: Guida, Richard [JJCUS]; [email-masked]
Subject: Re: Employee Certificates - Security Issues

Thanx Richard,

Note though that by using the Internet-bank model you can

- completely offload business parties from reading CPs
- give bosses and security officers the tools needed to monitor
   and control employees' external activities (regardless if they
   feel they need it or not)
- get automatic archiving
- essentially never have to transfer authorization data out-of-band
  as the Internet-bank model is an on-line system in contrast to the
  employee-PKIs' off-line paradigm
- deploy authorization schemes ranging from  the very basic which
  is the organization (rather than an employee), to sophisticated schemes
  using external authorities vouching for this and that
- easily add SAML for extranet authentication
- be compatible with coming e-business systems
- be able to efficiently manage a multitude of electronic business parties,
  long-term reducing costs
- increase "precision" and "trust" in your organizations' dealings with
  external parties

You current PKI would still operate and be worth preserving but would
never (when fully adapted), be the outermost (most authoritative) system
as the bank-model requires an organizational stamp in order to produce
an externally valid operation.

Also worth nothing is that this can be implemented now using existing
standard-technology, unlike end-to-end client-based PKI schemes
that today offers zero support for on-line authorization.  I cannot see
that it is even technically possible to obtain this functionality in
a client-based end-to-end PKI.

That this cannot happen overnight is for sure, but one can start
thinking about it at least.  Do some pilots etc.

cheers,
Anders

----- Original Message -----
From: Guida, Richard [JJCUS]
To: Anders Rundgren ; [email-masked]
Sent: Sunday, October 06, 2002 14:36
Subject: RE: Employee Certificates - Security Issues

Anders - this topic is not conducive to a full description in this thread,
too complicated and too easy to misinterpret.  So I have
to give you a simple and noncomplete answer: employees are trusted to use
their electronic credentials as they are trusted to use
other credentials issued them by the company.  If I took my company picture
ID and used it at a local merchant as proof of who I am
for writing a check, AND the merchant accepted that ID, is the company
liable if the ID were forged or if I just left the company
and "forgot" to turn it in (and the company failed to demand it be
surrendered)?  Same issue with certificates - if the relying
party wants to rely on a certificate: (a) without checking a CRL; and (b)
without checking the Certificate Policy (our CP explicitly
says the certs can only be used for J&J business and only establish
identity, do not established authorization to perform an act),
then the relying party is incurring the risk.  And the employee who is
improperly using the credential is subject to disciplinary
action (or if a former employee, subject potentially to charges of fraud).
Now I realize in the litigious U.S. the "deep pockets"
theory often results in large corporations being hit with liability
(responsibility) that they don't deserve, but thankfully that is
not true in much of the rest of the world.
As for security officers taking the approach of "we don't trust anyone,"
that is a bit simplistic.  I proceed from the premise that
the vast majority of employees want to do the right thing but may get
confused or may not know what "the right thing" is, so
training and awareness are paramount.  For those few who are miscreants, you
have to have in place an approach with overchecks and
safeguards to catch them before they can do much damage.  But to proceed
from the premise that every employee, given the
opportunity, will do something evil against his/her company is a scary
proposition.  I would not want to work for a company where
management holds that view - and I do not.
Authorization determinations are indeed handled "out of band," and hopefully
at some point we will employ SAML-based technology for
that purpose.  Authorization is (as you and others have commented) an
immensely complex topic, especially given legacy systems and
the fact that operating units (correctly) demand autonomy in making such
decisions regarding access to their own applications.
Authentication, by contrast, is far more straightforward.
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: Saturday, October 05, 2002 2:09 PM
To: Guida, Richard [JJCUS]; [email-masked]
Subject: Re: Employee Certificates - Security Issues

Richard,
It would be very interesting to know how J&J handles archiving
and authorization, as the conclusion from your answers seems
to be, "we trust all our employees for doing the right thing",
which BTW is in strong contrast to what security officers in
general say.  Not to mention bosses. :-)
In particular, how is authorization with respect to _external_
parties handled?  Based on out-of-band arrangements?
Although workable, I believe this is a very inefficient way to
perform "e-business", whatever the "business" is.
Anders
----- Original Message -----
From: Guida, Richard [JJCUS]
To: Anders Rundgren ; [email-masked]
Sent: Friday, October 04, 2002 21:30
Subject: RE: Employee Certificates - Security Issues

Anders - I don't think I misunderstood.  Your last e-mail makes the point
very well - you say that a company PKI is as bad as giving
employees company credit cards.  Well - I had a government credit card when
I worked for the USGovernment (as did almost everyone
else - at least those who traveled which was almost everyone, very few
exceptions), and I have one from my current employer as well
(again the majority of employees do).  Same is true for every company which
I know through professional affiliation.  So I agree
with the implication of your logic - we should do with certs for employees
the same as companies have done with credit cards for
employees.  That makes my case better than anything.  Thanks -- Rich

Richard A. Guida
Director, Information Securityu (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 12:24 PM
To: [email-masked]; Guida, Richard [JJCUS]
Subject: Re: Employee Certificates - Security Issues

Richard,

---

From: "Särs, Camillo" <[email-masked]>
Date: Mon, 7 Oct 2002 10:21:18 +0300

> A digital identity certificate proves (to whatever degree the certificate 
> policy underlying it affords) identity.  It does not prove authority 
> to take an action.  (I am omitting attribute certs from this 
> discussion.)

Unfortunately this is not the way identity certificates are interpreted
today.  You should note that the digital signature conveys far more
information than a "paper signature".  The digital signature actually proves
integrity, that is, nobody has tampered with the document since it was
signed.  This property unfortunately has also been used to imply
authenticity, that is, that the person who signed the document actually knew
what he was signing.  To date, I have yet to see a consumer-grade system that
would be able to enforce authenticity as a security property.

> Not to say they won't be used for a long time to come - but I certainly
hope 
> to free my children from the tyranny of dozens of passwords 
> and migrate them to the strength of a single digital 
> credential, a certificate, with the private key held on a 
> hardware token and unlocked using a passphrase known only by 
> the token, not by a server somewhere out of my control.

I wish people would stop marketing the "one key to rule them all" approach.
Using a single, all-powerful public key pair violates one of the most
fundamental security design strategies "principle of least authority".
Trying to build a global system where an individual would only be using a
single public key is foolish on the border of ciminal.  It would also make it
trivial to cross-correlate many different customer and government databases,
which in effect makes any such attempts illegal in the EU.  Fundamental
privacy principles mandate that separate databases must use separate unique
identifiers for individuals, to make cross-correlation difficult.

"The strength" of a single digital credential is simply something that I see
as completely incompatible with an open democracy.

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: Mon, 7 Oct 2002 08:01:44 -0600

this is also been discussed in the context of contracts and other use of
"paper" signatures as "intent" .... did  the person "intend" to perform the
signature in the sense that they also "agreed" to the T&Cs of the thing
that was signed. a digital signature can be interpreted as conveying much
less than a paper signature (legally; in the sense that it doesn't actually
imply all the stuff that a paper signature implies). the use of the term
"digital signature" with the word "signature" being used may create
semantic confusion for some automagically equating digital signature with
manual/paper signature .... just because the word "signature" appears in
both terms.  the concepts of intention and agreeing then is also involved
in non-repudiation ....  aka my machine may have signed a message ...  for
authentication and integrity purposes .... but my machine doesn't have
authority to agree/approve terms of contract that may been contained in the
body of a message.

some past threads on intent &/or non-repudiation:
http://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary &
taxonomy
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative
to PKI?
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case,
or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security
paper
http://www.garlic.com/~lynn/aadsm12.htm#18 Overcoming the potential
downside of TCPA
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during
ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and
their users [was Re: Cryptogram:  Palladium Only for DRM]

http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security'
site.
http://www.garlic.com/~lynn/2001d.html#8 Invalid certificate on 'security'
site.
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#51 future of e-commerce
http://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001n.html#75 A PKI question and an  answer
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet
Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002h.html#13 Biometric authentication for
intranet websites?
http://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you
are?
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman  schema
belong to Public Key schema family?
http://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman  schema
belong to Public Key schema family?
http://www.garlic.com/~lynn/2002j.html#24 Definition of "Non-Repudiation" ?
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and
hashing
http://www.garlic.com/~lynn/2002l.html#28 Two questions on HMACs and
hashing
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce
using POWF

sars.camillo <[email-masked] on 10/07/2002 1:21 am wrote:

Unfortunately this is not the way identity certificates are interpreted
today.  You should note that the digital signature conveys far more
information than a "paper signature".  The digital signature actually
proves
integrity, that is, nobody has tampered with the document since it was
signed.  This property unfortunately has also been used to imply
authenticity, that is, that the person who signed the document actually
knew
what he was signing.  To date, I have yet to see a consumer-grade system
that
would be able to enforce authenticity as a security property.

---

From: "Tom Gindin" <[email-masked]>
Date: Thu, 10 Oct 2002 18:53:08 -0400

XMLDSIG may well be ready for prime time now.  However, its scope is
roughly comparable to that of CMS SignedData.  It uses references instead
of in-line data, which allows for extra complexity, and it includes a
(quite valuable) canonicalization facility, but it's mainly a format for
defining the data which is signed and representing its signature.
      Unless one thinks that ASN.1/DER is the primary problem with PKI,
IMHO XMLDSIG is not going to be revolutionary.  I'm for it, and I've done
some work on it, but it isn't going to solve issues like those in this
thread.  If I've understood most of what's going on here, we've largely
been discussing what happens when an employee tries to commit his or her
employer by signing a document with an organizationally affiliated
certificate, and whether there would be a better way of handling that.  The
format of the signed document has little to do with this issue.

            Tom Gindin

"Hamrick, Matt" <[email-masked]>@mail.imc.org on 10/10/2002
04:50:19 PM

Sent by:    [email-masked]

To:    "[email-masked]'" <[email-masked]>
cc:
Subject:    RE: Employee Certificates - Security Issues

-----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,
> 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
> 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.
>

---

From: [email-masked]
Date: Thu, 10 Oct 2002 19:49:03 -0600

.... european financial institutions and various endevers ... like SET ...
went to relying-party-only certificates ... no visiable name, no visable
credit limit .... etc ... all of which are at least privacy issues ... if
not security issues ... like publishing credit limit. I wouldn't think much
of attaching a certificate to hardly any set of my messages (even financial
transactions) that might flow thru 3rd parties (like merchants) with a
credit limit (in the sense of a credit card credit limit).

the other issue is that since a certificate is stale, static information
... it can't actually approximate the function of credit limit in the
credit card sense .... i.e. credit limit minus (real time) charges to date
to give (real time) available credit.

in past discussions of this type of proposal ... the value in the
certificate was approximating the limit in the paper "check signing limits"
(aka paper checks that had per check signing limit). it doesn't do anything
for real time credit limit ... since at most. a stale, static certificate
approximates a arbritrarily large stack of paper checks each with the same
check signing limit (i.e. the stack is arbritrary large in the sense that a
stale, static certificate could be appended to an arbitrary large number of
different financial transactions). The problem with solely an offline,
static certificate .... is that it has difficulty dealing with aggregated
and/or real-time infomration.

as previously posted ... one of the reasons for migration to payment cards
was that payment cards did provide businesses with aggregation and real
time transaction controls. The issue was that individuals were
circumventing the per transaction limits of the check signing limits by
signing multiple checks (cases of person using 200 $5000 limit checks to
perform a million dollar transaction).

ref:
http://www.garlic.com/~lynn/aadsm12.htm#31 The bank-model, was: employee
certificates - security issues

there have been proposals that involve organization issuing daily
certificates .... where two organization members can trust that each other
are members in good standing as of the morning of that day ... however,
these certificates aren't involved in any sort of transactional
authentication and/or authorization mechanism ... and are proposed for
offline environments where the two participants have no online recourse for
doing real-time checking of organizational member status.

basically, the financial scenario found that starting sometime in the '70s
the cost/benefit ratio of doing online, real-time transactions paid off
(especially where aggregation and real-time information was useful) ...
compared to the old fashion offline credential/certificate (whether paper
or electronic) mode of operations.

ref relying-party-only postings
http://www.garlic.com/~lynn/subtopic.html#rpo

privacy/identification related postings
http://www.garlic.com/~lynn/subtopic.html#privacy

[email-masked] on 10/10/2002 2:50 pm wrote:

... snip ...

... snip ...