Misc AADS & X9.59 Discussions

AADS Postings and Posting Index, next, previous - home



maximize best case, worst case, or average case? (TCPA)
3D Secure GUI
3D Secure GUI
3D-Secure and Passport
3D-Secure and Passport
3D-Secure and Passport
3D-Secure and Passport
3D-Secure and Passport
3D Secure and EMV
Crypto Forum Research Group ... fyi
3D Secure and EMV
Some security, fraud, attack, threat, references
TOC for world bank e-security paper
anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa?
Challenge to TCPA/Palladium detractors
Challenge to TCPA/Palladium detractors
Feasability of Palladium / TCPA
Overcoming the potential downside of TCPA
Overcoming the potential downside of TCPA
TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
draft-ietf-pkix-warranty-ext-01
Smartcard in CD
draft-ietf-pkix-warranty-ext-01
10 choices that were critical to the Net's success
Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
Cryptogram: Palladium Only for DRM
I-D ACTION:draft-ietf-pkix-usergroup-01.txt
Employee Certificates - Security Issues
Employee Certificates - Security Issues
Employee Certificates - Security Issues
Employee Certificates - Security Issues
The Bank-model Was: Employee Certificates - Security Issues
Employee Certificates - Security Issues
two questions about spki
Banks + Legally binding signatures = A mess
Electronic Security: Risk Mitigation in Financial Transactions
two other financial electronic security related URLs
Legal entities who sign
Legal entities who sign
Identification = Payment Transaction?
In Brief: Anti-'Skimming' Guidelines Coming
I-D ACTION:draft-ietf-pkix-sim-00.txt
draft-ietf-pkix-warranty-extn-01.txt
draft-ietf-pkix-warranty-extn-01.txt
Identity Theft More Often an Inside Job
draft-ietf-pkix-warranty-extn-01.txt
Fraudit helps registrars battle global online fraud
Online Fraud Growing in Scale, Sophistication
draft-ietf-pkix-warranty-extn-01.txt
draft-ietf-pkix-warranty-extn-01.txt
Frist Data Unit Says It's Untangling Authentication
Frist Data Unit Says It's Untangling Authentication
First Data Unit Says It's Untangling Authentication
TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
TTPs & AADS (part II)
TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
eBay Customers Targetted by Credit Card Scam
Time to ID Identity-Theft Solutions
e-Government uses "Authority-stamp-signatures"
signing & authentication (was Credit Card Scam)
Intertrust, Can Victor Shear Bring Down Microsoft?
Intertrust, Can Victor Shear Bring Down Microsoft?
Intertrust, Can Victor Shear Bring Down Microsoft?
Invisible Ink, E-signatures slow to broadly catch on (addenda)
Online shopping passes $11 billion
Subpoena Sidelines PKI Project
Offline Root CA with valid CRL hierachie


maximize best case, worst case, or average case? (TCPA)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/30/2002 01:49 PM
To: Ryan Lackey <ryan@xxxxxxxx>
cc: cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
Digital Bearer Settlement List <dbs@xxxxxxxx>,
    dcsb@xxxxxxxx, "R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: maximize best case, worst case, or average case? (TCPA)
"security modules" are also inside the swipe & pin-entry boxes that you see at check-out counters.

effectively both smartcards and dongles are forms of hardware tokens .... the issue would be whether a smartcard form factor might be utilized in a copy protection scheme similar to TCPA paradigm .... a single hardware chip that you register for all you applications .... or in the dongle paradigm .... you get a different smartcard for each application (with the downside of the floppy copy protection scenario where a user with a half dozen active copy protected applications all wanted "their" smartcard crammed into the same smartcard reader simultaneously).

many of the current chipcards .... i believe are used in the magnetic stripe "swipe" mode for authenticating specific transactions .... most of the rest are used for password substitute at login type events. Many of the chipcards following the straight payment card model result in end-user having large number of different institutional tokens (similar to the floppy copy protect paradigm). Following the institutional-specific and/or application-specific token paradigm starts to become difficult to manage as the number of tokens increase and the probability that multiple are required simultaneously increases.

That eventually leads into some sort of person-centric or device-centric paradigm .... not so much an issue of the form factor (floppy, chipcard, dongle, etc) .... but an issue of whether there are potentially large numbers of institutional/application specific objects or small numbers of person/device specific objects.

So a simple issue is the trade-off between the institutional/application specific objects .... which seem to have some amount of acceptance (payment cards, chip cards, various "dongle" forms, etc) but in many instances can scale poorly ... especially if multiple different such objects have to be available concurrently .... vis-a-vis switching to a person/device specific object paradigm (chipcard, dongles, etc, potentially exactly same formfactor but different paradigm)

ryan@xxxxxxxx on 6/30/2002 12:39 pm wrote:
I think dongles (and non-copyable floppies) have been around since the early 80s at least...maybe the 70s. Tamper-resistant CPU modules have been around since the ATM network, I believe, in the form of PIN processors stored inside safes)

The fundamental difference between a "dongle" and a full "trusted module" containing the critical application code is that with a dongle, you can just patch the application to skip over the checks (although they can be repeated, and relatively arcane).

If the whole application, or at least the non-cloneable parts of the application, exist in a sealed module, the rest of the application can't be patched to just skip over this code.

Another option for this is a client server or oracle model where the really sensitive pieces (say, a magic algorithm for finding oil from GIS data, or a good natural language processor) are stored on vendor-controlled hardware centrally located, with only the UI executing on the end user's machine.

What I'd really like is a design which accomplishes the "good" parts of TCPA, ensuring that when code claims to be executing in a certain form, it really is, and providing a way to guarantee this remotely -- without making it easy to implement restrictions on content copying. It would be nice to have the good parts of TCPA, and given the resistance to DRM, if security and TCPA have their fates bound, they'll probably both die an extended and painful death.

I suppose the real difference between a crypto-specific module and a general purpose module is how much of the UI is within the trusted platform envelope. If the module is only used for handling cryptographic keys, as an addition to an insecure general purpose CPU, with no user I/O, it seems unlikely to be useful for DRM. If the entire machine is inside the envelope, it seems obviously useful for DRM, and DRM would likely be the dominant application. If only a limited user IO is included in the envelope, sufficient for user authentication and keying, and to allow the user to load initially-trusted code onto the general purpose CPU, but where the user can fully use whatever general purpose code on the general purpose CPU, even uncertified code, with the certified module, it's not really useful for DRM, but still useful for the non-DRM security applications which are the alleged purpose behind TCPA.

(given that text piracy doesn't seem to be a serious commercial concern, simply keeping video and audio playback and network communications outside the TCPA envelope entirely is good enough, in practice...this way, both authentication and keying can be done in text mode, and document distribution control, privacy of records, etc. can be accomplished, provided there is ALSO the ability to do arbitrary text processing and computing outside the trusted envelope, .)

If it's the user's own data being protected, you don't need to worry about the user intentionally circumventing the protections. Any design which removes control from the 'superuser' of the machine is fundamentally about protecting someone other than the user.

This, I think, is the difference between TCPA and smartcards. Notice which one has in its short lifetime attracted far more enmity :)

--
Ryan Lackey [RL7618 RL5931-RIPE] ryan@xxxxxxxx
CTO and Co-founder, HavenCo Ltd. +44 7970 633 277
the free world just milliseconds away http://www.havenco.com/
OpenPGP 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F


3D Secure GUI

From: Lynn Wheeler
Date: 07/08/2002 08:37 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: amolnatu@xxxxxxxx.ae,
    internet-payments <internet-payments@xxxxxxxx>,
epay@xxxxxxxx
Subject: Re: 3D Secure GUI
Nacha also had an aads pilot with digital signature (both with software & chipcards) .... see 7/23/2001 "secure ATM card"
http://web.archive.org/web/20070706004855/http://internetcouncil.nacha.org/News/news.html

it was close to the x9.59 standard mapping to iso8583 standard
http://www.garlic.com/~lynn/x959.html#x959

anders.rundgren@xxxxxxxx on 7/7/2002 11:39 pm wrote:
Amol,
Interesting this NACHA project. It seems like a direct copy of what banks are doing in many places in the world. Many quite ahead of 3D Secure in my opinion, but also totally disparate technically.

This also shows that when banks create their own preferred solution, it is centered around the bank rather than around a card.

Now regarding your concerns I have some problems understanding what the problem is:

>1. The status of the transaction completion is not available to the merchant
>as the transactions gets completed totally within the bank.

In all these schemes the merchant must of course get either a "receipt" or an authenticated payment authorization (like in 3D) depending on the type of payment. The way the this message reaches the merchant varies from 3D's (in my opinion pretty inferior) server- browser-server solution, to schemes using reliable messaging.

>2. It is cumbersome for the merchant to link the purchase details with the
>actual payment transaction.

You mean because it is not taking place within a Web-session? In many of these schemes it works as in 3D as it is just a change in GUI (as the subject line imply), but in some other schemes the merchant needs to store the message somewhere during checkout as well.

>3. It involves a large change to the existing card processing systems i.e
>the acquiring systems, card scheme would have no knowledge of authorisation
>prior to actual settlements.

I don't think this is the case, as the flow of information is not changed, just formats.

Cheers,
Anders


3D Secure GUI

From: Lynn Wheeler
Date: 07/08/2002 09:22 AM
To: ANSHU NAHAR /NIG/CRP <anshu.nahar@xxxxxxxx>
cc: 3d-secure@xxxxxxxx, 'Anders Rundgren' <anders.rundgren@xxxxxxxx>,
internet-payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: RE: 3D Secure GUI
note that in the previous reference to X9.59, X9.59 was designed to be a payment method agnostic standard .... applicable to all payments in all environments (at least both debit & credit).

The NACHA pilot demonstrated a AADS (some of the data elements were differed from that in the X9.59 standard) to ISO8583 mapping for debit. However, a similar mapping is showed for ISO8583 for credit.

The X9.59 (and NACHA) mapping to ISO8583 uses the same exact flow as currently is implemented .... aka there is no change in the existing message flows for either credit or debit .... and all the business processes remain identical. The standard to ISO8583 mapping just adds a few more data elements to the existing message standards w/o changing the message flow or processing.

anshu.nahar@xxxxxxxx on 7/4/2002 11:49 pm wrote:
"...Then the payment is carried out in the bank-environment..."

This is exactly the approach we have been using at our Bank for more than 3 years.
1. The customer "checks out" from the web merchant's site.
2. He is directed to ICICI Bank's site.
3. The payment is completed under "Bank's environment".
4. The customer is directed back to web merchant after payment processing. The difference is that is approach is used to effect direct account debit rather than for credit cards.

Regards
Anshu Nahar


[3d-secure] NEWS: 3D-Secure and Passport

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/09/2002 08:14 PM
To: donpark@xxxxxxxx, internet-payments@xxxxxxxx, epay@xxxxxxxx
cc: "'MacDougall, Alan'" <Alan.MacDougall@xxxxxxxx>
Subject: RE: [3d-secure] NEWS: 3D-Secure and Passport
Note that the host of the internet-payments mailing list has had a FAST project ... aka a consumer sign something authorizing a 3rd party to ask their financial institution a question ... and the financial institution can answer yes/no (or ???) ... much the same way the answer yes/no to debit & credit requests in iso8583.

note that financial institutions already answer questions about their customers ... aka you give a bank as a reference for a number of different things & circumstances .... which the bank then corroborates. That is different than a bank issuing a general identify certificates.

I've made a number of recent postings about financial institutions being able to migrate existing business processes to an electronic, digitial signed environment (w/o resorting to a certificate) like as described in the FAST project. it doesn't have to be a PKI ... it can be a little pki. a past discussion on some of these issues (furthermore, it isn't new business operations ... it is applying some additional technology to existing business operations, you might even be able to utilize the existing iso8583 financial networks to carry some of the messages):
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
http://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
http://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aadsm9.htm#cfppki3 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsmore.htm#x959demo AADS & X9.59 demos at BAI (annual world-wide retail banking) show in miami next week
http://www.garlic.com/~lynn/aepay6.htm#userauth MS masters NC mind-set (authentication is the key)
http://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy
http://www.garlic.com/~lynn/ansiepay.htm#x959demo X9.59/AADS demos operational
http://www.garlic.com/~lynn/99.html#216 Ask about Certification-less Public Key
http://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show

donpark@xxxxxxxx at 7/9/2002 7:52 pm wrote:
Alan,

> This will work assuming that a Bank would be happy
> outsourcing authentication services to a third party (let
> alone that third party being Microsoft).

True. At this point, it's the business issues that banks will have to consider. As one can see from a brief visit to Slashdot, there is no shortage of misinformed paranoid people in the world. Technically, its as secure as basic 3D-Secure authentication. There was an issue over security of Passport inline UI, but that feature was deprecated recently and 3D-Secure Passport integration no longer uses it.

> Personally I see Banks potentially as a source of
> authenticated users for other organisations (ie, other
> organisations trust the Banks to authenticate mutual users)
> rather than a recipient of users of other organisations'
> authentication processes (ie, the Banks trust
> Microsoft/Liberty Alliance to authenticate mutual users).

I understand where you are coming from. Using banks as PKI foundation is an old idea that is still valid. There are two problem with the idea:

1. Most banks and issuers are not equipped to provide general authentication service.
2. It doesn't fit their business model.
3. Authentication service as a business is yet to be proven.

Integration of Passport with 3D-Secure uses a variation of that idea, using ONE-WAY binding link from one or more 3D-Secure accounts to a Passport account. Each of these links are created whenever a user enrolls into 3D-Secure program and selects Passport as his/her authentication method. Because each of these links represents a form of trust, the Passport account takes on more substance than mere e-mail address.

Allow me to point out a copule of facts in an attempt to dispell some myth about Passport integration with 3D-Secure:

First, credit card information NEED NOT BE stored in Passport accounts. You may do so, but I don't recommend it.

Second, due to one-way nature of the links, there is minimal impact from Passport accounts being compromised and link can be broken once fraud is detected.

Best,

Don Park
Docuvers


NEWS: 3D-Secure and Passport

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/14/2002 10:01 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: 3d-secure@xxxxxxxx, donpark@xxxxxxxx,
'Internet-Payments' <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Re: NEWS: 3D-Secure and Passport
Part of the issue of SSO is can it be used to impersonate you in different security domains. One of the reasons for the requirement for different (shared-secret) passwords in different security domains .... is that the "authorities" in one security domain might otherwise be able to impersonate you in other security domains. The other issue related to SSO ... is ever product requiring some sor tof access authentication implementing their own (shared-secret) password mechanism.

One SSO mechanism might be once you connect to your ISP and (predominately RADIUS) authenticates you to the ISP ... having the ISP supply authentication information to every subsequent web-related access that you make requiring authentication. The downside is that you may be using a garage operation ISP run by a couple young techno wizards and you do internet banking (even if they aren't interested in performing fraud the physical security of their operation may not mean that anybody else can't enter their facility and perform fraud).

Security,. integrity, etc in different security domains may be signfiicantly different levels (20 plus years ago looking at allowing corporate travelers to access email from hotels, many hotel PBXs were identifiied has having a variety of significant security vulnerabilities, requiring special modem cards implementing challenge/response, key exchange, session encryption, etc, sort of an SSL of the late '70s). The whole area of open, unsecured (inter) networks has significantly compounded the vulnerabilities.

So an issue of internet/intranet SSO .... relates to shared-secret passwords and cross domain security & authentication. That also has been an issue of using trusted 3rd parties as part of an authentication infrastructure (in the crypto mailing list there is a recent thread on the extremely wide variation in integrity levels of some of the different SSL certificate vendors ... and the way SSL certificates currently operation mean that the trust level is effectively the lowest common denominator).

Back in the late '80s doing technical audits of Project Athena ... sat thru an all day session on the original definition of cross-domain authentication in Kerberos ... it wasn't so much a technology issue .... it was a business issue; things like who took the liability. If there was cross-domain Kerberos authentication between two corporations ... did one corporation accept full liability for any actions by entities that had been cross-domain authenticated (whether the entitties were actual employees of that corporation or somebody impersonating an employee of that corporation).

Note that authentication doesn't have to equate to identity. In theory, it is possible to register for a new account with an ISP ... and have a userid and a password. The password just authenticates that you are the person authorized to use the account. As long as the ISP gets paid .... in principle that need not know who you are. An ISP-based SSO would have the ISP supplying your authenticated userid to every subsequent web location you connect to (identity is not stamped on every ISP operation, but lets say your ISP persona is stamped on everything). Now, some governments around the world might want a "know your customer" rule ... for ISPs similar to similar fules in the financial industry.

cryptography archive ... thread is: SSL Certificate Monopoly Bears Financial Fruit:
http://www.mail-archive.com/cryptography%40wasabisystems.com/maillist.html

other related discussions to how SSL domain name certificates operate:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

some past postings on identity, authentication and privacy
http://www.garlic.com/~lynn/subtopic.html#privacy

one of the original SSOs is kerberos, kerberos is a IETF/internet standard. for kerberos related RFCs go to
http://www.garlic.com/~lynn/rfcietff.htm

and select Term (term->RFC#)

and scroll down to Kerberos kerberos see also authentication , security 3244 3129 2942 2712 2623 1964 1510 1411

description of kerberos working group:
http://www.ietf.org/html.charters/krb-wg-charter.html

at the above there is a draft for a kerberos network authentication service (drafts/versions only have a six month life time, sometimes one draft will die, be removed, and there will be a lapse until an updated version is reborn).

the dominant internet-related authentication mechanism is radius (also an internet stnadard) used by ISPs. RADIUS related RFCs can be found in the indexed referenced above: remote authentication dial in user service (RADIUS ) see also authentication , network access server , network services 3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138 2059 2058

also, radius related items:
http://www.garlic.com/~lynn/subtopic.html#radius

anders.rundgren@xxxxxxxx on 7/14/2002 2:31 am wrote:
Don,
OK. Being a part-designer of such I tend to disagree:
http://web.archive.org/web/20021012183030/shibboleth.internet2.edu/SHIB-05-Sept-2001.html

>I believe authentication should
>require a concious and visible user action.

Me too. But SSO on the Internet (in contrast to an Intranet) does not necessarily mean that you just login once, but rather that you can use the same method and data at many different places.

> SSO tatoos my identity on my forehead just so I don't have to
>reach for my wallet. Yikes.

Is this a privacy concern or what?


NEWS: 3D-Secure and Passport

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/14/2002 01:14 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: 3d-secure@xxxxxxxx, donpark@xxxxxxxx,
     epay@xxxxxxxx, 'Internet-Payments' <internet-payments@xxxxxxxx>
Subject: Re: NEWS: 3D-Secure and Passport
There are at least 2-3 kinds of SSOs ...

1) the ones that you give it all your current passwords .... and you authenticate yourself to the SSO which then spoofs a login using the appropriate password into some other environment ... the "owners" of that SSO then have all your passwords ... potentially across mutliple security domains and could effect a non-SSO direct login impersonating you (this is somewhat related to non-repudiation).

2) the kerberos kind of ticket SSOs ... where you authenticate yourself to kerberos servers and it provides tickets that can be used with other services. the identity of the original kerberos agency is involved here ... since the other services need to know which kerberos service they might be trusted (see previous references to kereros which goes back possibly 15 years). Note that kerberos is the standard in w2000 and beyond (the pre-amble in the referenced kerberos "draft" from previous note touches on some of this). Cross-domain kerberos authentication has been a long term issue ... not so much because of technology issues .... but business and liability issues/
http://www.garlic.com/~lynn/aadsm12.htm#4 3d-secure and passports

3) (sort-of) SSL server certificates and trusted 3rd parties (aka you accept the athentication for session setup based on the information in the certificate). note as mentioned many times previously ... a primary purpose for SSL server certificates is because of integrity issues with the domain name infrastructure .... however TTPs issuing SSL server certificates are also dependent on the integrity of the domain name infrastructure; any improvement in the integrity of the domain name infrastructure for purposes of the TTPs issuing SSL server certificates .... contributes to reducing the justification for having SSL server certificates (i.e. integrity/trust issues in the domain name infrastructure). In effect, significant improvement in the trust for SSL server certificates also contributes to not needing them. This sort of complicates any sort of long term business plan (for example if SSL server certificates ever become sufficiently onerous ... it would might also justify fixing the domain name infrastructure ... eliminating SSL server certificates):
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

anders.rundgren@xxxxxxxx on 7/14/2002 11:27 am wrote:
Lynn,

>Part of the issue of SSO is can it be used to impersonate you in different
>security domains. One of the reasons for the requirement for different
>(shared-secret) passwords in different security domains .... is that the
>"authorities" in one security domain might otherwise be able to impersonate
>you in other security domains.

This is solved in SAML/Liberty/OBI Express etc. by marking the signed SSO "ticket" with a target site which eliminates impersonation.

>The other issue related to SSO ... is ever product requiring some sor
>tof access authentication implementing their own (shared-secret) password
>mechanism.

If you have a central SSO-handler taking care of multiple sites/apps you may indeed need such a mechanism. But even this part can easily be performed by asymmetric crypto to get away from shared-secrets.

>That also has been an
>issue of using trusted 3rd parties as part of an authentication
>infrastructure (in the crypto mailing list there is a recent thread on the
>extremely wide variation in integrity levels of some of the different SSL
>certificate vendors ... and the way SSL certificates currently operation
>mean that the trust level is effectively the lowest common denominator).

Agreed. That's why it is surprising the financial industry cannot get their act together and establish a trustworthy organization-level CA. But probably the fraud-level for SSL-certs is still too low to justify anything else.

Anders


NEWS: 3D-Secure and Passport

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/14/2002 01:57 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: 3d-secure@xxxxxxxx, donpark@xxxxxxxx,
    epay@xxxxxxxx, 'Internet-Payments' <internet-payments@xxxxxxxx>
Subject: Re: NEWS: 3D-Secure and Passport
... oh yes, the issue wasn't reply type of attack for impersonation .... the issue was leakage of valid authentication information thru some accidental or purposeful fault in the SSO infrastructure.

lots of authentication protocols have reply resistance ... say in the case of a digital signature orientation for RADIUS .... the server transmits a time or other unique/random value. The user returns a message with the servers time/unique-value, userid ... signed with their digital signature.

Say a traditional RADIUS implementation transmits "enter userid" (this can be in the clear as if it appears on a terminal .... or encapsulated in a PPP message; .... I've seen ISPs do their front-end radius with routing by sending down "enter userid" .... if it comes back with straight userid ... then it is assumbed to be something like telnet .... if it comes back with some prefix and some separation character preceding the userid .... then it may be assumbed to be PPP and the person is logging in to PPP ... then there are the ISPs that only allow PPP).

In any case ... they might send down "7/14/02 13:00:00.xx enter userid" ... in which case that whole character string is included in a signed reply.

One issue has to do with whether you have a "chatter" authentication protocol .... taking one or more exchanges of messages (where both parties could contributed to the contents as a replay prevention measure) ... or a "transaction" authentication protocol ... here everything is piggy-backed in a single message (aka like in x9.59 where only one party gets to contribute information for replay resistant purposes).

Also, note the original wasn't whether the relying party couldn't tell whether it was an SSO or a direct authentication operation .... the issue was whether any leakage of (authentication) information from an SSO feature could result in a relying party authorizing a fraudulent operation.(regardless of whether the audit trail subsequently showed whether not things originated from SSO or not).

I'm not sure which you were referring to as being "solved" .... some replay attack remediation by having a ticker marked for a specific target site (relying party) ... minimizing using previously issued tickets in some sort of replay (with the same or different relying party, also various forms of insider attacks also involve use of priviledged information for fraudulent transactions on the same site).

anders.rundgren@xxxxxxxx on 7/14/2002 11:27 am wrote:
This is solved in SAML/Liberty/OBI Express etc. by marking the signed SSO "ticket" with a target site which eliminates impersonation.

NEWS: 3D-Secure and Passport

Refed: **, - **, - **
From: Lynn Wheeler
Date: 07/14/2002 02:25 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: 3d-secure@xxxxxxxx, donpark@xxxxxxxx,
epay@xxxxxxxx, 'Internet-Payments' <internet-payments@xxxxxxxx>
Subject: Re: NEWS: 3D-Secure and Passport
oh yes, from
http://www.garlic.com/~lynn/secure.htm
single sign-on
(I) A system that enables a user to access multiple computer platforms (usually a set of hosts on the same network) or application systems after being authenticated just one time. (C) Typically, a user logs in just once, and then is transparently granted access to a variety of permitted resources with no further login being required until after the user logs out. Such a system has the advantages of being user friendly and enabling authentication to be managed consistently across an entire enterprise, and has the disadvantage of requiring all hosts and applications to trust the same authentication mechanism. [RFC2828] (see also secure single sign-on, authentication)


[3d-secure] 3D Secure and EMV

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/28/2002 08:05 AM
To: amolnatu@xxxxxxxx.ae
cc: 3d-secure@xxxxxxxx, <internet-payments@xxxxxxxx>,
epay@xxxxxxxx
Subject: RE: [3d-secure] 3D Secure and EMV
payment cards can include credit, debit, any sort of payment.

credit was initially used on the internet .... in part because of relatively close fit with existing non-face-to-face business model (MOTO, aka mail-order/telephone-order) support; i.e. AVS, card-not-present, cardholder-not-present previsions:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2 assurance, e-commerce, and some x9.59
http://www.garlic.com/~lynn/aadsm5.htm#asrn3 assurance, e-commerce, and some x9.59

debit was an issue since it didn't have a non-card-present model and it depended on shared-secret authentication implemented in a private, secure network with private, secure point-of-entry devices (implementing trusted security modules).

NACHA has done an internet trial for ACH/debit ... using an AADS model with public/private key cryptography using both software and hardware tokens.
http://www.garlic.com/~lynn/x959.html#aads
http://web.archive.org/web/20070706004855/http://internetcouncil.nacha.org/News/news.html

an issue is given appropriate technology then the trust level of existing debit on private network with trusted security modules .... can be approached or exceeded for public, non-trusted networks.

the PC industry has somewhat moved in a couple of direction .... hardware tokens in chipcard form factor requiring ubiquitous card reader deployment .... but also hardware tokens in USB dongle form factor requiring ubiquitous USB port availability (there are also combos that look like a 7816 chipcard on one end and USB dongle on the other end).

For overlapping environments .... there is also some migration to iso 14443 proximity/contactless, especially for high-traffic areas.

One could imagine three or four different tokens all mapped to same financial accounts ... a magstripe form factor, a 7816 form factor, a 14443 form factor and a USB dongle form factor ... or possible some combo hardware tokens supporting multiple form factor operation (magstripe, 7816, 14443, USB dongle, etc).

amolnatu@xxxxxxxx.ae on 7/28/2002 1:28 am wrote:
Hi
Probably this topic posed by Anders got missed out ... I would like to understand the path that internet payments would take once EMV cards are rolled out.

To my knowledge, banks implementing smart cards see no effect on internet payments at this point in time i.e these payments will continue to be non-authenticated and move to 3D secure in due course.

Once there is a large mass of smart card holders, would banks go ahead with equipping them with readers ? How would this affect 3D ? Which authentication would prevail ?

Any thoughts ...

Is the PC industry moving towards having smart card readers as default hardware ...

Cheers Amol

P.S. can someone send me links to popular EMV related mailing lists ?


Crypto Forum Research Group ... fyi

From: Lynn Wheeler
Date: 07/28/2002 07:42 AM
To: cryptography@xxxxxxxx
cc: epay@xxxxxxxx
Subject: Crypto Forum Research Group ... fyi

To IETF-Announce ;
Subject Crypto Forum Research Group
From Vern Paxson <vern@xxxxxxxx>
Date Fri, 26 Jul 2002 163850 -0400

A new IRTF research group, CFRG (Crypto Forum Research Group), has begun, with the appended charter. Use cfrg-request@xxxxxxxx to subscribe to the mailing list. See http://www.irtf.org/cfrg/ for further information.
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Crypto Forum Research Group (CFRG) is a general forum for discussing and reviewing uses of cryptographic mechanisms, both for network security in general and for the IETF in particular.

CFRG serves as a bridge between theory and practice, bringing new cryptographic techniques to the Internet community and promoting an understanding of the use and applicability of these mechanisms via Informational RFCs (in the tradition of, e.g., RFCs 1321 (MD5) and 2104 (HMAC)). Our goal is to provide a forum for discussing and analyzing general cryptographic aspects of security protocols, and to offer guidance on the use of emerging mechanisms and new uses of existing mechanisms. IETF working groups developing protocols that include cryptographic elements are welcome to bring questions concerning the protocols to CFRG for advice.


[3d-secure] 3D Secure and EMV

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: Sun, 28 Jul 2002 09:58:26 -0600
To: amolnatu@xxxxxxxx.ae
Cc: 3d-secure@xxxxxxxx,
"'Internet-Payments'" <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: RE: [3d-secure] 3D Secure and EMV
also slightly related discussion on form factor & ubiquitous deployment
http://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman

somewhat related was a recent news on being able to use cellphones in japan to operate an ATM machine.

cards have been a form of something you have authentication.

technology and wireless operation can "prove" you have something .... without anybody actually seeing what it is you have .... aka a wireless PDA or cellphone can contain a specific chip that contains a unique value ... where the operation of the chip can "prove" that you posses the chip. Furthermore, the chip can be designed to only operate when presented with a valid PIN.

This would be combination of something you have and something you know authentication. The technology difference compared to existing PIN-debit ... where information on a magstripe and your PIN is essentially transmitted over a closed, private, secure network .... is that the technology used can imply just by its correct operation both something you have and something you know w/o having to divulge or show either.

This is the X9.59 and NACHA AADS digital signature operation .... a chip signing an operation can imply two-factor authentication ... even if the chip is embedded in a cellphone or PDA for wireless operation and nobody actually physically observes it.

Some security, fraud, attack, threat, references

From: Lynn Wheeler
Date: 07/28/2002 01:56 PM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Some security, fraud, attack, threat, references
Internet Security Alliance:

A Trusted and Reliable Public-Private Partnership for Information Sharing and E-security Issues
http://www.isalliance.org/

some resources:
http://web.archive.org/web/20041125092246/http://www.isalliance.org/resources/

technology briefs from above
Secure Infrastructure Design, This document was provided to ISAlliance members in May. July 1, 2002

A Brief Tour of the Simple Network Management Protocol, This document was provided to ISAlliance members in April. June 10, 2002

Organized Crime and Cyber-Crime: Implications for Business, This document was provided to ISAlliance members in February. April 8, 2002

Downstream Liability for Attack Relay and Amplification, This paper was based on a joint presentation at the RSA Conference 2002. March 15, 2002

Home Network Security, This document was provided to ISAlliance members in October. March 4, 2002

Overview of Attack Trends, This document was provided to ISAlliance members in January. February 19, 2002

Using PGP to Verify Digital Signatures, This document was provided to ISAlliance members in December. January 28, 2002

Cross-Site Scripting Vulnerabilities, This document was provided to ISAlliance members in November. January 15, 2002

Dealing with External Computer Security Incidents, This document was presented to ISAlliance members in November. December 17, 2001

Managing the Threat of Denial-of-Service Attacks, ISA releases their first Technology Brief. This document was presented to ISAlliance members in October. November 15, 2001

External Resources:

Electronic Security: Risk Mitigation in Financial Transactions, World Bank Financial Sector Report: June 2002 June 13, 2002

Mobile Risk Management: E-Finance in the Wireless Environment, World Bank Financial Sector Discussion Paper: May 2002 May 28, 2002


TOC for world bank e-security paper

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Date: Sun, 28 Jul 2002 14:30:43 -0600
Subject: TOC for world bank e-security paper
with respect to world bank e-security paper:
http://web.archive.org/web/*/http://www.isalliance.org/resources/papers/E-security.pdf

the following is the table of contents
Abstract
Acknowledgments
Executive Summary
I. Introduction
II. What Is Electronic Security and Why Is It Needed?
III. The Electronic Security Industry
IV. Electronic Security Infrastructure within a Risk Management Framework
V. Pillar I: Legal Framework and Enforcement
VI. Pillar II. Electronic Security of Payment Systems
VII. Pillar III: Supervision and Prevention Challenges
VIII. Pillar IV: The Role of Private Insurance as a Complementary Monitoring Mechanism
IX. Pillar V: Certification, Standards, and the Role's of the Public and Private Sectors
X. Pillar VI: Accuracy of Information on E–Security Incidents and Public–Private Sector Cooperation
XI. Pillar VII: Education and Prevention of E–Security Incidents
References
Glossary
Annex I. Risk Management: A Blueprint for Layered Security
Annex II. Authentication and Non-Repudiation
Annex III. E–Security in the Case of Wireless
Annex IV. New Regulatory Paradigm: Safe and Sound Transactions in an Open networked  Environment


anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/08/2002 08:59 AM
To: cryptography@xxxxxxxx
Subject: anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa?
for eal 5/6 evaluation .... a semi-formal specification is required. has anybody seen a fips186-2/x9.62 semi-formal specification?

from common criteria ...

in the attached, TOE refers to "target of evaluation" ... for more detailed definition ... see TOE in
http://www.garlic.com/~lynn/secure.htm
EAL5

EAL5 permits a developer to gain maximum assurance from security engineering based upon rigorous commercial development practices supported by moderate application of specialist security engineering techniques. Such a TOE will probably be designed and developed with the intent of achieving EAL5 assurance. It is likely that the additional costs attributable to the EAL5 requirements, relative to rigorous development without the application of specialized techniques, will not be large.

EAL5 is therefore applicable to those circumstances where developers or users require a high level of independently assured security in a planned development and require a rigorous development approach without incurring unreasonable costs attributable to specialist security engineering techniques.

EAL5 provides assurance by an analysis of the security functions, using a functional and complete interface specification, guidance documentation, the high-level and low-level design of the TOE, and all of the implementation, to understand the security behavior. Assurance is additional gained through a formal model of the TOE security policy and a semiformal presentation of the functional specification and high-level design and a semiformal demonstration of correspondence between them. A modular TOE design is also required.

This EAL represents a meaningful increase in assurance from EAL4 by requiring semiformal design descriptions, the entire implementation, a more structure (and hence analyzable) architecture, covert channel analysis, and improved mechanisms and/or procedures that provide confidence that the TOE will not be tampered with during development.

EAL6

EAL6 permits developers to gain high assurance from application of security engineering techniques is a rigorous development environment in order to produce a premium TOE for protecting high value assets against significant risks.

EAL6 is therefore applicable to the development of security TOEs for application in high risk situations where the value of the protected assets justifies the additional costs.

This EAL represents a meaningful increase in assurance from EAL5 by requiring more comprehensive analysis, a structure representation of the implementation, more architectural structure (e.g. layering), more comprehensive independent vulnerability analysis, systematic covert channel identification, and improved configuration management and development environmental controls.


Challenge to TCPA/Palladium detractors

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/10/2002 11:25 PM
To: Russell Nelson <nelson@xxxxxxxx>
cc: cryptography@xxxxxxxx, cypherpunks@xxxxxxxx
Subject: Re: Challenge to TCPA/Palladium detractors
small discussion of security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk

slightly related
http://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?

also slightly related, both the tpm chips and various card chips are similar ... some with eal3-high or eal4-high evaluation. however these ratings are typically just for the chip ... or the chip with the barest of software .... not the completely delivered operation environment.

trying to get an EAL5-high or EAL6-high on the complete package .... would include getting evaluation on things like any crypto (for those chips employing crypto) ... which is a interesting whole 'nother exercise. slightly related:
http://www.garlic.com/~lynn/aadsm12.htm#13 anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa?
http://www.garlic.com/~lynn/2002h.html#71 history of CMS
http://www.garlic.com/~lynn/2002h.html#84 history of CMS
http://www.garlic.com/~lynn/2002j.html#86 formal fips186-2/x9.62 definition for eal 5/6 evaluation

nelson@xxxxxxxx on 8/10/2002 11:01 pm wrote:
Can't be done. I don't have time to go into ALL the reasons. Fortunately for me, any one reason is sufficient. #1: it's all about the economics. You have failed to specify that the cost of breaking into the data has to exceed the value of the data. But even if you did that, you'd have to assume that the data was never worth more than that to anyone. As soon as it was worth that, they could break into the data, and data is, after all, just data.

Ignore economics at your peril.

--
-russ nelson http://russnelson.com |
Crynwr sells support for free software | PGPok | businesses persuade
521 Pleasant Valley Rd. | +1 315 268 1925 voice | governments coerce
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |


Challenge to TCPA/Palladium detractors

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 08/10/2002 11:40 PM
To: cryptography@xxxxxxxx, cypherpunks@xxxxxxxx
Subject: Re: Challenge to TCPA/Palladium detractors
oops, finger slip that should be
http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk

aka 2001h.html not 2002h.html ....

lynn.wheeler@xxxxxxxx on 8/10/2002 11:25 pm wrote:
small discussion of security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk


Feasability of Palladium / TCPA

Refed: **, - **, - **
From: Lynn Wheeler
Date: 08/12/2002 11:22 AM
To: Tim Dierks <tim@xxxxxxxx>
cc: cryptography@xxxxxxxx
Subject: Re: Feasability of Palladium / TCPA
there are two possible answers:

1) it just has to be at least as secure at the risks (doing something might improve the situation so that some number of vulnerabilities ... but not all ... are minimized).

2) one of the excuses for not spending the money on secure software ... as opposed to the current process .... is it wouldn't improve anything because everything else is insecure. so there is a huge chicken and egg situation .... no single operation should do anything about security because the hundred of other organizations that are involved in producing insecure components are not doing anything about security (nobody should do nothing because everybody else is doing nothing).

I've been railing about the buffer-overflow vulnerability every since we did the vulnerability analysis for ha/cmp in the late 80s .... it is just another on the list of things that need fixing also. some general stuff:
http://www.garlic.com/~lynn/subtopic.html#fraud
http://www.garlic.com/~lynn/subtopic.html#assurance

tim dierks.org on 8/12/2002 10:12 am wrote:
I haven't done an in-depth reading of available information of Palladium/TCPA specifications, but my understanding is that there is a private key stored in hardware and a contiguous chain of trust that extends

from the hardware/BIOS through the OS to an application, with each level validating the superior levels; specifically, the hardware/BIOS validates the OS as compliant, and then the OS validates an application's identity. The OS then vouches for the application to the BIOS, giving the application

the ability to make indirect use of the hardware private key in order to engage in application-level communication with an attestation of the integrity of all levels (hardware, OS, application).

Here's my question: who thinks this can actually be made secure? Having spent some time looking at such security issues, developing software, and watching security alerts fly by for software, I think there's almost no chance that the attestations made by the OS can be very secure.

Given the nature of PC software platforms, with the size, complexity, and diversity of vendors, I think it is guaranteed that there will be software bugs that will allow attackers to run rogue code inside another application's address space or otherwise cloak themselves in another application's trust attestation. The attacker can thus get access to protected secrets or the ability to convince a remote system that they are an authentic & secure software instance.

Does anyone not believe that there's not going to any buffer-overflow type bugs in drivers for third-party sound cards that will allow an attacker to execute code as some other application? And what can be done about? It's certainly not viable to require dramatically more code review & security in

applications & drivers: I don't think Microsoft & Intel are willing to sacrifice the economic viability of the platform on the throne of DRM. It's

also not acceptable to customers to require that all code running on the platform be signed & authorized (unless you're willing to destroy the industry of software developers who are not large enough or reliable enough

to get such signatures, including the entire open source industry). I don't

believe it's technologically feasible to design a software platform that can reliably determine the complete chain of control resulting in an API entry-point being called. (Among other things, you can execute an attack without having your return address address on the stack.)

Bottom line, I don't think that TCPA or Palladium will be reliable enough to really constrain those who wish to penetrate it. Given that, I don't think that there will be as high a value put on the technology by vendors &

rights holders (since their stuff can be stolen by others anyway). If there's not a high differential value to these architectures, then presumably the market will not support a high differential price, and the technologies will not see widespread acceptance.

- Tim Dierks

PS - I'm looking for a job in or near New York City. See my resume at <http://www.dierks.org/tim/resume.html>


Overcoming the potential downside of TCPA

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/14/2002 04:36 PM
To: bear <bear@xxxxxxxx>
cc: Joseph Ashwood <ashwood@xxxxxxxx>, cryptography@xxxxxxxx
Subject: Re: Overcoming the potential downside of TCPA
Just because some cars have anti-theft devices that can be defeated in seconds .... doesn't make all auto anti-theft devices useless.

so you have currently have an environment that has no protection and everything is totally wide open.

lets say a hardware chip that currently has no tamper resistance and a whole infrastructure is put in place based on having security based on a hardware chip. Hypothetically it eliminates allt the non-physical attacks. however there are still vulnerabilities involving physical attacks on the hardware components.

Would that be beneficial? Would it be helpful to eliminate all network and electronic attacks leaving only physical attacks?

One of the issues is that some amount of the population actually has some sensitivity for dealing with physical attacks. Part of the current problem is many people don't have any experience dealing with electronic and non-physical attacks. I would consider the elimination of all electronic and network attacks as an interesting prospect.

So what does the world currently do about physical attacks.

Some organizations .... if they physical own the device and trying to protect against outside attacks .... might put the device under armed guards.

If it is DRM, where the chip is, in effect, acting as a proxy agent on somebody else's behalf then there is issue about protection about physical attacks by the person in possesion of the device. Tamper-resistance just ups the cost of a succesful attack. One could hypothesis the value of something that is always in excess of the protection measures. .... i.e. security proportional to risk; aka ... regardless of the protection measures there could always be some hypothetical value making it worth the cost of mounting an attack.

The hypothetical DRM risk is possibly 90 percent of the infrastructure (not single, here & there isolated copying .... copying being done everywhere). Would some TCPA possibly both increase the percent of authorized copies and reduce the unauthorized copies (i.e. a method to reduce unauthorized copies to zero is by not publishing the works at all). The issue isn't absolutely ruling out unauthorized copies .... the issue is increasing the percent of authorized copies.

So hypothetically, the environment has reduced all the vulnerabilities and attacks to attacks just on the physical chip. It is possible that market forces could react to such an environment and opportunity. One opportunity might be higher priced PCs that have chips evaluated at EAL7-high with loads of tamper-resistance along with certain works are only available on machines having the higher evaluated chips.

random mutterings about parameterised risk management:
http://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
http://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature initiative stalled
http://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech9 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo2 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo3 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
http://www.garlic.com/~lynn/aepay3.htm#x959risk1 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment standard issue
http://www.garlic.com/~lynn/2000.html#46 question about PKI...
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.

bear@xxxxxxxx on 8/14/2002 9:19 am wrote:
The problem with this idea is that TCPA is useless. For all the useful things you are thinking of, you need TCPA plus an approved key. The only way you are going to get an approved key is inside a tamper-resistant chunk of hardware. If you should manage to extract the key, then yes, you'll be able to create that CD. But the idea is that you, the hardware owner, are not authorized to extract the information contained in your own hardware. I find the idea of "owning" something without having the legal right to open it up and look inside legally dubious at best, but I'm no lawyer....

The idea is that you shouldn't get anywhere without hardware hacking. The people doing this have decided hardware hacks are acceptable risks because they only want to protect cheap data -- movies, songs, commercial software, whatever. They are sticking to stuff that's not expensive enough to justify hardware hacks.

However, if this infrastructure does in fact become trusted and somebody tries to use it to protect more valuable data, God help them. They'll get their asses handed to them on a platter.

Bear


Overcoming the potential downside of TCPA

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/15/2002 02:41 PM
To: bear <bear@xxxxxxxx>
cc: Joseph Ashwood <ashwood@xxxxxxxx>, cryptography@xxxxxxxx
Subject: Re: Overcoming the potential downside of TCPA
hum, i guess i somewhat view the situation somewhat in flux ... maybe analogous to the period when there was a claim that only auto mechanics should be allowed to drive automobiles .... and only automobiles that required mechanics to drive them should allowed to be built. The situation today is that while anybody could build their own automobile from scratch, few actually do.

as to putting together reliable configurations ... i've had a little experience ... possible you've heard of some of it.

there was this little client/server startup in the valley that was interested in implementing server transactions ... with this emerging technology that required some amount of vetting and maturing. during the year that my wife and i worked with them on the implementation and deployment they moved from menlo park to mountain view and changed their name from mosaic to netscape .... the emerging technology is sometimes referred to as SSL or HTTPS and the transactions they wanted to do are sometimes now referred to as electronic commerce. Possibly you have heard of some of this? Does Netscape, SSL, HTTPS, or electronic commerce ring any bells?

some past integrity and security suggestions:
http://www.garlic.com/~lynn/2001j.html#5 E-commerce security
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything

no matter how much I wanted the industry to not allow operation of systems that didn't meet certain criteria, I wasn't succesful.

thread somewhat analogous to this one:
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn1
http://www.garlic.com/~lynn/aadsm5.htm#asrn4

slightly related mumblings on security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61 Security Proportional to Risc

rant about maybe in a couple thousands years security engineering will reach the maturity level of civil engineering for bridge building
http://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several common SSL implementations?

How many people participate in the creation of the bridges and roads that you drive on ... so that you could examine the safety of the road bed before it is paved over?

bear@xxxxxxxx on 8/14/2002 9:54 pm wrote:
... wide ... open ... <<boggle...>> Do you even know what Kerchoff's Principle IS?! Look, I've been trying to hold back on actual ranting, but... but... you really don't get it, do you?

<rant mode ON -- sorry guys....>

On the contrary, I have one box with all the protection I want: it's never connected to the net at all. I have another box with all the protection that I consider practical for email and web use. Both run only and exactly the software I have put on them, which I obtained from sources trusted to me and which do not and CAN NOT require any further interaction or authorization whatsoever to run their software. I have selected software, on purpose, which denies someone who is not me even the bare possibility of restricting my ability to run it at some future time. I have the source code.

That is what I mean when I talk about trusted computing. I trust that my software does what it says it does, is completely open to inspection and verification by first, second, and third parties, and cannot be denied to me at any point after I have come to depend upon it, whether or not I have a net connection at the moment to interact with its creators. I trust that I cannot be singled out remotely to have a sniffer installed on my local machine through a backdoor. I trust that code I can inspect at the level of machine instructions is code that cannot keep secrets from me or forever conceal malign intent. I trust that I cannot be forced to depend on any single commercial software provider, whether it be for the OS or for the "trusted" compiler which can, of course, come from only one source. I trust that coercive "upgrades" done for the sake of incompatibility with existing code, do not and cannot happen automatically given my system configuration.

That is trusted computing sir, and TCPA/Palladium is a huge step backward from it. Anything that runs ANY code that cannot be inspected, or which keeps data that cannot be inspected, is running code that cannot be trusted.

TCPA/Palladium does not provide trusted computing. At least not computing that I can trust in the way I trust what I've got now. In fact, from my POV, TCPA/Palladium look like ways to enable the running of software which I CANNOT trust. Imagine my excitement at the prospect.

This is a cryptography mailing list. Do we even want to count the number of times commercial software providers have come up with some crap and claimed it was secure, and been just lying to us? Do I have to recount all the proprietary, snake-oil encryption systems that relied for its security on not being inspected? Do I have to recount the number of ways that unstudied security designers have given us their best efforts and had them shot down by professionals in seconds? Do we have to speculate about what can happen if the clowns who employ them think they'll never be caught?! We've all been around the block enough to know this by now:

Kerchoff was absolutely right. A hundred and twenty years since he elucidated the Principle has not changed a thing.

NOBODY has the manpower or time to find all their bugs in-house.

If you can't inspect the machine code (and preferably the source) then you are looking at something that is not and can never be made secure.

Now, you're talking about a system that gives people the opportunity to HIDE THE CODE, and telling us that's security?! What the hell are you smoking?! You are confusing real security mistakes with the ability to DETECT real security mistakes!

<Rant mode OFF -- I'm getting too angry about this, I need to take a break from this topic. ... >

Bear


TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/15/2002 08:49 PM
To: Adam Back <adam@xxxxxxxx>
cc: Joseph Ashwood <ashwood@xxxxxxxx>,
cryptography@xxxxxxxx, cypherpunks@xxxxxxxx
Subject: Re: TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
I arrived at that decision over four years ago ... TCPA possibly didn't decide on it until two years ago. In the assurance session in the TCPA track at spring 2001 intel developer's conference I claimed my chip was much more KISS, more secure, and could reasonably meet the TCPA requirements at the time w/o additional modifications. One of the TCPA guys in the audience grossed that I didn't have to contend with the committees of hundreds helping me with my design.

There are actually significant similarities between my chip and the TPM chips.

I'm doing key gen at very first, initial power-on/test of wafer off the line (somewhere in dim past it was drilled into me that everytime something has to be handled it increases the cost).

Also, because of extreme effort at KISS, the standard PP evaluation stuff gets much simpler and easier because most (possibly 90 percent) of the stuff is N/A or doesn't exist

early ref:
http://www.garlic.com/~lynn/aadsm2.htm#straw

or refs at (under subject aads chip strawman):
http://www.garlic.com/~lynn/x959.html#aads

random evauation refs:
http://www.garlic.com/~lynn/aadsm12.htm#13 anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa?
http://www.garlic.com/~lynn/2002j.html#86 formal fips186-2/x9.62 definition for eal 5/6 evaluation

adam@xxxxxxxx on 8/15/2002 6:44 pm wrote:
I think a number of the apparent conflicts go away if you carefully track endorsement key pair vs endorsement certificate (signature on endorsement key by hw manufacturer). For example where it is said that the endorsement _certificate_ could be inserted after ownership has been established (not the endorsement key), so that apparent conflict goes away. (I originally thought this particular one was a conflict also, until I noticed that.) I see anonymous found the same thing.

But anyway this extract from the CC PP makes clear the intention and an ST based on this PP is what a given TPM will be evaluated based on:

http://niap.nist.gov/cc-scheme/PPentries/CCEVS-020016-PP-TPM1_9_4.pdf

p 20:
| The TSF shall restrict the ability to initialize or modify the TSF
| data: Endorsement Key Pair [...] to the TPM manufacturer or designee.

(if only they could have managed to say that in the spec).

Adam
--
http://www.cypherspace.org/adam/


draft-ietf-pkix-warranty-ext-01

Refed: **, - **, - **
From: Lynn Wheeler
Date: 08/16/2002 09:52 AM
To: <asturgeon@xxxxxxxx>
cc: "Denis Pinkas" <Denis.Pinkas@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: RE: draft-ietf-pkix-warranty-ext-01
somewhat aside, note that most financial risk management has moved past stale, static data ... even on a per transaction basis .... since the exploits/attacks on such infrastructures started using aggregation. the old-style "signing limit" checks attempted to manage risk & liability on a per transaction basis .... but quickly found that they were extremely vulnerable to aggregation risks. That is one of the forces leading to online operation in the financial industry (as opposed to an offline operation with trivial per transaction limits and no support for online management of aggregation).

A similar model might be various kinds of automobile insurance with per transaction limits .... however any aggregation risks tend to happen over a long enough period that processing tends to occur in "relative" real time (and they have been able to manage aggregation risks ... if nothing else by canceling the policy).

The problem for the insurance industry is given the alternatives between an offline paradigm and an online paradigm .... where the offline paradigm with basically per transaction limits .... and an online paradigm that can handle both per transaction and aggregation limits .... the offline paradigm leaves them wide-open to aggregation attacks/risks. The problem for a certificate is that the policy & representation is static per transaction risk/limit ... and any migration to an offline paradigm with both support for per transaction as well as aggregation risk/limits obsoletes the requirement for the certificate.

Somewhat analogous is the hardware token (as a credential) ... when used purely in an offline mode, there have been all sorts of aggregation risk. Typically the remedial action is to limit the per transaction exposure to a very trivial dollar value .... as a mechanism for attempting to bound the aggregation risk/exposure.

The problem for an indusrance industry risk managing in establishing policy rates .... isn't the per transaction limit risk .... but what is the worst case risk scenario for an offline paradigm with regard to transaction aggregation. The certificate doesn't contain a dynamic transaction count and/or any sort of dynamic value aggregation .... and/or even idea of how many times it has been used ... which is the unknown exposure facing the risk manager having to establish policy rates aka when they look at the risk exposure for establishing insurance rates .... it is the total risk exposure. A single per event bound doesn't tell them anything unless they can also put a reasonable bound on the maximum number of such events .... to arrive at the total risk.

Smartcard in CD

From: Lynn Wheeler
Date: 08/31/2002 02:15 PM
To: ray@xxxxxxxx
cc: cryptography@xxxxxxxx, HugheJP@xxxxxxxx,
Michael_Heyman@xxxxxxxx, ptrei@xxxxxxxx
Subject: Re: Smartcard in CD
iso format/standard is not only thickness but also flexibility .... even some proximity (iso 14443) cards have had problem in the past with flexibiity standards because flex tests would stress the coils in the plastic and cause the connection to the chip to break.

ray@xxxxxxxx on 8/31/2002 4:57 arm wrote:
Contactless smart cards typically have coils in the card and the magnetic field is generated by the reader.

Capacitive coupling is an alternative but requires more precise alignment and thus doesn't really provide a proximity/vicinity card like inductive coupling does.

On-board batteries are hard to fit on an ISO-format smart card but maybe with the new ultra-thin batteries that's no longer the case. Batteries are perhaps more suitable for a CD.


draft-ietf-pkix-warranty-ext-01

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/02/2002 01:38 PM
To: Denis Pinkas <Denis.Pinkas@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
asturgeon@xxxxxxxx, ietf-pkix@xxxxxxxx
Subject: Re: draft-ietf-pkix-warranty-ext-01
In addtion to insurance premiums proportional to risk
http://www.garlic.com/~lynn/aadsm12.htm#20draft-ietf-pkix-warranty-ext-01
There are actually a couple of issues:

a) security/insurance proportional to risk. in the online world ... the RP/merchant may get a surcharge per transaction that pays for insurance on per transaction basis. they may also have one-time disaster insurance ... that is sort of independent of the number of transactions ... but represents some total value that is at risk

b) the entity at risk pays for the insurance. typically the business arrangement is between the CA and the entity being certified. if it is a merchant certificate then the CA can charge a little bit more for the insurance to cover damages where the merchant might get sued. if it is a consumer certificate .... the consumer is being charge but typically the merchant is still the one at risk; not the consumer (this is because there are special provisions favoring consumers in retail transactions .... this wouldn't apply between two equal parties in commercial transactions). Ignoring for a moment the issue of whether (offline paradigm) certificates are needed in the online world, there is a separate issue that the entity primarily at risk is not party to the CA/consumer business transaction. There is nominally no direct business relationship between the CA & the merchant in the case of consumer certificates .... so it is difficult for a merchant to establish liability (possibility other civil legal issues) against the CA. Difficult for a merchant to sue a consumer because of CA liability to the consumer.

CAs either have to

1) convince consumers that certificates are good for something that consumers have at risk (say identity theft) for which the CA can justify charging the consumer extra to cover the cost of doing business as well as ancillary things like insurance ... or

2) CAs have to revamp the business model so that there is a contractual relationship between the CA and the RP ... and be able to charge on the basis of that ... or

3) get gov. to pass mandated certificate requirements.

now ... if

1) if consumers (or any party) aren't at risk ... it is hard to get them to (directly) pay anything

2) if a contractual relationship between CAs and RPs can be fabricated .... then you are likely to have relying-party-only certificates .... the RPs pay either directly or indirectly (so that there is a contractual relationship with the CA on which money flow can be based) ... the RPs will pass on the cost for relying-party-only certificates to the consumer .... but it is a business solution to match the money flow with who is at risk and the contractual relationships. The downside here is that it is trivially possible to show that relying-party-only certificates in an online, transaction world are redundant and superfluous. This establishes some basis for civil litigation.

3) if you can get a gov. to pass bills mandating something ... then you can eliminate any civil liability issues with the contractual relationships and money flow not matching parties at risk.

I believe there has been lots of past discussions regarding the difficulty in the commercial world of establish money flow & risk with the RP in a standard CADS paradigm (the RP being at risk but original CADS business model had no contractual relationship between the CA and the RP). I believe the FED GSA PKI stuff has tried to resolve this by contorting the business model that the contractual relationship is between GSA and the CAs .... and that the CAs are providing (relying-party) certificates to end-users. CAs may levy a surcharge on the end-users for the certificate issuing ... but the business relationship is not between the CA and the end-user .... it is between the CA and GSA (the relying party). Note that since the business relationship is between the CA and the GSA, the contract(s) call out the warranties and liabilities. In this case, certificates would be considered a service provided and independent of the contract documents and the specifications of T&Cs, warranties, liabilities and things like insurance.

The next step would be to get some kind of legislative bill passed that mandates such certificates .... even when it can be proven that they are redundant and superfluous in an online world.

random refs on relying party certificates:
http://www.garlic.com/~lynn/subtopic.html#rpo

denis.pinkas@xxxxxxxx wrote:
Alice,

I concur with many of the arguments raised by Anders. It is very scarce, but this time it happened, thanks to your draft. :-)

I believe that sufficient arguments have been raised against the progression of this draft, as it stands, which does not even explicitly states, for a naive reader, what the warranty is about.

The warranty is concerned with the liability of the CA, more precisely, only errors made by the CA personal or attributed to the CA during the management of the certificate, e.g. at the time of registration of the subject, when issuing the certificate, when handling revocation requests or when making available revocation status information.

Regards,

Denis


10 choices that were critical to the Net's success

Refed: **, - **, - **
From: Lynn Wheeler
Date: 09/09/2002 03:19 PM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: dcsb@xxxxxxxx
Subject: Re: 10 choices that were critical to the Net's success
a couple additional points

1) arpanet had a single homogeneous implementation using the IMPs. the internal network effectively had gateway function in every node and wasn't subject to the arapnet limitations of a homogeneous network. this wasn't corrected until 1/1/83 switch over .... where it finally got "internet" and the idea of gateways that could handle the interoperability between heterogeneous environments. at the 1/1/83 switch over there were less than 255 nodes. around late '84 there were: http://www.garlic.com/~lynn/2002k.html#26

2) i would consider the AUP a temporary, transient issue. i would claim more significant was effectively huge amount of unused capacity (in places like dark fiber) and the owners of this capacity to make significant excess resources (over and above what was actually called for in NSFNET1/NSFNET2 backbone) as an incubator environment to help evolve new, bandwidth hungry applications. I would assert that the provision of those resources were more significant than the AUPs. Some NSFNET backbone:
http://www.garlic.com/~lynn/2002k.html#12
extract of email i got announcing the award and asking to participate
http://www.garlic.com/~lynn/2000e.html#10

3) lots of people ignored the gov. and other large structured organizations with regard to GOSIP and other OSI mandates.

4) IETF standards policy of needing two interoperable implementations for standard progression. The whole ISO/OSI seemed to go forth with no concept whether anything was actually implementable in any practical sense.

5) large number of educational institution networking nodes in bitnet, earn and other networks that addition of gateways could significantly increase total network coverage. a earn specific ref from 1984:
http://www.garlic.com/~lynn/2001h.html#65

misc. other refs:
http://www.garlic.com/~lynn/internet.htm#0
http://www.garlic.com/~lynn/subtopic.html#networking

rah@xxxxxxxx on 9/9/2002 11:29 am wrote:

http://www.siliconvalley.com/mld/siliconvalley/business/columnists/4029770.htm?template=contentModules/printstory.jsp

Posted on Sun, Sep. 08, 2002

10 choices that were critical to the Net's success

By Dan Gillmor
Mercury News Technology Columnist

In our modern, corporate culture, the rise of the Internet is a happy accident. In its roots and growth, says Scott Bradner, the Net never had a business model.

How did technologists, government officials and a host of other early players turn something with no obvious business model into a system that has become so intrinsic to the new century? A series of decisions proved critical -- choices that helped turn data transport into a commodity business and put the power in users' hands, not in the centralized telecommunications companies' controlling grasp.

At a telecom conference in Massachusetts last week, Bradner, senior technical consultant at Harvard University and a longtime leader in the formation of Internet standards, listed 10 crucial decisions along the way. (You may have other candidates; send them to me and I'll list them on my Web page). Here are Bradner's picks:

1) Make it all work on top of existing networks. Designers deliberately didn't try to build a single, new über-data network -- it was about ''networks, not a network,'' Bradner observes. This meant supporting multiple network types by putting a simple set of rules, now called the Internet protocols, on top. This added layer was wide open for innovation, not controlled by a few players.

2) Use packets, not circuits. Telephone networks open a circuit from one phone to another, keeping the connection open until the call is ended. The Internet splits messages into little packages called packets, which are sent to their destination by various routes and at various times. This was a radical idea at the time, but it has been one of the qualities that makes the Internet so basically reliable and resilient under stress.

3) Create a ''routing'' function. Stand-alone boxes along the way from point to point make instant decisions on what route to send each packet by, reacting to failures in the networks. Again, this was a decentralizing function that enhanced reliability.

4) Split the Transmission Control Protocol (TCP) and Internet Protocol (IP), which are generally used together in much of what we do on the Net and are called TCP/IP. Originally they were meant to be tied together in a single service designed to guarantee that the stream of data would get to its destination complete and in perfect order. To do this, however, would have given network services far less flexibility. IP by itself offers an unreliable but still enormously valuable service, simply sending the packets through the network without checking to see if they all get there.

TCP makes sure, among other things, that they actually do get there. So an application can use TCP if it cares most about reliability, while another application can use IP (and other protocols) if it's more concerned with timeliness -- such as an Internet phone call -- where losing a few packets matters much less than getting most of the data there on time.

5) The National Science Foundation (NSF) funds the University of California-Berkeley, to put TCP/IP into the Unix operating system originally developed by AT&T. Berkeley thereby created a full but low-cost network operating system, along with a full suite of network applications, that computer start-up companies flocked to use in their boxes. It was, says Bradner, ''a way to get into the networking game without spending a lot of money.'' So it spread fast.

6) CSNET, an early network used by universities, connects with the ARPANET, the Internet precursor network operated by the Pentagon's Advanced Research Projects Agency. ARPA funded much of the early technical work on what later became the Net. ARPANET use had been restricted solely to government-funded individuals. The connection was for e-mail only, but it led to much more university research on networks and a more general understanding among students, faculty and staff of the value of internetworking. When students graduated, they sought employers that had the technology.

7) The NSF requires users of the NSFNET to use TCP/IP, not competing protocols. This decision about the NSFNET, which was originally created to connect supercomputer centers, forced wider availability of the TCP/IP protocol, and helped prevent a wasteful ''proliferation of miscellaneous transport protocols for the Internet,'' Bradner says.

8) International telecommunications standards bodies reject TCP/IP, then create a separate standard called OSI. TCP/IP, remember, was designed as a low layer on top of which other applications, such as e-mail, would be created. OSI was carrier-centric, a suite of protocols that included things like e-mail. Had TCP/IP been accepted and then co-opted by the international groups and telecom companies, things we now take for granted might not have appeared, or might have been under central control. One the fundamentals of the Net is we can create new protocols on top of IP, as Tim Berners-Lee did to create the World Wide Web, says Bradner -- ''and we don't have to have permission of the carriers to do that.

9) The NSF creates an ''Acceptable Use Policy'' restricting NSFNET use to noncommercial activities. Although this rule grew blurry, it was largely heeded despite fierce criticism. The result was an incentive to create commercial network providers. The commercial providers created a huge business of long-haul ''backbone'' and local carriers upon which the Internet relies today.

10) Once things start to build, government stays mostly out of the way. If the Internet suffered from a lack of regulation, Bradner says, it was ''a good suffering'' for all of us.

-----------------
R. A. Hettinga <mailto: rah@xxxxxxxx>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 17 Sep 2002 16:35:08 -0600
To: jon@xxxxxxxx
Subject: Re: Interests of online banks and their users [was Re: Cryptogram:  Palladium Only for DRM]
Cc: Adam Shostack <adam@xxxxxxxx>,
   cryptography <cryptography@xxxxxxxx>
At 01:07 PM 9/17/2002 -0700, jon@xxxxxxxx wrote:
As far as I know, banks assume that a certain percentage of their transactions will be bad and build that cost into their business model. Credit and ATM cards and numbers are as far from secure as could be, far less secure than somebody doing online transactions from a Wintel machine on an unencrypted connection, let alone an encrypted one. Until somebody takes full advantage of the current system and steals a few trillion dollars in one day, the problems are easier to deal with than a solution. Until that happens, there's no reason for banks to go through the pain of dealing with or requiring Pd.
-Jon Simon


note that EU finread standard attempted to address some of this. an external (secure, finread) token acceptor device with secure display and secure pin entry. The hardware token is used to "sign" the (financial) transaction .... PIN code is entered into the finread device and goes directly to the hardware token (w/o passing thru the PC). Critical pieces of the transactions passes thru the finread device on the way to the (signing hardware token) and is displayed on the secure display ... which then requires the PIN to be entered to confirm the transaction.

There is the issue of 3-factor authentication

something you have (hardware token)
something you know (pin)
something you are (biometrics in addition to &/or in place of PIN)

besides the straight-forward use of signatures to authenticate the source of the transaction ... there is the nominal legal requirement associated with physical signatures ... i.e. did you intend to sign what you signed aka is what you "see" what you signed ... and do you confirm that you actually want the hardware token to sign what you "see".

A lot of digital signature seems to address the technology part of authentication ... and then sometimes (just because the term "signature" is used as part of the description of the technical procedure) that all technical implementations of the process referred to as "digital signature" is legally equivalent to "physical signatures" (even when no aspects of intention have been satisfied).

random past finread & intention posts:
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
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#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
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#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/2000.html#0 2000 = millennium?
http://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...
http://www.garlic.com/~lynn/2000f.html#79 Cryptogram Newsletter is off the wall?
http://www.garlic.com/~lynn/2001f.html#39 Ancient computer humor - DEC WARS
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#61 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#51 future of e-commerce
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001j.html#46 Big black helicopters
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral infection?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001n.html#70 CM-5 Thinking Machines, Supercomputers
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002f.html#55 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/2002l.html#24 Two questions on HMACs and hashing
http://www.garlic.com/~lynn/2002l.html#26 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002l.html#28 Two questions on HMACs and hashing



Cryptogram: Palladium Only for DRM

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 17 Sep 2002 16:40:53 -0600
To: daw@xxxxxxxx (David Wagner)
Subject: Re: Cryptogram: Palladium Only for DRM
Cc: cryptography@xxxxxxxx
At 06:02 AM 9/17/2002 +0000, David Wagner wrote:
I wasn't thinking of pure software solutions. I was thinking of a combination of existing hardware + new software: use the MMU to provide separate address spaces, and use a secure VM or OS kernel to limit what those processes can do. As far as I can see, this can provide just as much protection against viruses for your bank account as Palladium can.

In general, with software and existing hardware working together, I suspect we can already do everything Palladium can do, except for the DRM and related applications founded on taking control away from the owner of the machine. Maybe I'm missing something. Still, it seems to me that Palladium would much more compelling if it left out the tamper-resistant chip and gave up on the semi-coercive DRM-like applications.


couple refs to multics study
http://www.garlic.com/~lynn/2002m.html#8 Backdoor in AES ?
http://www.garlic.com/~lynn/2002m.html#10 Backdoor in AES ?

I-D ACTION:draft-ietf-pkix-usergroup-01.txt

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/03/2002 05:46 PM
To: Michael StJohns <msj@xxxxxxxx>
cc: anders.rundgren@xxxxxxxx, ietf-pkix@xxxxxxxx
Subject: Re: I-D ACTION:draft-ietf-pkix-usergroup-01.txt
The bit strings are essentially r/o (typically stale and significant subset) of trust information in some sort of trust repository.These trust bit strings were originally designed for use in offline environments where there was something inhibiting the access to the actual trust repository. They can currently be useful in environments where it isn't worthwhile to know the actual timely &/or aggregated information ... for instance you don't need to know things like whether your online account is active, your have sufficient funds in your account and/or you have exceeded your credit limit (aka useful for low or no value operations).

the scenario is somewhat similar to the credit card industry of the '60s that was non-electronic and offline. In the '70s, the online economics was sufficient that it allowed a direct transition to electonic and online (with some residual non-electonic/offline lingering on). The certificate actrivity of the '80s was essentially a paradigm step backwards in time ... to the '60s ... but with a offline electronic ... rather than a offline non-electronic.

special purpose types of certificate are in effect the same or very similar to the relying-party-only certificates that various financial (and other) institutions were making use of by at least the mid-90s. However, it is trivial to show that for any kind of value, online operation the relying-party-only certificates are redundant and superfluous (again leaving just the domain of offline, low/no value operations).

misc. past r-p-o certificates references:
http://www.garlic.com/~lynn/subtopic.html#rpo

and of course ... the misc postings on end-game of why eventually TTPs would even be issuing server domain name certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

michael stjohns on 10/3/2002 3:44 pm wrote:
A 100% outsourced PKI should also be able to generate certificates which use Subject and IssuerAltName extensions for at least the specified name forms (e.g. RFC822 and DNS). This is just another plugin, and if it gets into the normal PKI specification, a 100% outsourced PKI should be able to issue this type of certificate. Its not a reasonable argument to make that because it wasn't specified before no one will implement or use it. If it doesn't have sufficient functionality, or breaks something - that's the argument I'd actually like to hear.

Also, certificates are just bit strings - I don't need or want to use the same certificate over and over again to access different resources. That requires way too much centralization. Let me give you an example: Should the same certificate I use to access local company resources be the same one I use to make purchases on the internet which get charged to my Visa card? I hope not. Let's look at the trust relationships. In the former, I need a trust relationship with my local sysadmin who also has a trust relationship with the local resources. By virtue of his/her position he can establish a transitive trust relationship between me and the resources by issuing me a certificate. In the Visa case, I have a relationship with Visa as does the merchant (the transaction Acceptor). We both have credentials issued to us by Visa which allow us to participate in a commercial exchange under Visa's rules. The acceptor doesn't need to know who I am, it just needs to know that Visa accepts me (or rather the holder of the certificates private key) as someone who has a trust relationship with Visa for the purpose of commercial exchanges of a particular type. I don't need a global identity for that set of transactions. And indeed, a global identity has all sorts of privacy issues.

I guess what I'm saying is that I'm not sure why paying Verisign to issue client certificates makes a lot of sense.


Employee Certificates - Security Issues

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/04/2002 07:31 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: Employee Certificates - Security Issues
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 superfluous ... 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.

anders.rundgren@xxxxxxxx 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


Employee Certificates - Security Issues

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/04/2002 07:54 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Juergen Brauckmann" <brauckmann@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: Re: Employee Certificates - Security Issues
there are two other scenarios given in
http://www.garlic.com/~lynn/x959.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 superfluous)

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

Employee Certificates - Security Issues

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/04/2002 01:32 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, "Guida, Richard [JJCUS]" <RGuida@xxxxxxxx>
Subject: Re: Employee Certificates - Security Issues
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, static copy of such a record (aka into a certificate) ... for their own use .... is frequently redundant and superfluous 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 and superfluous 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 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


Employee Certificates - Security Issues

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/07/2002 08:01 AM
To: "Särs, Camillo" <Camillo.Sars@xxxxxxxx>
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
"Särs, Camillo" <Camillo.Sars@xxxxxxxx>, ietf-pkix@xxxxxxxx,
"Guida, Richard [JJCUS]" <RGuida@xxxxxxxx>
Subject: RE: Employee Certificates - Security Issues
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 <camill.sars@xxxxxxxx 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.

The Bank-model Was: Employee Certificates - Security Issues

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 10/09/2002 08:35 AM
To: "Särs, Camillo" <Camillo.Sars@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, "J Adrian Pickering" <jap@xxxxxxxx>
Subject: RE: The Bank-model  Was: Employee Certificates - Security  Issues
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/x959.html#x959

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

F-Secure products: Securing the Mobile Enterprise


Employee Certificates - Security Issues

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/10/2002 07:49 PM
To: "Hamrick, Matt" <HamrickM@xxxxxxxx>
 cc: "'ietf-pkix@xxxxxxxx'" <ietf-pkix@xxxxxxxx>
Subject: RE: Employee Certificates - Security Issues
.... european financial institutions and various endevers ... like SET ... went to relying-party-only certificates ... no visible name, no visible 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

HamrickM@xxxxxxxx on 10/10/2002 2:50 pm wrote:
... snip ...

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.

... snip ...


two questions about spki

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/11/2002 01:38 PM
To: Sameer Ajmani <ajmani@xxxxxxxx>
cc: spki <spki@xxxxxxxx>, Zishuang Ye <Zishuang.Ye@xxxxxxxx>
Subject: Re: two questions about spki
another side of the trust issue ... is the context that trust is suppose to operate in. in many cases the trust issues have to do with permissions and authorization contexts.

there is something of an analogy to the original certificate design point .... method of authentication in a basically offline world .... where it is not possible to perform a real-time, online verification .... and there needed to be some sort of construct that represented a stand-in, substituting for direct, real-time contact with the authority agency responsible for whatever information is under consideration. In large number of situations the cost/benefit of performing realtime, online operations has changed to the point that stale, static certificates are an akane leftover from some other era.

so this particular context changes from the straight online/offline paradigm scenario to things like role-based access controls (aka the context of permissions and authorizations). One of the issues emerging in the role-based access control is that as the world gets more complex and cost effective technology appears for dealing with such complexity ... it becomes possible to deal with more complex issues than simple role-based access controls (i'm using role-based access controls here as an example that could be mapped to a certificate-based methodology since the roles can map to labels or classifications that relatively easy to map to certificate fields).

I would assert that role-based access controls are a security administrators methodology for simplifying the complexity that they have to deal with. However, underlying roles tend to be collections of fine-grain entitlements where frequently in the real world ... individuals may have been assigned multiple roles (i.e. real world is seldom as simple as some of the methodologies try and make it). Various of the role-based access control mechanisms are evolving to deal with the intersections of sets of fine-grain entitlements. These emarging(?) methodologies are almost all online, real-time, dynamically based solutions and not readily conducive to mapping into a simplistic offline category/label based paradigms (which certificates are forced into).

Coming at it from the opposite facet ... rather than looking at simply what is being permitted .... look at what kinds of things can go wrong. Twenty years ago these were much more simplistic and static solutions (also conducive to mapping into certificate-base paradigm). Current technology is starting to deal with real-time patterns that go wrong (fraud, etc). The half-way point has been static permissions with post-failure analysis of audit trails. The emerging technology are things like real-time business processes that actually prevent certain patterns of actions by the same individual (or collections of individuals) ... even if at the microscopic level they have the necessary permissions. You tend to see this much more in real live business process systems that involve value. It is also very synergistic and analogous to emerging technology in the area of network intrusion.

Basically there is a direction towards strong authentication ... and real-time online systems that not only look at permissions associated with individual events .... but also start to deal with patterns or aggregation of events (either from a business process standpoint or a network intrustion standpoint, basically most stuff that involves value). The issue as such processes move towards dynamic, online paradigm .... it becomes harder & harder to force-bit solutions (aka certificates) that were targeted at a much more simplistic, static, offline scenario of 20-30 yeras ago. Financial infrastructures are noted for business process systems that looks for (and possibly inhibits/precludes) collusion patterns between groups of individuals .... even 20 years ago.

on 10/11/2002 11:45 am wrote:
The idea of name intersection was discussed on this list a long time ago (I believe Ron Rivest suggested it). It is not currently part of SPKI. ~ This list would be a good place to discuss whether it should be.

We need to somehow answer the question of how people really think about trust and restricted forms of trust. Is it most natural to think of restricted trust in terms of joint delegation? Or as set intersection? ~ Or perhaps something more complex? Recent certificate systems, such as QCM and SD3, provide even richer languages for defining trust than SPKI.

QCM:
http://www.cis.upenn.edu/~qcm/papers/spe.pdf
SD3:
http://www.research.att.com/~trevor/papers/JimOakland2001.pdf

One of the goals of SPKI is to find a balance between expressive power and simplicity for describing trust. Of course, this is a very hard problem. A nice survey of modern techniques is:

http://www.comsoc.org/livepubs/surveys/public/2000/dec/pdf/grandison.pdf

Sameer


Banks + Legally binding signatures = A mess

From: Lynn Wheeler
Date: 10/21/2002 08:36 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
CC: internet-payments <internet-payments@xxxxxxxx>
Subject: Re: Banks + Legally binding signatures = A mess
recent posting in sci.crypt
http://www.garlic.com/~lynn/2002n.html#16

Electronic Security: Risk Mitigation in Financial Transactions

From: Lynn Wheeler
Date: 10/28/2002 04:13 PM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Electronic Security: Risk Mitigation in Financial Transactions
Electronic Security: Risk Mitigation in Financial Transactions

http://web.archive.org/web/20021020081757/http://www.isalliance.org/news/pressreleases/2002-10-11.66.phtml

two other financial electronic security related URLs

From: Lynn Wheeler
Date: 10/28/2002 04:27 PM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: two  other financial electronic security related URLs
cyber security in the financial services sector

http://web.archive.org/web/20040104220638/http://www.imn.org/2002/a420/index.dhtml

and something that has been around ... electronic crimes task force

http://www.ectaskforce.org/

Legal entities who sign

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/31/2002 08:37 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: Legal entities who sign
lot of legal signature stuff touches on the non-repudiation subject .... which has requirements pretty much orthogonal to anything that might be stated in a certificate (this was discussed some time ago regarding what does a non-repudiation flag actually mean ... aka you can place thousands of bits and megabytes of prose in a certificate ... and it doesn't change the situation).

past refs:
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/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#30 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
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/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
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#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#40 Beginner question on Security
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
http://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card?

<anders.rundgren@xxxxxxxx at 10/31/2002 2:02 am wrote:
According to "e-lawyers", legal entities cannot sign as even a delegated signer must be physical person. This creates huge practical problems and is also quite ridiculous, here thinking of a CEO-certificate/key stored in a locked server- room that not even the CEO may have a key to, and used by business-systems, often completely out of the CEO's control.

Question: Would it be completely unthinkable that a certificate policy stated that the owner of this certificate (which only identifies a legal entity) has through its management approved that the legal entity is to be held legally responsible for all documents signed by this certificate and associated key?'

This solution seems a bit related to Alexander the great and the Gordian knot...
cheers,
Anders Rundgren


Legal entities who sign

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/02/2002 02:15 PM
To: "Jimi Thompson" <jimit@xxxxxxxx>
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: Re: Legal entities who sign
there may be two separate issues. there is contract with human demonstrating that they intended to sign what was signed. Some of this is analogous to some of the click-thru stuff ... where it is demonstrated that there is a high probability that a human actually had to look at the T&Cs as part of doing the click (placing the click at the bottom of long page where the person had to scroll down thru the page to get to the click button). legal signature can carry with it the concept that the person read, understood, agrees, and intended to sign what was signed.

as referenced in the past .... there is a computerized process that involves secure hash and asymmetric cryptography that has a label "digital signature". At the basic level ... the use of the term "signature" in "digital signature" and the term "signature" in "legal signature" .... may only have purely superficial relationship to each other. it is possible to have secure hash and asymmetric cryptography that meets all the technical specifications of a digital signature and carries with it none of the characteristics of a legal signature.

once parties have a binding contract ... the contract can specify all sorts of processes that can be binding for the parties ... aka a particular automated mechanism doing something that is deemed acceptable by both parties. the signing of something by an automated agent can be accepted on good faith if the contract stipulates that it is to be accepted (i.e. say in the case of a PO).

jimit@xxxxxxxx at 11/2/2002 1:44 am wrote:
In order to establish non-repudiation, I would say that you probably need to have the CEO sign the authorized agents signature agreeing that they are authorized under the parameters issued. This should satisfy the non-repudiation needs and still provide for statement about delegation of authority. I think that this solves your problem, as the only time a CEO's key is needed would be to authorize a new agent. The other, more accessible people, would be available to handle day to day business.

Identification = Payment Transaction?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/12/2002 11:05 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Re: Identification = Payment Transaction?
The original design point for (identification) certificates ... was offline email ... aka, connect, exchange email, hangup ... process all email offline. Relying-party/enduser is sitting there with no online connectivity and some need to authenticate originator of the email.

The payment transaction industry in the '60s was an offline, hard-copy operation. They could have gone thru the technology stage compareable to certificate paradigm ... by going to electronic and offline ... but they actually stepped that intermediate step and moved all the way to electronic and online starting in the '70s. Various of the payment related activities associated with certificates in the '90s was a technology step backwards .... to an electronic & offline paradigm ... something that the payment transaction business had skipped over in the '70s.

So in the 90s, the payment transaction business has an online & electronic infrastructure ... and various certificate factions were trying to introduce the concept of a 20 year technology regression with the suggestion for an electronic and offline paradigm ... rather than the more modern online and electronic paradigm that they had been using for 20 years.

One of the places that financial institutions attempted to extend this is somewhat typified by the FSTC "FAST" project. The financial industry already has a modern online & electronic authentication and authorization infrastructure instantiated by the payment transaction network. FAST essentially abstracted that modern online & electronic paradigm from being a payment only infrastructure to a generalized authentication and authorization operation. Basically, the end-user makes an assertion and signs it and gives it to the relying party. The relying party (say merchant) does a real-time, online, electronic transaction sending the assertion to the end-users financial institutioin ... and the financial institution can return a real-time, online electronic message as to the validity of the assertion. Currently the assertions are only about amount of money to pay ... but FAST extended the modern, online, electronic authorization/authentication paradigm to be just about any information.

One of the big advantages of FAST (besides being modern, online, electronic .... rather than old-fashioned offline, electronic paradigm that the financial industry had decided to skip 30 years ago) was that it minimized privacy and indenty information leakage. There wasn't a general purpose identity certification that had a catch all collection of privacy information that somebody, someplace might be interested it. An assertion could be something specific like "over 21" or "over 18" ... or "under 18", .... some assertion that was specific to business process at hand.

The other characteristic was that even in the scenarios where some certificate was forced-fit into such an operation .... they were reduced specifically to relying-party-only certificates .... one of the primary reasons was the big issue of identify & privacy leakage represented by a typical x.509 identity certificate. The relying-party-only certificate was reduced to simply an account number and a public key ... in large part to avoid the privacy exposures. However, a relying-party-only certificate can trivially be shown to be redundant and superfluous since everything that is in the relying-party-only certificate is already replicated in other parts of the business process. In part, this is another demonstration that trying to force fit a offline/electronic solution into the world of real-time, online, electronic environment ... stands out like a boil on the side.

random refs:
http://www.garlic.com/~lynn/subtopic.html#privacy

Another way of viewing the sitution ... is from the standpoint of the fundamental business process components.

The typical RP in a transaction ... isn't directly about what the consumer/end-user has to say ... it is concerned about what the financial institution has to say. If it is a merchant ... the merchant is insterested in having a real-time response from the financial institution about whether the merchant is going to be paid or not. There is a timeliness associated with that answer .... that is impossible to get in a certificate electronic/offline paradigm.

anders.rundgren@xxxxxxxx on 11/12/2002 8:21 am wrote:
Survey regarding the future of PKI trust networks
------------------------------------------------------

Traditionally certificates have been purchased (or just issued) for an entity by a party that is concerned that the entity can be properly identified in authentication- and signature-operations.

For a relying party (RP) to check certificate-status has mostly been a public and free service.

The financial industry however, have in several recent PKI-ventures shown that they intend to change this by treating lookup-services as equivalent to payment transactions, where the RP's bank is used as a "trust clearing center" communicating with the subscriber's bank that must be a member of the same "trust network". To make it technically impossible for RPs to fully verify signatures without going through the trust network (and paying for the services), root-certificates are usually not "published".

I would be very happy to hear what the PKI community in general think about this scheme as the future for PKI. Off-list responses will be treated as CONFIDENTIAL information.

Anders Rundgren


In Brief: Anti-'Skimming' Guidelines Coming

From: Lynn Wheeler
Date: 11/20/2002 08:29 AM
To: internet-payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: In Brief: Anti-'Skimming' Guidelines Coming


In Brief: Anti-'Skimming' Guidelines Coming

American Banker       Wednesday, November 20, 2002

David Breitkopf

HOUSTON - The chairman of a committee formed to combat "skimming" - the theft of personal information from credit and debit cards - said it will present best-practices recommendations to the Electronic Funds Transfer Association board by yearend or in January.

Mike Hudson said last week that many of the recommendations of the ATM Integrity Task Force will be ways to "secure the PIN and ? make sure the PIN stays secured," including modifying PIN pads. The panel will also recommend standards for independent sales organizations and ways for their sponsor banks to ensure that those standards are met, he said.

Mr. Hudson is the executive vice president and chief operating officer at Tidel Engineering LP of Houston, which makes automated teller machines.

The task force members represent financial institutions, EFT networks, ISOs, and ATM manufacturers, all looking for a solution to the growing problem of skimming at ATMs. Most of their first set of recommendations will deal with the machines' internal workings.

At its next meeting, in April, the panel will look at external prevention tactics. On the agenda will be how to combat skimming devices that are placed over card readers and thin, transparent membranes placed over PIN pads to capture cardholders' PINs.


I-D ACTION:draft-ietf-pkix-sim-00.txt

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/25/2002 06:51 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: I-D ACTION:draft-ietf-pkix-sim-00.txt
and of course the (FSTC) FAST model has some authoritative agency/authority (for the information) .... authenticating the information in a transaction that (can) looks very much like an existing online payment authorization transaction (aka the end-user makes some signed assertion to a RP ... and the RP gets the real-time agreement back directly from the authoritative agency). This somewhat makes the distinction between a certification authority (as TTP) and an authoritative agency; where there can be contractual and liability relationship between the RP and the agency certifying (& responsible for) the information.

There are (at least) three issues

1) certificates originally targeted as solution for offline certified information in an offline environment ... attempting to find a reason in an online world

2) x.509 identity certificates creating a value proposition .... for a time somewhat attempting to aggregate more & more privacy information ... exasperating the identity theft and privacy leakage problems. one reaction was institutions going to relying-party-only certificates that contained just an account number .... which were attached to signed messages & transactions that contained the same exact account number and transmitted to business process that contained the account record and already contained a copy of the public key for authenticating the transaction (trivially showing that certificate itself was redundant and superfluous). The existence of such certificates were technical artificial contrivance having nothing to do with any business process.

3) the traditional online business model has had bilateral agreements/contracts a) between the authoritative agency (like a financial institution) and the end-user, b) the end-user and the relying party and c) the relying party and the authoritative agency. Many of the certification authority constructs were introduced as TTPs that would certify information nominal the responsibility of some authoritative agency .... supposedly because the relying-party might not have an online conduit to the authoritative agency. However, the CA typically had no direct contract/business relationship with either the authoritative agency or the relying party .... any contract (implied or real) was between the end-user and the certification authority (which could be totally unrelated to any of the three bilateral agreements already mentioned). I think that the GSA has addressed this by making the CAs agents of the GSA and the RPs having contractual relationship with the GSA (with regard to the GSA agents).

the certificate challenge then is 1) role in online world, 2) contain useful information w/o leaking useful information, 3) some correspondence to normal accepted business relationships (especially in a TTP scenario where the TTP is independent of the actual authoritative agencies for the information and all existing business relationships).

Some of the adult oriented internet has been using $1 auth for sort-of a real-time age checking transactions. You do a something that looks like MOTO payment transaction with a RP ... the RP does a $1 auth through the normal network but doesn't do settlement (so nothing ever shows on your statement). The result of the $1 auth is saved and used as implying that you are of legal age (aka there is legal relationship between you and the financial institution acting as an authoritative agenchy, there is legal relationship between the RP and the financial infrastructure ... and you are directly interacting with the RP). While there are some issues with regard does the existance of legal relationship between you and your financial institution actually implying legal age ... as well as the lack of a digital signature (or other form of strong authentication) actualy mean that you are you (say a x9.59 digitally signed transaction) ... the control flow and the business relationships follow normal accepted practices.

draft-ietf-pkix-warranty-extn-01.txt

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/28/2002 08:11 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: asturgeon@xxxxxxxx, ietf-pkix@xxxxxxxx
Subject: Re: draft-ietf-pkix-warranty-extn-01.txt
note also that warrenties/insurance tend to be between parties in a business relationship. that has been one of the problems with certificates. A certification authority can have a relationship with the end-user that purchases the certificate.

A certification authority can warrenty/insure something with respect to the person that purchases the certificate. Such warrenty/insurance might be if a relying-party happens to sue the person that purchases the certificate ... then that person has coverage from the certification authority. If something bad happens to a relying-party because of some certificate related thing ... then for the relying-party to be able to collect ... there typically has to be a business relationship between the relying party and the institution providing the warrenty/insurance. possibly the relying-party can sue the end-user ... and then have the certification authority insurance/warrenty cover the cost of that litigation. This is possibly somewhat like home insurance that has a rider covering workers hired by the home owner that are injured while at the home.

i presume this is the case somewhat of the previously mentioned reference to GSA certificates .... certification authorities are providing certificates as a business agent of the GSA ... and relying parties have contracts with GSA. Presumably such contracts could include payment by the relying parties to the GSA for the cost of any insurance/warrenties. It is frequently difficult for a business entity to provide a service like insurance or warrenties ... when there hasn't been any fees and/or other funding which would cover the cost of providing such a service. Possibly the only kinds of insurance and warrenties that don't require any funding are the kind that nobody figures on ever having to make good on (totally w/o substance or concrete validity).

not having any warrenties or insurance (or liability) somewhat implies that there is no incremental upfront cost of doing business if something goes wrong.

warrenties or insurance typically are related to some liability that might be incured if something goes wrong.

warrenties and insurance are an incremental cost of doing business and must be covered by some sort of revenue associated with doing that business. furthermore the entities underwriting the insurance will want to understand the parameters of the insurance risk ... in order to set the premiums. this is something that the insurance industry is revising in the wake of 9/11 ... there were possibly significant amount of unanticipated risk for which the premiums are insufficient to cover the risk exposure. this is analogous to security proportional to risk (in this case, insurance can be considered a form of security):
http://www.garlic.com/~lynn/2001h.html#61

warrenties and insurance associated with some liability of doing business is typically with respect to entities that have some business relationship. For a typical TTP environment with respect to a relying party ... it is frequently not possible to show a business relationship between the TTP and the relying party (i think that in part is the purpose of the various GSA legal instruments).

anders.rundgren <anders.rundgren@xxxxxxxx on 11/28/2002 2:19 pm wrote:
Alice,

I do sympathize with the idea, but I maintain that it is not fully recommendable to mix warranties and liabilities as they are at least are perceived as different.

CA liability do address a serious commercial aspect. Very few CAs are likely to go beyond liability due to the following reasons:

A problem with a "warranty" worth its name, is that it must cope with transaction-accumulation, which is technically impossible to support. An identity thief performing massive parallel attacks of some kind, like sending fake purchase orders to different parties, will erode any valid reason for having a warranty in the form we usually define it.

A car can only break down once at a time, while PKI break-downs can be like forest-fire.

Another problem with "warranties" is that not everything have an a priori known value. Like authentication.

Also I don't think this is how PKI is actually used (or even should be used for that matter), you'd rather accept a CA or not.

If you split the ID in two pieces I'm sure that at least the liability-ID could be a real success. If lawyers accept the liability extensions (it is really reductions...) in case of a lawsuit that is. Otherwise the whole thing gets redundant.

cheers, Anders

PS It must be a challenge to be "Alice" in the world of PKI where "Bob and Alice" are the two main players :-) DS

asturgeon@xxxxxxxx on 11/28/2002 20:36 wrote:

Anders,

I respectfully disagree. You're right that a CA is not like GM or Ford, but why can a CA not offer a warranty? Perhaps what is missing here is a definition of warranty, which, in insurance terms, is attestation of the intent to provide compensation for harm incurred by using a certificate (that is, a certificate that is faulty in some way). Warranty is not the same as liability; warranty is something that the CA can control, whereas it cannot completely control liability. The CA (or indeed any product- or service-offering company) may try to limit its liability, but regardless of this attempt, the extent of liability will ultimately be decided by the courts.

You seem to be defining warranty rather narrowly, as replacement or refund in the event of an inherent flaw.

Similarly, it seems to me that I define risk management more broadly than you suggest. Every time an RP enters into a transaction, or considers doing so, the RP makes a risk management decision. This can be quite a natural and intuitive process, or it can be explicitly defined; either way, the decision is made, and it will be based on more or less information. The more information an RP has, the more informed the risk management decision will be. If a certificate contains information pertaining to the existence of compensation in the event of harm, then the RP has more information on which to make a risk decision. Armed with this information, as well as information about other factors of the transaction, such as value, sensitivity of information, parties to the transaction (e.g., known or unknown), etc., the RP's risk is reduced by virtue of knowing more about all of the risk factors - including warranty. If there is a TTP involved, this again becomes a factor in the RP's risk management decision.

My 2 Canadian cents again.

Alice

Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone: 613-232-2350
Cell: 613-291-0331

anders.rundgren on 11/28/2002 12:29 pm wrote:

Hi,

After reading this draft I believe the name "warranty" is a bit misleading. It is, (or should IMHO at least be), focused on CA liability issues as a CA cannot be compared to a car maker, as the only the latter will repair or replace their products in case of faults. Well, to get a "replacement" certificate would be the equivalence but that is sort of taken for granted anyway. :-)

CA-liability-extn

seems to be closer to what we are actually dealing with.

I would also be very cautious about RP "risk management" because that's rather fictional. The risk you take by accepting an unknown[] business partner is likely to be magnitudes bigger than accepting their certificates. If the CA is unknown as well you have nothing to build PKI trust on either.

For TTP CAs OTOH, "risk management" with respect to client-certificates is a part of their daily bread.

Just my 2 öres

Anders

] with respect to performance, trustworthiness, credibility etc.


draft-ietf-pkix-warranty-extn-01.txt

From: Lynn Wheeler
Date: 11/28/2002 08:41 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: asturgeon@xxxxxxxx, ietf-pkix@xxxxxxxx
Subject: Re: draft-ietf-pkix-warranty-extn-01.txt
random semi-related points are the "extended" warrenties that you can purchase for just about any product these days. they effectively operate as form of insurance .... at least from the standpoint that the consumer is paying a premium and the entities selling the "extended" warrenties are calculating their risk exposure very much like insurance companies calculate their premiums and risks.

there has also been some amount of discussions about the consumer disk industry cutting in half the warrenty period for disks ... presumably primarily as a means of reducing the cost of doing business. this potentially could go to the companies bottom line ... and/or result in a lower cost product.

whether it is insurance in the form of insurance or insurance in the form of warrenties ... it represents a business cost and somebody has to pay. furthermore the associated premiums/pricing calculations are based on the expected resulting costs that will be incured by the warrenties and/or insurance.

Identity Theft More Often an Inside Job

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/03/2002 06:24 AM
To: internet-payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Identity Theft More Often an Inside Job

http://www.washingtonpost.com/wp-dyn/articles/A1026-2002Dec2.html
Identity Theft More Often an Inside Job
Old Precautions Less Likely to Avert Costly Crime, Experts Say
Washington Post Staff Writers
Tuesday, December 3, 2002; Page A01

You can take all the steps you want to protect yourself against identity theft: Guard your wallet, shred your personal financial papers before throwing them in the trash, monitor your credit reports.

But no matter how careful you are, you may not be able to avoid having your identity assumed by someone who wants to go on a buying spree, using your credit card, bank account, Social Security number or other personal data.

That's because the nature of identity theft has changed and the threat today is more likely than ever to come from insiders -- employees with access to large financial databases who can loot personal accounts -- than from a thief stealing a wallet or pilfering your mail. Banks, companies that take credit cards and credit-rating bureaus themselves don't do enough to protect consumer


draft-ietf-pkix-warranty-extn-01.txt

From: Lynn Wheeler
Date: 12/06/2002 06:47 AM
To: Andreas Mitrakas <andreas.mitrakas@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>, asturgeon@xxxxxxxx,
Denis Pinkas <Denis.Pinkas@xxxxxxxx>,
    Russ Housley <housley@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: Re: draft-ietf-pkix-warranty-extn-01.txt
basically companies are offering two kinds of warrenties ...

1) insurance ... if the product is defective you get replacement or compensation. this is frequently marketing issue .... possibly when dealing with marketing environment where competition may have more reliable product ... or otherwise differentiated themselves.

2) limited liability statement ... legal &/or gov. have established that there is some range/scope of liability ... and offers the provider opportunity to state the limits of their liability. some of these statements may include phrases about gov. regulations may offer additional or other recourse.

#1 is almost always with regard to the direct purchaser of the the product or service ... and may even involve additional, optional fees. This leaves out the RP ... unless there is some sort of insurance of the nature of home owner's insurance that allows the RP to recover from the insurance policy of the certificate owner.

#2 is frequently interpreted within the context of parties of a contract. as mentioned before, this aspect of contract law creates a difficult situation for TTP CAs with respect to RPs ... since RPs aren't party to the contract between the CA and the end-user purchasing a certificate. The traditional legal recourse for the RP then is to sue the owner of the certificate ... not the CA ... since there is some business operation between the RP and the owner of the certificate ... but not between the RP and the CA (at least in the traditional TTP CA model). The other approach is the deep pockets .... if you are injured in a traffic accident ... sue the company that manufactured the vehicle ... on the grounds the vehicle was defective in some way. Some sort of standard is established as to what might be considered defective and not defective ... and the manufactur of the vehicle is typically not allowed to make statements regarding the limitation of their liability.

Now, it is pretty obvious that in #1 ... the RP is recovering from the certificate owner's insurance policy (which the certificate owner paid for). The problem in #2 is either that it is a) specified gov. standards or b) this seems to be some sort of new type of legislated legal relationship ... that doesn't seem to exist in most existing contractual relationships .... an implied contractual relationship between the RP and a TTP CA by way of both of them having some relationship with the certificate owner.

If it is "2a" ... then it isn't really a limited liability statement .... it is a statement as to the type/class/kind of gov. standard certificate (somewhat contrived to call it a warrenty).

The other downside (mentioned somewhat in this thread) comes in the area of value and financial. It is pretty obvious that a certificate can state that it is only for transactions that are less than some specific value. The issue is that many kinds of electronic value transactions can be repeated (aka aggregation). Can a ten dollar certificate be used for a million transactions? What if it is used for a million ten dollar transactions with the same RP?

andreas.mitrakas@xxxxxxxx on 12/6/2002 4:16 am wrote:
Anders,

from an RP perspective this matter touches upon the statutory liability level as for example it is addresse in art 6 of the EU Directive. The liability of the CA for publishing a certificate featuring erroneous data, for example, would be detrmined in court. The CA however, has the right to set a limit to the value of the transactions a specific cert can be used for. This does not mean that RPs cannot perform transactions in excess to such cap, but only that they act at their own risk.

A warranty --as I believe Alice said yesterday -- is a positive offer by the CA to cover transactions up to a certain limit. Such warranty, if accepted by RPs would limit any future claims, with the exception of any statutory liability the CA may incur. If there is a warranty and something goes wrong the RP can have a direct claim from the CA. A warranty makes sense since the potential risk for a CA is enormous, if you consider the amount and value of the transactions, a certificate can be used for. In support of a warranty the CA might seek an insurance policy, but this probably gets beyond the point.

On a certificate an RP possibly needs an indication of a cap -- this could be just a numeric field. Warranty terms can be part of the policy.

I hope this helps,

andreas


Fraudit helps registrars battle global online fraud

From: Lynn Wheeler
Date: 12/06/2002 07:55 AM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Fraudit helps registrars battle global online fraud
http://www.computerworld.com/securitytopics/security/cybercrime/story/0,10801,76440,00.html
At first, he said it couldn't be done. But ultimately, Rick Wesson, CEO of Alice's Registry Inc., developed a product to improve the accuracy of Whois data on the front end.

"About a year ago, a number of people expressed their interest in a system to detect when someone provided inaccurate information on their domain name registration form, and I said it couldn't be done," Wesson said.

But he decided to take on the challenge -- and to his surprise, succeeded in developing such a system, he said.

The new product, named Fraudit (think "fraud audit," Wesson said), is the first to tackle the problem of ensuring that the information that people provide to registrars of domain names is correct, said Alec French, an aide to Rep. Howard Berman, (D-Calif.), the ranking member of the House Judiciary Committee's Subcommittee on Courts and Intellectual Property.

Fraudit checks databases worldwide to verify an entity's e-mail address, postal address and telephone number, detecting errors and scoring the validity of the registration information, said Wesson, who is also the chief technology officer of the Registrar's Constituency group of the Internet Corporation for Assigned Names and Numbers. He said registered users can access the Fraudit service through an easy-to-use Web-based form or a secure Web service client for 25 cents per transaction, with a $49.95 minimum per month.

Wesson, who noted that Santa Cruz, Calif.-based Alice's Registry is already using Fraudit, said he has been talking with other registrars about using the new technology, which was announced in October. He declined to say more about how those discussions are going.


Online Fraud Growing in Scale, Sophistication

From: Lynn Wheeler
Date: 12/06/2002 08:00 AM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Online Fraud Growing in Scale, Sophistication
http://itmanagement.earthweb.com/ecom/article.php/1552921
Online Fraud Growing in Scale, Sophistication
December 5, 2002
By Sharon Gaudin

Fraud will cost online retailers about $500 million during this holiday season, according to a new study out by industry analyst giant Gartner, Inc.

Suspect transactions and credit card fraud will nail the e-commerce industry, according to Gartner's recent survey of 50 leading e- commerce outlets. The analyst firm also predicts that U.S. online sales will ring up to $15.66 billion in the fourth quarter of 2002.

The report also notes that missed sales opportunities cost online merchants two times more than losses from completed but fraudulent transactions. Credit card fraud causes e-tailers to lose about 1% of their transaction volume and sales revenue, while e-tailers reject 6% of consumer purchase requests because they appear suspicious. Gartner analysts note that 6% of sales equals $950 million in revenue for the fourth quarter alone.

The e-commerce leaders surveyed admitted that they mistakenly reject about 2% of total sales, costing them $315 million in sales.

Fraud alone will cost online merchants $160 million in the fourth quarter.

Fraud is growing not only in scale but in sophistication.


... snip ...

draft-ietf-pkix-warranty-extn-01.txt

From: Lynn Wheeler
Date: 12/06/2002 10:41 AM
To: <asturgeon@xxxxxxxx>
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
    "Andreas Mitrakas" <andreas.mitrakas@xxxxxxxx>,
"Denis Pinkas" <Denis.Pinkas@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: RE: draft-ietf-pkix-warranty-extn-01.txt
the other problem in a commercial environment is with regard to insurance/warrenty/liability represents an incremental cost of doing business. In the contractual model, the customer (i.e. certificate owner) pays for business costs (aka otherwise if a business is charging a customer less than the cost of doing business .... they are loosing money).

frequently the insurance kind of warrenties may actually have the costs to the customer (certificate owner) broken out separately. not only is the RP left out in this model ... because of contractual conventions .... but also the RP isn't involved in the paying for the cost of doing business to the certification authority. It is even harder to imagine what kind of incentive that an RP could give a customer (certificate owner) to have (voluntarely) purchased the addtional insurance (other than the scenario of home owner's insurance that there is a threat of the RP suing the customer because of some issue with the certificate).

it is more common in the liability kind of warrenties ... especially when gov/legally mandated that it is found such costs of doing business is bundled into the basic product price (i.e. in this situation since it is gov/legally mandated there is much more of a level playing field for all companies offering the service/product).

there is some hypothesis that there might be different gov/lergally mandated standards for certificates with different value limits. The challenge in the traditional TTP CA model is that while the direct cost is carried by the purchaser of the product (the consumer/certificate owner), the whole thing is supposedly is primarily for the benefit for the RP ... who is not part of the contractual relationship (and who isn't purchasing the certificate, and therefor isn't directly contributing to the CA cost of doing business).

Another issue is if a RP ever tried to collect under any such possible CA warrenty can the CA legally disclaim all responsibility on the basis that there is no contractual relationship between the CA and the RP. That seems to be where the gov. regulations come in .... that they can legislate any sort of obligation they want to ... even if one wouldn't otherwise exist in standard contract environment.

asturgeon@xxxxxxxx on 12/6/2002 10:15 am wrote:
Lynn, and others,
Looking at your last point first, if I were an insurer, I'd opt for the aggregate model, being basically risk averse, to avoid getting slammed by those one million ten-dollar transactions. But this may be a matter of knowing your community. If that is the case, i.e., that the CA knows its user community in terms of usage profile, then it might be comfortable in offering per-transaction. Thus both should be available. On your two types of "warranties", I think you're using the wrong term for your second type. As I tried to categorize them earlier, liability really has nothing to do with warranty. In a dictionary sense, you might find a definition that brings the two together, perhaps as analogous, but certainly in the legal and insurance communities, they are very different indeed. Your third paragraph offers a reason for having a warranty in a certificate. If it is in the certificate, then the RP is not left out.

Alice

Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone: 613-232-2350
Cell: 613-291-0331


draft-ietf-pkix-warranty-extn-01.txt

From: Lynn Wheeler
Date: 12/06/2002 10:44 AM
To: <asturgeon@xxxxxxxx>
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
    "Andreas Mitrakas" <andreas.mitrakas@xxxxxxxx>,
"Denis Pinkas" <Denis.Pinkas@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: RE: draft-ietf-pkix-warranty-extn-01.txt
... somewhat total aside ... the issue of consideration establishing basis for valid contract (& therefor warrenty, liability, etc) was one of the issues extensively discussed during the formation of the x9.59 payment protocol standard.

Frist Data Unit Says It's Untangling Authentication

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 12/09/2002 08:31 AM
To: iang@xxxxxxxx
cc: Digital Bearer Settlement List <dbs@xxxxxxxx>, iang@xxxxxxxx
Subject: Re: Frist Data Unit Says It's Untangling Authentication
my wife and i started to come up with the idea when we were assigned to work with this small client/server startup company that wanted to do payment transactions. during the year that we worked with them ... they changed their name from mosaic to netscape and moved from menlo park to mountain view. it is now frequently referred to as electronic commerce.

http://www.garlic.com/~lynn/aadsm5.htm#asrn1Assurance, e-commerce, and some x9.59 ... fyi
http://www.garlic.com/~lynn/aadsm5.htm#asrn2Assurance, e-commerce, and some x9.59 ... fyi
http://www.garlic.com/~lynn/aadsm5.htm#asrn3Assurance, e-commerce, and some x9.59 ... fyi
http://www.garlic.com/~lynn/aadsm5.htm#asrn4assurance, X9.59, etc

iang@xxxxxxxx wrote on 12/9/2002 7:21 am wrote:

> First Data Unit Says It's Untangling Authentication
> First aSuretee's version does away with the certificate authority, the
> company says. A token simultaneously generates the private and public keys
> that identify the user, but the transaction goes directly to a bank or
> company.

Well, yee-haa! Finally, someone is seeing how to do it. Folks, that's what Ricardo has been doing for years. Since '95, to be precise. We weren't the only ones, but we are the only ones still in existance, to my knowledge.

It's so damn basic, I just cannot explain why it has taken someone else so long to catch on. One of the great mysteries of the business.

--
iang


Frist Data Unit Says It's Untangling Authentication

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/09/2002 10:47 AM
To: iang@xxxxxxxx
cc: Digital Bearer Settlement List <dbs@xxxxxxxx>, iang@xxxxxxxx
Subject: Re: Frist Data Unit Says It's Untangling Authentication
x9.59 is an ansi/financial standard. x.509 is an iso certificate standard (somewhat in concert with x.500). they are totally unrelated ... other than both use naming convenition that starts with "X".

charter given x9a10 working group was to preserve the integrity of the financial infrastructure for ALL electronic retail payment transactions (not just internet, not just point-of-sale, not just face-to-face, not just unattended, not just credit, not just debit, not just ACH, not just stored-value, etc).

after the SSL implementation ... some comments:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

which preserved CC# "in-flight" .... there was a specification (from an industry association, ... but not a standard from a standards body) that basically also used very complex crypto for transactions "in-flight" (along with everybody having certificates) on the internet (aka while being transmitted). However, the biggest exploit/threat to the SSL implementation was not the "in-flight" data (which was already encrypted) ... but from the data at rest at the merchant site (web server, backroom server, etc). In effect the newer, much more complex specification did nothing (additional) to address the major risk exposures of the SSL-based implementation. The biggest exploits that hit the press have been the harvesting of the merchant's master credit card file and then using the CC numbers for fraudulent transactions. Specific discussion of this issue ... security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61

and lots of past stuff about various kinds of fraud, exploits, etc:
http://www.garlic.com/~lynn/subtopic.html#fraud

there was quite a bit of work on x9.59 to resolve all of these issues ... including the exposure of the data at risk in the merchant credit card master file:
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subtopic.html#privacy

in addition to the x9.59 standards work there was also work in the generic case of certificate-less digital signing ... including the specification and trial by NACHA in the debit network:
http://www.garlic.com/~lynn/x959.html#aads

as well as work applying it to various ietf internet standards like Kerberos and RADIUS
http://www.garlic.com/~lynn/subtopic.html#radius

also
http://www.garlic.com/~lynn/rfcietff.htm

and go to RFCs listed by and click on Term (term->RFC#) and in Acronym fastpath, click on "RADIUS".

the pk-init draft for kerberos specifies public key authentication allowing for both certificate (x.509) and certificate-less (aads/abds) modes of operation.

iang@xxxxxxxx on 12/9/2002 9:09 am wrote:
lynn.wheeler@xxxxxxxx wrote:

> my wife and i started to come up with the idea when we were assigned to
> work with this small
> client/server startup company that wanted to do payment transactions.
> during the year that we worked with them ... they changed their name from
> mosaic to netscape and moved from menlo park to mountain view. it is now
> frequently referred to as electronic commerce.

I've heard of them :-) So, whatever happened to their electronic commerce ideals?

> http://www.garlic.com/~lynn/aadsm5.htm#asrn1Assurance, e-commerce, and > some x9.59 ... fyi
> http://www.garlic.com/~lynn/aadsm5.htm#asrn2Assurance, e-commerce, and
> some x9.59 ... fyi
> http://www.garlic.com/~lynn/aadsm5.htm#asrn3Assurance, e-commerce, and
> some x9.59 ... fyi
> http://www.garlic.com/~lynn/aadsm5.htm#asrn4assurance, X9.59, etc

Ah, there's the answer. X.something. We tried x.509 in the 2nd generation of SOX, but when we found that the whole CA model was mandated within, we went back to OpenPGP. I guess some big player could have the patience and resources to write all the additional formats, but from my pov, x.509 was terminally afflicted with CA. Also, that whole model seemed to want to do credit card processing, which all seemed like a waste of time to me. Like, how much effort has been spent in trying to protect a credit card from a non-threat, the mythical mallory?

--
iang


First Data Unit Says It's Untangling Authentication

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/10/2002 09:31 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Re: First Data Unit Says It's Untangling Authentication
I'm sorry if it comes across as TTPs are useless. There are a lot of AADS examples of TTPs that are extremely useful. I've sometimes abbreiviated "offine TTP/CA" to just TTP.

I've looked at certificates and TTP/CAs from an distributed information model. My wife and I have done a lot of work in this area in the past (multiprocessor cpu cache designs, distributed file, caching & locking designs, distributed database, caching & locking designs). From an information analysis standpoint, the basic certificate is a piece of R/O cached, distributed information .... which uses some cryptography for assurance about the integrity of the cached entry (similar to the way that multiprocessor cpu cache designs used check & partity codes).

AADS model corresponds to traditional business bilaterial agreements (contract law) and/or online TTP models. The issue is where does an offline TTP/CA certificate model fit.

Typically contracts involve two parties where there has been exchange of consideration. One of the issues in the TTP/CA with respect to RPs is the lack of consideration between the two parties. This frquently will then fail the basis for a contract and therefor any concept that there is any obligation between the TTP/CA and the RP in any way. Of course, govs can legislate anything they want to be true.

Even in B2B .... there is either 1) an established business context that includes things like authentication, aggregation, and some other characteristics and/or 2) access to an online TTP. AADS fits when either "1" or "2" is true. Trying to force fit a TTP/CA certificate designed for an offline environment into such an environment is pure contrivence (redundant and superfluous). TTP/CA certificates are useful when neither "1" (aka established business relationship) and "2" (aka no recourse to an online, realtime TTP) are true. Furthermore, because of the frequent stale nature of TTP/CA certificates, if the B2B relationship involves anything of any value ... and even if both "1" and "2" are true, the parties may delay actual finalization of initial negotiations until after there has been timely, current validation established (even if it involves sending off telegram/email and waiting for the response).

The issue of a TTP/CA for offline certificates is trying to find a market niche where neither "1" nor "2" applies. This typically will be situations involving little or no value. The problem then for a TTP/CA in supporting environments with little or no value .... can they make an business plan based on selling certificates for situation involving little or no value. Again, govs can legislate something here and/or provide the service (aka when it doesn't make sense in traditional business relationships as well as being shown to have little or no value).

So there are lots of examples where it is possible to examine the information flow and characteristics in detail and show that if either "1" or "2" applies then certificates are redundant and superfluous So we look at it from a slightly different point. We examine the dominant use of TTP/CA certificates in the world today, which are SSL domain name certificates (the claim is that they account for 99.99999% of all certificate-related events that occur in the world today). As outlined in the original ref'ed postings .... and aggregated in
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

there is an online authoritative reference for domain names. The issue was that there are integrity issues with the online authoritative reference for domain names .... and SSL domain name certificates was a quck & dirty fix pending the much more difficult task of fixing a deployed and established legacy system. This fit the criteria that there was no recourse to an online TTP ... aka while it is online ... and it is third party ... there were concerns that it didn't fit the "trusted" part of "online trusted third party".

The irony is that the TTP/CAs when issuing an SSL domain name certificate ... actually have to check with the authoritive authority for domain names (which is the same "untrusted" domain name infrastructure) as to the validity of the owner of that domain name. It turns out integrity issues affect both the basic use of the online domain name infrastructure as well as the use of the domain name infrastructure by the TTP/CAs for validating the information that goes into SSL domain namme certificates. There is proposal, somewhat motiviated by the TTP/CA industry, to improve the integrity of the domain name infrastructure information. However, implementing such a proposal on behalf of the TTP/CA industry also goes a long ways towards negating the need for having SSL domain name certificates. Turning an online untrusted third party into an online trusted third party eliminates the need for certificates ... conforming to the assertion that certificates are useful only when both "1" (established business context) and "2" (recourse to online TTP) are not true. If either "1" (established business context) or "2" (recourse to online TTP) can be shown to be true .... then it can be shown that the certificate construct (R/O, cached stale data) is redundant and superfluous.

So TTP/CAs work when there is neither 1) established business context (typical contractual or bilaterial environment) nor 2) recourse to online TTP.

I've given an example of specific analysis of "2" with respect to "trusted". The business opportunity for "2" (assuming non-bilaterial and/or non-contractual) can be looked at in the individual pieces:

a) recourse to online b) trusted

The SSL domain name certificates currently exists because of the failure of "b" or "trusted".

"A" or "recourse to online" ... can be because the implementation just doesn't exist .... or the operation in question doesn't business justify an online operation. These days with the online world starting to penetrate every nuck & crany .... the idea that "online frequently doesn't exist" is typically associated with the business idea that it isn't cost justified. With the continued cost reductions related to online, this niche is becoming smaller and smaller. An assertion is that "recourse to online" can be frequently simplified as a not cost justified. The associated implication of not being cost justified also implies low value operations. Again the problem for a TTP/CA trying to sell certificates into a low value or no value market niche is that a viable business plan is difficult to create.

"Anders Rundgren" on 12/10/2002 04:56 AM wrote:
Lynn,
You must join the new OASIS PKI TC that is trying to address why PKI have failed. Note: I don't share your view that TTPs are useless, as entire societies are built on "TTPs". I.e. governments. Hopefully CAs can do better than governments as the former's tasks are better defined and very limited.

Note also that FirstData's system as well as AADS have a rather limited scope with respect to transactions. For B2B-messaging in general, AADS falls short as AADS in only suitable in a bilateral relation.

That does not mean that FD or AADS is wrong, it is just the universality, I claim is a bit exaggerated.

Anders


TTPs & AADS Was: First Data Unit Says It's Untangling Authentication

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/10/2002 04:12 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: epay@xxxxxxxx, internet-payments <internet-payments@xxxxxxxx>
Subject: Re: TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
Let's do the information analysis again.

The public keys that happened to be resident in browsers ... and other distributed applications .... happen to be public keys in account records .... that they are physically encoded in certificate format happens to be a physical encoding artifact not a business issue. In fact, almost all standard discriptions say that these public keys are handled in an "out-of-band" process that isn't part of the normal (offline) TTP/CA certificate business process (i.e. as part of a three part transaction/message, aka the actual message, the signature on the actual message, and the signer's certificate obtained from an offline TTP/CA).

The business process of the public keys contained in these account records .... typically included as part of some out-of-band business process .... just happens to be in certificate encoded format. If I were to register public keys and as part of that registration, encode them in certificate format as stored in the account records (in the AADS model) ... they could all be considered to be certificates also. However, just because they are in certificate encoded format ... doesn't make them part of a offline TTP/CA infastructure.

My actual statements ... in further detail, is that in the online AADS model ... the traditional offline TTP/CA business process involving the three-part message/document/transaction has the certificate part as redundant and superfluous .... aka part I is the actual message/document/transactio9n, part II is the digital signature, and part III is the (offline) TTP/CA certificate issued to the entity signing part I.

The discussion about offline TTP/CA having a vanishing market niche ... for selling offline certificates ... is in no way invalidated by the existance of account-oriented public keys that happened to be encoded in certificate format in your model.

For the most part these "static" certificates have been acquired by some out-of-band business process (not included in the traditional offline TTP/CA business operation) and also tend to be self-signed. Again, just because data has been encoded in certificate format doesn't automagically create any logical conclusion that offline TTP/CA business operation has a large market opportunity in an online world (aka severely confusing the encoding method with the actual business process).

When my wife were doing this stuff that came to be called electronic commerce with this thing called SSL .... we realized that we were inserting public keys in both browsers (the traditional SSL based stuff that most people are aware off). However, there was also this thing called a payment gateway ... and we were doing mutual authentication (this was before SSL had a definition for mutual authentication). This part could be considered one of the first B2B infrastructures (although must people aren't really familiar with it since it was much more of a fixed backroom process).

The encoding of the public keys used certificate format ... but there was no use of any offline TTP/CA business processes. The business software supporting the payment gateway had the payment gateways public key inserted into the software by an out-of-band process .... and other than the COTS software required certificate format for the public key encoding .... there was no aspect of the process that resembled any offline TTP/CA business process. Correspondingly each merchant site that was allowed to use the gateway was predefined and had account record created. Again the use of certificate encoding for the public key was purely a side-effect of the COTS software library being used and the actual business process bore no resumblance to any offline TTP/CA business operation.

The offline TTP/CA business processes have other similarities with AADS models (other than possibly using certificate encoding for public key storage). Basically the offline TTP/CA business process includes something called a registration authority. This basically does some up front validation of public key stuff before storing the public key in a TTP/CA internal business process database (aka account record). Effectively both offline TTP/CA business processes and AADS implementations can use very similar business process for the validating and recording of public keys in account records (weither or not they are certificate-format encoded when they reside in the account record). Such account records can be in traditional database management infrastructures or just simple tables that are typical of the form used for public key storage by internal browser processes or say by some of the PGP applications. Whether or not they use certificate-format encoding for the stored public keys and whether or or not the account record is a real database entry or just a much more simpler linear table doesn't affect the logical business process (and still doesn't automagically turn it into a offline TTP/CA business process).

The place where AADS starts to differ significantly from the offline TTP/CA model is with the elimination of the appended certificate as the 3rd part of a signed message/document/transaction.

Now, a traditional account record .... doesn't usually stop with the identification of the TTP ... and some could actually use certificate-format encoding of the stored information ... but they typically have to have much more context than just simple a TTP identification. There is a lot more business context involved ... that has to be wrapped around this. At a minimum, it isn't sufficient that you know the identification of the entity .... there has to be some business process that established this is a TTP entity ... and not just some random entity. If all I had was the name of the entity .... and nothing about it be an acceptable TTP entity .... the infrastructure could be susceptable to fraudulent impersonation (aka just because i have a certificate that has my identification and my public key doesn't make me an acceptable TTP). So there has to be some additional context ... either the whole table of publickey/identification entries has to be known to only be acceptable TTPs ... or each entry has to have additional information distinquishing between entries for acceptable TTPs and entries for other entities.

misc. refs about this stuff we did with this small client/server startup that was doing this stuff called SSL, HTTPS, and electronic commerce .... the year that we worked with them they moved from menlo park to mountain view and changed their name from mosaic to netscape.
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn1
http://www.garlic.com/~lynn/aadsm5.htm#asrn4

to re-iterate .... the method of encoding the data doesn't establish the business process of the use of that data. just because some data happens to reside in an account record in certificate-format encoded format doesn't automagically turn things into offline TTP/CA business operation.

anders.rundgren@xxxxxxxx on 12/10/2002 1:33 pm wrote:
Lynn,
In ad-hoc peer-to-peer B2B-networks relying on a set of TTPs, a static certificate have at least one important function: - identifying the TTP

So you can delete the certificate, keep the public key but you must add something else to let the RP find the on-line TTP. An URL maybe?

Anders


TTPs & AADS Was: First Data Unit Says It's Untangling Authentication

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/11/2002 09:00 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Re: TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
simple ... we can take the trivial purchase order ... using trivial purchase card example.

I send in order ... with an x9.59 signed transaction that effectively asserts that my bank will transfer x amount of money for the order. the business forwards the x9.59 signed assertion and gets back a statement from the financial institution either supporting the payment claim or not. people are bascially in business to make money. this is the simplest.

So we go to less trivial ...

case where there needs to be somewhat more complex relationship between the two parties ... possible because there is more complex relationship between orders and payments. We contact and express desire to make a relationship. If I'm the contacteee ... i (digitally) sign some assertions. The receiving party contacts my bank, D&B, and posibly some other credit reference operations. This is the existing business process model ... w/o certificates. However ... extending it to digital signature world ... use the FSTC FAST model as to the signed assertions can be things other than about payments. The financial institutions, D&B, and various credit reference operations that are the "authoritative reference" for the particular information respond either affirmative or negative. This is the X9.59 model for all payments, the FSTC FAST model, the business model as how things operate today.

We can even find this business model operating within the existing TTP/CA industry today. In this case the two business entities are the parties applying for the certificate and the certification authority. The business process is by the TTP/CA as in the above description, they contact financial institutions, D&B, and possibly other references .... get back the answer and load it into their TTP/CA account-based database.

At this point the TTP/CA creates an offline certificate that effectively represents a stale read/only copy of the data and business transaction process that it has just performed (aka a substitute for what is in their account-based repository). From the business process standpoint, the certificate reprsents a stale, static representation/standin of the standard business process performed by the TTP/CA. This stale, static, representation/standin credential ... representing the standard everyday business performed by the TTP/CA ... can sortof be used business operations and entities that are unable to perform the standard business process operations themselves (aka the certificate ... effectively is analogous to some of the paper certificates that appear on the wall of business claiming that they have passed various checks and verifications and have paid a fee to some organization).

The issue of course ... is the stale, static standin certificate (representing the process performed by the TTP/CA) a sufficient substitute for a business operation performing their own real-time business verification. The more complex detail behind this issue ... and has shown up in the X.509 identity, individual certificate work .... can a generalized certificate be issue to an entity that is adequate for all possible places that need to do various checks. I can claim that I sort of know the kind of information that needs to be verified for me .... but I may have no idea what actual verification might be done by a large number of different corporations that i wish to deal with ... and whether they specific verification requirements actually correspond to the verification done for the kind of certificate that i had just purchased.

So, it is difficult to come up with a definition of any set of generalized business operations that such a certificate would represent.

So we start applying KISS.

Lets say that the only thing in such a certificate is a public key. I can create a self-signed document that includes a public key.

This is basically the process that I mentioned previous is done by TTP/CAs and is a "registration authority" business process than is effectively shared/identical with AADS operations and TTP/CAs.

I can create this self-signed document ... which goes directly to the business entity that i'm wishing to establish a relationship. Along with that, I also sign X9.59/FAST type assertion transactions that basically state that some TTPs are authorized to confirm/validate certain information to the business entity that i'm establishing a relationship with. The business sends off the signed X9.59/FAST type assertions to the various TTPs (financial institutions, D&B, credit checks, etc) and gets back various confirmation information (this is the digital eequivalent of the existing business processes w/o needing a TTP/CA intermediary).

The business entity can check that the signature on the self-signed document validates with the public key contained in the document. They can also validate that the signed assertions sent off in real-time to the various TTPs also validate with the same public key. They then register the public key and the confirmation by the various TTPs that they've contacted in an account record. Future communication doesn't need the registration authority process. In effect, the business entity is performing all of their specifically required processes ... that a TTP/CA is trying to emulate in a more general way. The business entity then creates an account record that is a representation of all of those business activities .... and is sort of the thing that the TTP/CA is trying to replace with their certificate representation.

As i stated in the previous posts .... the registration process ... and various kinds of verification operations ... are identical in most businesses today and is something what TTP/CAs have trying to emulate and create a certificate substitute for. A major difference is that the TTP/CA is trying to create a generalized acceptable version of that ... that would repsent some value substitute to other parties.

In many cases the TTP/CA are duplicating in their backroom, exactly the same process that goes on in every business backroom.

So we now get to some of the contractual relationships. In the case where a business entity is directly contacting their TTPs (using "out-of-band" from a TTP/CA standpoint .... or "standard business as usual" from a business proces standpoint) ... it is possible to establish consideration and the basis for contractual relationship and things like liablity between the two parties (a business entity and the TTP). One of the challenges for the TTP/CA paradigm (in addition to getting acceptance that generalized stale certificate verification of information by the TTP/CA is acceptable to a business compared to them performing the same operations themselves) is that there is no basis for contract between the TTP/CA and the business entities (aka relying party in TTP/CA terminology). I buy the certificate from a TTP/CA and provide consideration. That means that there is basis between me and the TTP/CA for contract and possible liablity. However, in much of the world just because I have a contractual relationship with a TTP/CA ... and then I go on to establish a contractual relationship with a (RP) business entity .... it is somewhat harder to show that because I have a relationship with a TTP/CA and a relationship with a RP ... that there is the basis for a contractual relationship between a RP and a TTP/CA.

Now we come to the value proposition. A TTP/CA that is dupliating the standard backroom business process that goes on everyday in every business is trying to sell a certificate that is a codified representation of the fact that they've beformed these standared, everyday business processes. Unfortunately in the TTP/CA model ... they aren't selling these certificates to the RP, they are selling these things to public key owner. In additional to the TTP/CA trying to establish a new business paradigm that violates standard acceptable contractual relationships (as per previous paragraph) they are also trying to revise the payment model of the RP paying the TTP for the verification.

As stated in the previous posts, governments have been able to establish that the certification is payed for by the person certificated ... rather than by the RP. This is typically done by setting up a government agency responsible for the certification and legislating that the person being certified pay for the license/certification.

Simple B2B KISS/Summary

TTP/CAs are duplicating backroom verification operations that go on in standard business operations today

TTP/CAs are trying to get people to pay for their own certificates .... with are the representation of these backroom verification operations

TTP/CAs having people pay for their own certificates ... violates existing business models (both from contractual standpoint and value transfer standpoint)

TTP/CAs the succesful model of people paying for their own certificates .... is where govs. sent up regulations and licensing authorities and mandate it

TTP/CAs there is assumption that the backroom operation performed by a TTP/CA and represented by the certificate can substitute for some existing business process/expense

TTP/CAs there is assumption that the backroom operation performed by a TTP/CA and represented by the certificate involves operations that won't have to be repeated by the RP

previous refs
http://www.garlic.com/~lynn/aadsm12.htm#50 Frist Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#51 Frist Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#53 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication

the succesful example of a new TTP/CA like operation is the age verification businesses that cater to the internet adult oriented industry (gaming and entertainment). They perform a backroom peration that is almost exactly the same as standard TTP/CAs have done for some kinds of personal certificates. Basically, you register with the TTP by supplying your name, address, and credit card number. The TTP does a one dollar auth(orization) & AVS credit card transaction that is never settled (aka never shows up on your credit card bill). The name and address is checked against the name and address on file for the credit card number and if it matches a positive response is made to the TTP. The TTP creates a account record for you. When you go to an adult oriented site, you can be asked to verify your age ... and select one of the TTP services that you've registered with. The web site then does a real-time check with the TTP. The websites get charged by the transactions by the TTP. These "stand-in" TTPs are relying on the $1 credit card authorization by the "real" TTP (the financial institution) as the basis for their determination that you are an adult or not. Note that this does follow the online TTP model (not the offline TTP/CA model) and has the RP paying for the certification ... not the person being certified.

The corresponding thing done for certain kinds of certificates by TTP/CA ... is that you pay for your certificate with a credit card. The TTP/CA does an authorization for the amount including the AVS option with your name and address. When the amount is authorized ... they can infur from the approval that the name and address also matches ... and they can stuff it into the certificate as certified.

Note both the age verification TTPs and some of the TTP/CAs are relying on the AVS part of a credit card transaction (and in the case of the the age verification transaction ... it is a $1 auth with no settlement that never shows up on your credit card bill) as their backroom certification activity.

general aads subject:
http://www.garlic.com/~lynn/x959.html#aads

some past threads involving "registration authority" subject:
http://www.garlic.com/~lynn/2000.html#41 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001d.html#46 anyone have digital certificates sample code
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001j.html#11 PKI (Public Key Infrastructure)
http://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
http://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature initiative stalled
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss4 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
http://www.garlic.com/~lynn/aadsm5.htm#ocrp2 Online Certificate Revocation Protocol
http://www.garlic.com/~lynn/aadsm5.htm#ocrp3 Online Certificate Revocation Protocol
http://www.garlic.com/~lynn/aadsm8.htm#softpki3 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki4 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsmail.htm#complex AADS/CADS complexity issue
http://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation checking capability
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 updates for (AADS) Relying-Party Certification Business Practices

anders.rundgren@xxxxxxxx at 12/11/2002 12:43 am wrote:
Lynn,
Less is better. Prove one thesis at a time, not hundred. So please describe step-by step how the ad-hoc B2B scheme would work during the sign-up phase.

Using the certificates and TTP PKI the process is as follows 1. A business partner sends a signed signup-request to a prospective partner. The request contains contact information about the business partner. 2. The receving party records the TTP-issued DN (not key) as the PKI identity of the associated company. After possible out-of-band checks, the "account record" is created and secure e-business can begin.

The point is that now the party has a strong, static, revocable and renewable link to the other partner.

It is a bit harder to see how you realize this static-ness in an AADS-scheme where there are no DNs. I believe you must "simulate" such anyway. Hopefully based on DNS rather than X.500.

Actually I think you should write a paper about it instead.

Anders


TTPs & AADS (part II)

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/11/2002 09:26 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Re: TTPs & AADS (part II)
so ... lets explore the gov regulatory/licensing environment.

one of the early assertions was that the TTP/CA certificates are attempting to be an electronic emulation of a hardcopy credential (or possibly license) targeted for the offline but electronic environment. The corresponding assertions is that as the world is rapidly migrating to electronic and online ... that there is a view that the use of a paradigm targeted for offline environment is obsolete technology in an online world.

So we have the 1960s and earlier environment (extending up today) where businesses gets various licenses and credentials from state licensing boards, the better business bureau, the AMA, a like ilk, These can be hung on the wall. If it is a no-value or low-value operation ... the customer is likely to take to take the wall plaque as sufficient. For value transactions, the customer is likely to call up the responsible agency to get a real time check as to things like is the business still in good standing, look for recent references, check about complaints, etc.

We move to the offline, electronic world of the 1980s where the idea of electronic certificates started to happen. Basically these could be considered (offline) substitutes for various kinds of hardcopy instruments, credentials, licenses, and/or certificates. For no-value or low-value operations ... the customer is likely to take the stale, static credential as sufficient. For value transactions, the customers is still likely to call up the responsible agency to get a real time check as to things like is the business still in good standing, look for recent references, check about complaints, etc.

We make it to the late 90s where it looks like the world is quickly becoming online. The licensing agencies look at the issues of providing ancient offline technology or move into the online world. In the online world paradigm, set up a website in lieu of an old-fashion electronic certificate (but probably still issue old fashion hardcopy certificates). The online website has all the information that somebody might be interested in if they were to make a phone call to ask about details related to a specific business. This can be organized hierarchically ... effectively the summary of the information that might appear in a paper certificate ... but having real-time status. The prospective customer can then go into more detail.

The assertions here ... is that even gov. and other kinds of licensing agencies ... which have one of the few business models where the person being certified pays for the certification .... now are faced with the option of being an ancient offline TTP/CA issuing 1980s technology electronic credentials (emulating even orlder, offline hardcopy credentials) ... or move to an online world paradigm that supports real-time, online verification of certifications. The hint here is that these licensing agencies typically are already supporting some type of call-center operation that needs to provide timely verification ... the operation of which can be translated directly into a web site busines service operation.

TTPs & AADS Was: First Data Unit Says It's Untangling Authentication

From: Lynn Wheeler
Date: 12/11/2002 02:01 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "internet-payments" <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Re: TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
possibly a real live business example would also be helpful .... to explain what is going on the real world, everyday in normal business backrooms as a matter of course. see recent posting about versigns online service offering

http://www.garlic.com/~lynn/aepay10.htm#62 VeriSign unveils new online identity verification services

somewhat as an aside ... one of these things that my wife and I had to do when we were working with this small client/server company on what became to be called electronic commerce and payment gateway ... was due diligence on the major certification authorities ... and do an examination of their backroom process.

http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/2001i.html#52

eBay Customers Targetted by Credit Card Scam

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/13/2002 01:19 PM
To: Todd Boyle <tboyle@xxxxxxxx>
cc: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Re: eBay Customers Targetted by Credit Card Scam
there have always been lots of problems with shared-secrets in general ... and especially things that aren't necessarily all that secret ... but easy for people to remember. the aads activity
http://www.garlic.com/~lynn/x959.html#aads

has always been about being able to substitute non-shared-secret paradigm for shared-secret paradigm as method of authentication. the above url has lots of references of such a paradigm ... including a hardware token implementation.

in a larger sense .... this falls into the taxonomy of general skimming/harvesting which in one form or another affects a lot of the payment card industry.

some past fraud related postings
http://www.garlic.com/~lynn/subtopic.html#fraud

a related but different harvesting technique ... also addressed by a non-shared-secret paradigm; aka most shaerd-secret exploits can be addressed by migrating to a non-shared-secret paradigm
http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk

and only somewhat related ... my merged security taxonomy & glossary
http://www.garlic.com/~lynn/secure.htm

description of the sources:
http://www.garlic.com/~lynn/index.html#glosnote

Time to ID Identity-Theft Solutions

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Subject: Time to ID Identity-Theft Solutions
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Date: Fri, 13 Dec 2002 19:11:18 -0700

http://www.techweb.com/tech/security/20021211_security

Time To ID Identity-Theft Solutions
By Larry Lange

"Identity-Theft Reports Soar!" "Internet Makes It Easier To Steal ID!" "Personal Data In Danger!" Those were the headlines back in 2000, when the Federal Trade Commission noted the spike in ID theft. Things sure have changed since: The situation has gotten much worse.

Forget for a moment (if you can) the recent scam involving the theft of more than 30,000 credit reports. A study by Meridian Research predicts that by 2006 nearly a million people a year could find themselves victims of ID theft, with losses adding up to $8 billion annually.

Software vendors and standards groups are moving into action. New gear targets insider hacking (where much of the theft begins), while Oasis has ratified the Security Assertion Markup Language (SAML), which governs how apps can exchange security information via XML. But these are baby steps. Worse, the government seems completely lost: The FTC merely offers a toll-free number (1-877-ID-THEFT), and the Justice Department provides an online quiz about ID theft (http://www.usdoj.gov/ criminal/fraud/idquiz.pdf). Wowie.

Some security insiders say that with more and more personal information residing on networks, identify theft may be unavoidable. But if the only advice they can offer is "get used to it," then maybe it's time to ID a new set of experts.


... snip ...

e-Government uses "Authority-stamp-signatures"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/14/2002 08:05 AM
To: "Jimi Thompson" <jimit@xxxxxxxx>
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: RE: e-Government uses "Authority-stamp-signatures"
past discussion of non-repudiation .... a non-repudiation "service" basically can demonstrate participation of the two end points in a particular message. that makes such a service somewhat independent of the content and/or processes involved in the message .... however for non-repudiation (as opposed to the service) ... there is also electronic signature as well as intention (aka the content of the message as well as the actual electronic signature process).

for a legal signature ... as in manual signature, there is concept of intention ... i.e. demonstrate that person intended to sign what they signed. it is easier to show that when a person writes their signature, they intended to write their signature.

issue in technology with digital signatures ... a piece of computer equipment may have been programed to apply signatures to messages, aka just because the technology has been labeled digital signature doesn't make it a digital equivalent of signatures.

somewhat taxonomy

* hash can demonstrate integrity of transmitted message
* signed hash (i.e. digital signature) can demonstrate origin and integrity of the hash combined with the integrity of the message
* there is still the missing transition from demonstrating origin to demonstrating intention (like demonstrating that the technology was never used for purely integrity/origin ... or if it was, there is demonstratable distinction)
* finally service that demonstrates that origin & destination actually participated

abbreviatied random refs (in this mailing list):
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#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#11 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?

jimt@xxxxxxxx on 12/13/2002 10:19 pm wrote:
In order to establish non-repudiation, won't you need the signature of a person and not just proof that the email passed through a specific server?

signing & authentication (was Credit Card Scam)

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 12/16/2002 02:16 PM
To: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: signing & authentication (was Credit Card Scam)
another take/facet on signing & authentication ... from thread in sci.crypt ng
http://www.garlic.com/~lynn/2002p.html#52
http://www.garlic.com/~lynn/2002p.html#50

note that their is periodically an issue raised regarding using the same token/keypair in multiple environments.

ate fundamentally level is the existing practice based on procedures involving shared-secrets. it is obvious that using shared-secret based keys, pins, numbers, and passwords (either instantiated as tokens or magstripe cards, or memory) in multiple different (security) contexts represents a risk. such risks justify (from a security standpoint) the requirement for a unique token for every unique security context (every different financial institution, every different ISP, every different employer, etc). Envisoning a feature, token-based security environment ... a person might require large tens of such tokens.

it is pretty obvious that a public key used in multiple different (security) contexts is free of the impersonation risks that come with shared-secret based paradigm.

harvesting information from a merchants credit card transaction file enables a crook to perform fraudelent transactions ... somewhat related
http://www.garlic.com/~lynn/2001h.html#61

aka in a shared-secret paradigm the same information that is used to originate a transaction is used to validate a transaction ... as a result the accumulation of such information represents a threat/risk.

the use of public key non-shared-secret paradigm alliviates that particular risk/exploit mode.

there is a business question regarding aggregation of everything into a single token .... where the electronic failure of that single token leaves the individual w/o financial and/or other recourse. this would tend to support a personal choice for having two or three tokens and spreading various business purposes across the tokens (each token having at least some financial capability).

there have been some hypothetical arguments for multiple tokens as risk mitigation because of token theft exploits ... however these tend to much more of a red herring. assuming an iso7816 smartcard hardware token scenario ... a person carries all of their tokens in their wallet or purse. The common unit of (physical) loss/theft is the wallet or purse ... not individual tokens. The advocation of multiple tokens as risk mitigation for loss/theft exploits is only valid if the tokens are distributed in such a way that they wouldn't commonly all be lost/stolen at a single time.

as in other areas .... theat countermeasures (aka risk mitigation) need to correspond with realistic threat/risk scenarios.

Intertrust, Can Victor Shear Bring Down Microsoft?

From: Lynn Wheeler
Date: 12/21/2002 01:33 PM
To: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Intertrust, Can Victor Shear Bring Down Microsoft?
http://web.archive.org/web/20040216152131/http://www.fortune.com/fortune/print/0,15935,400412,00.html
INTERTRUST
Can Victor Shear Bring Down Microsoft?
Maybe not. But his company's patent suit is the biggest legal threat to Microsoft since the antitrust case.
FORTUNE
Tuesday, December 17, 2002
By Roger Parloff Imagine you had a nickel for every compact disc that's ever been made. The patent holders of the CD technology do have nearly all those nickels. Sony Corp. of America and Royal Philips Electronics get 3 cents for every CD manufactured, plus 3% of the price of every CD player sold.


.. snip ...

Intertrust, Can Victor Shear Bring Down Microsoft?

From: Lynn Wheeler
Date: 12/22/2002 07:33 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>
Subject: Re: Intertrust, Can Victor Shear Bring Down Microsoft?
well the original post wasn't so much about bringing down microsoft but being able to patent DRM processes and transactions.

for the past 4-5 years there have been repeated articles and press releases that DRM is the silver bullet for electronic commerce and payments on the internet. A simple summary of past DRM articles would be that when (and if) DRM payment transactions on the internet takes off ... that there will be ten times as many DRM payment transaction as all other payment transactions combined .... and that whatever internet payment implementation emerges for DRM would come to dominate the whole payment industry (not just internet payments). Whether you believe the thesis as true or not ... DRM related matters tend to get some play in the payments industry. The area of internet payments tends to include things like major market niches that would result in payments on the internet .... in addition to what might be the best possible technical solution for doing payments on the internet (the DRM assurtion would be that it doesn't make any difference what the best possible solution is ... whatever emerges for DRM will dominate).

so to follow random thread drifts ... we can revert to one of the previous questions as to whether identity or payment is more important in payments. simplifying a previous scenario
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible ink, e-signatures slow to broadly catch on

lets say i walk into a store in frankfurt to get a black leather coat. the clerk has an option to do one:

A) have me insert my passport that has a chip with a x.509v3 identity certificate and do an online OCSP transaction to see if I'm still me

B) have me insert my payment chip card and do an online x9.59/iso8583 payment transaction to see if they are going to get paid.

In the DRM world of possible enormous numbers of small transactions ... there are important issues of both efficiency and security. In the past there was some thot that efficiency significantly dominated security. However there are issues about using electronic technology to fraudulently aggregate large numbers of small value DRM transactions resulting in extremely huge sums.

anders.rundgren@xxxxxxxx on 12/22/2002 6:43 am wrote:
Being relatively uninterested in bringing down Microsoft, but extremely interested in the key to secure commerce, I wonder if someone can shed some more light on this "fantastic" technology that took more that 3 years to productify?

http://www.intertrust.com/main/overview/trustcomputing.html

Paying $400M for a 39-person company seems a bit steep these days but who knows....

Anders


Intertrust, Can Victor Shear Bring Down Microsoft?

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 12/22/2002 08:28 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "internet-payments" <internet-payments@xxxxxxxx>
Subject: Intertrust, Can Victor Shear Bring Down Microsoft?
http://www.garlic.com/~lynn/aadsm12.htm#61
http://web.archive.org/web/20040216152131/http://www.fortune.com/fortune/print/0,15935,400412,00.html

quote from the above/referenced article:
Now imagine that one company holds the key patents to the whole shebang--not just methods to secure music and movies, but the entire spectrum of digital commerce. Imagine that revenue stream.


... so patent coverage that covers "the entire spectrum of digital commerce" might be considered to have a little impact on internet payments.

misc. past DRM refs:
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
http://www.garlic.com/~lynn/aepay3.htm#disputes Half of Visa's disputes, fraud result from I-commerce (more)
http://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
http://www.garlic.com/~lynn/2002m.html#55 Beware, Intel to embed digital certificates in Banias
http://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
http://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#16 Feasability of Palladium / TCPA
http://www.garlic.com/~lynn/aadsm12.htm#17 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/aadsm12.htm#25 Cryptogram: Palladium Only for DRM
http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aepay10.htm#18 FC: European Commission considers mandatory digital rights management

Invisible Ink, E-signatures slow to broadly catch on (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/22/2002 08:30 PM
To: epay@xxxxxxxx
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
"Robert E. Frank" <bobfrank@xxxxxxxx>,
internet-payments <internet-payments@xxxxxxxx>,
Einar Stefferud <Steflist@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on (addenda)
for those that just have to have certificates .... past discussion about how to compress certificates to zero bytes for payload efficiency:
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 updates for (AADS) Relying-Party Certification Business Practices
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary
http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#3 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
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#72 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001d.html#31 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???

egerck@xxxxxxxx on 12/21/2002 9:44 am wrote:
And, PKI certs are simply too big for wireless and also for everyday use -- this message would probably more than double in size if signed.

Cheers, Ed Gerck


Online shopping passes $11 billion

From: Lynn Wheeler
Date: 12/24/2002 08:02 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Online shopping passes $11 billion
it would be interesting to know what the distribution/skew of volume versus merchants ... and what the relation of the 2000 "stores" to online merchant sites.

http://news.com.com/2100-1017-978712.html?tag=fd_top
Online shopping passes $11 billion

By Margaret Kane Staff Writer, CNET News.com December 23, 2002, 10:56 AM PT

Shoppers continued to hit the Net as the holiday shopping season headed into the final lap, spending $11.35 billion between Nov. 1 and last week.

That number--an increase of about 40 percent from the same period last year-- comes from shopping comparison site BizRate, which surveys consumers as they finish making purchases. BizRate has about 2,000 stores in its database.


... snip ...

Subpoena Sidelines PKI Project

From: Lynn Wheeler
Date: 12/24/2002 09:41 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Subpoena Sidelines PKI Project
and of course ... my standard response that it is possible to do digital signature authentication w/o requiring certificates .... aka corporate access can be done with radius or kerberos .... using digital signatures and certificates have nothing at all to do with it (aka frequent description that you just wave certificates over a bunch of bits and the rest is magic; digital signature?, digital signature!, we need no #$% digital sigatures!!!).

http://www.computerworld.com/securitytopics/security/story/0,10801,76940,00.html
Government Subpoena Sidelines PKI Project

A court order sentences our security manager to two weeks of hard labor creating forensic images of employee hard drives.

By MATHIAS THURMAN DECEMBER 23, 2002

Now that my company's wireless LAN project is under control and ready for deployment, I thought I could start my research project on public-key infrastructure (PKI). That was before the feds dropped by this week with a subpoena. But more on that in a moment.

With regard to PKI, I have a feeling that once my company sees the costs involved, it will more than likely find some way of postponing or even killing the project. Until that decision is made, however, I'm pressing on with the feasibility study and will provide some pricing options to the executive staff. As part of the study, I plan to assemble a list of areas within the company that I feel could benefit from PKI.

The obvious areas include e-mail, disk and file encryption, and virtual private network (VPN) access. To further assist me in determining other areas that would benefit, I've scheduled meetings with representatives from different departments. I need to understand all the enterprise applications being used within the company and get a feel as to how receptive key managers and employees will be to a PKI implementation.

One of the traditional problems with PKI is that most people don't really understand the technology and how it could benefit them and their companies. Most of the time, each employee has his own idea or interpretation of what PKI is and what it can offer. By meeting with key individuals from each department, I can determine whether PKI might benefit each area.

For example, in talking with a representative from the professional services group, I learned that we have a Web-based professional services automation (PSA) tool, which is currently accessed via a VPN connection from employee laptops. There is some frustration within the team, as some of our company engagements are in government facilities that don't allow us to use our laptops. They do, however, let our consultants use the government computer systems to access the Internet (go figure). PKI would allow our employees to obtain a short-term certificate that they could use to access the PSA tool.

I've spent a considerable amount of time on wireless connectivity within the company. By using PKI, I can control wireless access by issuing certificates to those individuals who should be allowed access. The certificates can be stored in a Universal Serial Bus-type device that's small enough to fit on a key chain, or the certificates can be stored on the user's laptop. Once I get a handle on which departments and applications can benefit, I can formulate a request for information and submit it to a few PKI integrators. We hope to find one company that can handle all of our requirements. A PKI implementation will require a substantial amount of money, however, so at this point, I suspect that we will back off.


... snip ...

Offline Root CA with valid CRL hierachie

From: Lynn Wheeler
Date: 12/31/2002 04:23 PM
To: "Ambarish Malpani" <ambarish@xxxxxxxx>
cc: "David P. Kemp" <dpkemp@xxxxxxxx>, ietf-pkix@xxxxxxxx,
     "Mitchell Arnone" <marnone@xxxxxxxx>
Subject: RE: Offline Root CA with valid CRL hierachie
note that this is one of the places that it would become difficult to turn the current manufactured certificate infrastructure for SSL domain name certificates into a PKI.

The customer of a SSL domain name CA are all the web servers in the world. The relying-parties are (at least) every browser in the world (aka every client in the world potentially having multiple browsers). "Every time" would in effect be everytime a SSL/HTTPS session anywhere in the world was ever initiated .... aka everytime a browser initiated an SSL/HTTPS session there potentially would require a CRL fetch (assuming a pull paradigm; assuming a push paradigm then every CA would have to transmit their CRLs to every possible browser in the world .... with every possible client in the world possibly having multiple different browsers).

Also .... there is some difficulty in a CA "telling" every RP in such an infrastructure anything .... since actual RPs are infrequently predetermined. Possible sidestep is some sort of browser intialization informing the "human" operator of the browser some text extracted from each pre-installed root certificate.

random ref:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

ambarish@xxxxxxxx on 12/31/2002 2:52 pm wrote:
Hi Mitchell,
As a CA, you can tell the RP (relying party) that it is responsible for fetching the latest CRL. If you then give it no way of knowing when to get a new CRL, any serious security client would keep checking for a new CRL every time it needed to validate a certificate/certification path.

As a root CA, it is very unlikely that your directory could handle the load you would get from every client trying to get your latest CRL for every certificate that chains up to you (distribution is the real scalability problem with CRLs - as opposed to OCSP - not generation).
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani 650.759.9045
Malpani Consulting Services ambarish@xxxxxxxx
http://www.malpani.biz


AADS Postings and Posting Index, next, previous - home