Subject: RE: PKI International Consortium

From: "Terwilliger, Ann" <[email-masked]>
Date: Fri, 2 Apr 2004 09:54:28 -0800

The Visa International PKI does issue certificates to Visa Members and their agents internationally.  However, we are a closed system and these certificates are only to be used in conjunction with Visa products and services.

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Friday, April 02, 2004 8:28 AM
To: PKIX list; [email-masked]
Subject: Re: PKI International Consortium

Hi Shaheen,
There are several PKIs run by FIs, even on an international level.
However, I have some difficulties with the phrase
"certificates for the members"? 

Is a "member" an FI organization, FI employee or an FI customer?

For the premier category I believe VISA does that for the 3D Secure
network.   For FI employees I don't know if there really is any
big need for such as these certificates have little use except internally.
Well, Identrus have indeed sold such services to a few banks.

Regarding the third category, it is interesting to note that banks
seem to take the lead in issuing "citizen-certificates" as a
citizen=bank customer.  These FA CAs are though not really
international due to some basic problems like the lack of
standards for expressing citizen identities in various regimes.
Here the customer is really e-governments although the certificates
can often be used for on-line banking as well.

www.identrus.com
www.bankid.com
www.bankid.no

Anders

----- Original Message ----- 

From: <[email-masked]>
To: "PKIX list" <[email-masked]>
Sent: Thursday, April 01, 2004 16:30
Subject: PKI International Consortium

Hello,

I would like to know if there is any international consortium of financial
institutions that maintain a PKI and issues certificates for the members.
If so, what are the standards followed? Any information would be helpful.

Regards.

Shaheen Nasirudheen
JPMorgan ACCESS, Portal Security

-----------------------------------
This message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee or
agent responsible for delivery of this message to the intended
recipient(s), you are hereby notified that any dissemination, distribution
or copying of this message is strictly prohibited.  If you have received
this message in error, please immediately notify the sender and delete this
e-mail message from your computer.

---

From: [email-masked]
Date: Fri, 2 Apr 2004 11:49:36 -0700

sort of the fundamental issue is that the certificate design point is for
offline processing .... it contains sufficient information that it is
possible for the relying party to perform some operation based on relying
on the certificate w/o needing recourse to any additional information.

the problem is also sort of analogous to the issue of needing different
shared-secrets for different security domains ... recent topic drift in
sci.scrypt ...
http://www.garlic.com/~lynn/2004d.html#40 RFC-2898 Appendix B

lets say i have a passport certificate and i wish to do a financial
transaction on a chase bank account. the passport certificate probably
doesn't provide any information with regard to whether i even have a
financial account with chase bank .... aka the passport certificate
contains insufficient information for a relying party expecting a valid
financial transaction.

so for an offline certificate paradigm to work .... it just about means a
unique certificate for every operational domain ... containing sufficient
information that a relying party will go ahead and do whatever operation
based on the contents of the certificate.

now, if the relying party really wants a financial transaction executed
with chase .... then there is not only the issue of the contents of a
stale, static certificate designed as a solution for offline environments
... but there is the possibility that the relying party might be interested
in online, timely, and possibly aggregated information (not conducive for
incorporation in a stale, static certificate designed for solving problems
associated with offline environments) ... in which case, the relying party
might be inclined to perform a online operation with the authoritative
institution for that particular
kind of operation. In the case of a customer financial transaction, the
relying party might be interested in performing a financial transaction
with the customer's financial institution (as the authoritative agency for
that kind of operation).

For this type of scenario, it is then possible to claim for valuable and/or
important operations (where relying parties may be interested in timely
information, as opposed to stale, static information possibly contained in
a certificate), that direclty contacting the authoritative agency makes the
use of stale, static certificates redundant and superfluous. If the
authoritative agency has registered a public key and issued a stale, static
certificate .... then if the relying party is directly contacting the
authoritative agency ... the substitute stale static certificate (issued
for addressing the needs of offline operations) is redundant and
superfluous.

[email-masked] on 4/2/2004 8:57 am wrote:

Hello everyone,

I appreciate your feedback and most of the replies were referring to
identrus.com . My basic concern is from a customer's point of view. If I
have a digital certificate issued by a single authority that is considered
trusted internationally by all financial as well as other commercial
institutions, then I do not require to have a certificate for Institution
-1 and another for Institution -2. Do we have something in place that takes
of this issue. I would be happy to carry and protect that one certificate
which is trusted by everyone.

Thank you,

Shaheen Nasirudheen
978 805 1815

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

---

From: [email-masked]
Date: Fri, 2 Apr 2004 17:11:46 -0700

The arpanet was a traditional, homogeneous network ... that happen to be a
packet-switch implementation rather than circuit-switch implementation.
Note however, it was NOT an internet. It corresponded much closer to the
standard OSI model of homogeneous infrastructure (but having a packet
orientation rather than a circuit orientation).

I've claimed that one of the reasons that the internal network was larger
than the arpaent for all of that period ... was that the internal network
had effectively the equivalent of a gateway built into every node ...
allowing support for heterogenous networking. The great switch-over from
arpanet to internet occured on 1/1/83 ... with the introduction of
internetworking .... a "layer" that doesn't even exist in the OSI model
(sitting somewhere between layer3/networking and layer4/transport). At that
time of the switchover the arpanet was around 250 nodes and the internal
network was nearly 1000 nodes. The combination of internetworking,
heterogeneous networking support, gateways, and the appearance of PCs and
workstations as internet network nodes resulted in the internet eventually
exceeding the number of nodes on the internal network sometime around
mid-85.

misc. past posts related to arpanet, csnet, nsfnet, internet, internet
switch-over and the internal network:
http://www.garlic.com/~lynn/internet.net

a story not related in the above was some corporate type doing technology
audit in the late 70s and being told about the size of the internal
network. the person supposedly wrote a report stating that it was
impossible ... because to build a network of that size using traditional
homogeneous networking technology (common at the time) would have required
more people total than had been working for the corporation over the
previous ten years.

misc. past posts related to OSI, arpanet, iso, etc:
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
the above mentions another issue w/OSI. attempting to get HSP (high-speed
protocol) work item in X3S3.3 (iso chartered us standards organization
responsible for networking and transport layer standards). The problem was
that ISO had a rule that there couldn't be standards work on protocols in
this area that violated OSI. HSP was going to go directly from
level4/transport to the MAC interface. This violated OSI in two respects 1)
it bypassed the level3/level4 interface and 2) it interfaced to MAC layer.
LANs/WANs/MAC are a violation of OSI with the MAC layer sitting somewhere
in the middle of layer3/networking. Because of the OSI violation rule,
X3S3.3 rejected the work item.

in late '69, i did get involved in a project as an undergraduate building a
telecommunication controller using an Interdata/3. this resulted in later
getting blaimed for helping create the plug-compatible manufactoring (PCM)
controller business:
http://www.garlic.com/~lynn/subtopic.html#360pcm

[email-masked] on 4/2/2004 3:37 pm wrote:

Hello everyone,

Quote from bbn.com : "In 1968, the Advanced Research Projects Agency (ARPA)
sent out a Request for Quotation (RFQ) to build a network of four Interface
Message Processors (IMPs). Many of the large computer and
telecommunications organizations didn't even respond--they thought it was
impossible. " - http://bbn.com/arpanet/index.html.

If the pioneers believed that "Internet" is impossible, then I dont think
we would enjoy sending these emails today.

---

From: [email-masked]
Date: Sun, 4 Apr 2004 10:24:08 -0600

The use of relying-party-only certificates were done in large part because
of privacy issues ... which could be

* personal privacy issues with identity information
* personal privacy issues with personal attributes
* institutional sensitivity/privacy issues with institutional attributes

However, for a  relying party that used an index/account number from a
relying-party-only certificate to index an entity entry in a repository or
access an online service, it can be shown that the stale, static
replying-party-only certificate is redundant and superfluous. The issue is
that the relying party is retrieving attributes and/or authorization from
the online service and or an entity entry from their own respository ...
and, in effect, a public key bound to an entity is then just another
personal attribute. A public key personal attribute is safely stored in an
entities entry in a repository just like any other personal attribute, no
matter how many PKI infrastructures wish to infuse public keys with some
sort of mystical properties (alhtough public key can be a non-shared-secret
where so many other attributes take on shared-secret properties).

One scenario is FAST project that was being done by FSTC
http://www.fstc.org/
this basically attempted to leverage the 8583 real-time infrastructures to
provide real-time yes/no answers about things other than authorizing
financial transaction.

For instance, rather than having an attribute certificate with
date-of-birth (which currently represents a identity theft vulnerability)
to establish whether a person is younger/older than 18 .... an entity would
sign a age level question, much in the same way they might sign a x9.59
financial transaction. This is then sent off to the financial institution,
which decodes it and replies yes/no to the relying party. The FI maintains
a repository entry for the entity ... including things like timely,
sensitive and/or aggregated information. The FI can answerr questions about
younger/older than 18 (w/o having to reveal date-of-birth) or answer yes/no
to a financial transaction w/o having to reveal credit limit or current
balance.

The current issue is that things like identity theft vulnerabilities aren't
limited to just identity, but can include other personal attributes as
well; in fact probably includes attribute that may potentially be used in
part of a shared-secret paradigm. Also sensitivity of attributes may not be
just be limited to personal attributes, but may also include institutional
sensitivity regarding institutional attributes.

[email-masked] wrote:

Hi,

> If a relying party needs to know that I possess certain attributes, and
> if I can present an "Attribute Certificate" that convinces them that I
> do indeed possess those attributes, then what purpose is served by also
> having me present an "Identity Certificate"?

You are completely right, Eric. There are many situations that require
the knowledge of certain attributes but do not require knowledge of
identity.
For instance, accesing the Playboy should require knowledge of the user
being
over 18, but no identity information should be revealed.

---

From: [email-masked]
Date: Sun, 4 Apr 2004 20:28:38 -0600

the EU directive just said something about being as anonymous as cash ....
in general the privacy mandates signficantly reduce the run of the mill
phishing .... it is somewhat like cryptography .... some cryptography is
secure for all but the most determined government operations.

it is possible to make account number electronic financial transactions
like x9.59
http://www.garlic.com/~lynn/index.html#x959
 .... authenticated but not identified.

In that sense they become pretty agnostic with respect to identification.
Governments are able to mandate "know your customer" rules for the accounts
... which given the appropriate government action can extract all sorts of
details. However, it doesn't preclude other governments allowing purely
anonymous accounts.

[email-masked] wrote:

Lynn - good commentary - but I also want to add that cash transactions are
not anonymous in that they leave finger prints and they survived this
"reduction in their anonymity" after the adoption of fingerprinting by law
enforcement... i.e.  Someone handles the money and there is all kind of
tangible evidence left, the issue is the cost of collecting and maintaining
it.

Todd