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
Refed: **, - **, - **
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"
https://web.archive.org/web/20070706004855/http://internetcouncil.nacha.org/News/news.html
it was close to the x9.59 standard mapping to iso8583 standard
https://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):
https://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
https://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
https://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
https://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
https://www.garlic.com/~lynn/aadsm9.htm#cfppki3 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsmore.htm#x959demo AADS & X9.59 demos at BAI (annual world-wide retail banking) show in miami next week
https://www.garlic.com/~lynn/aepay6.htm#userauth MS masters NC mind-set (authentication is the key)
https://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy
https://www.garlic.com/~lynn/ansiepay.htm#x959demo X9.59/AADS demos operational
https://www.garlic.com/~lynn/99.html#216 Ask about Certification-less Public Key
https://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:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
some past postings on identity, authentication and privacy
https://www.garlic.com/~lynn/subpubkey.html#privacy
one of the original SSOs is kerberos, kerberos is a IETF/internet standard.
for kerberos related RFCs go to
https://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:
https://www.garlic.com/~lynn/subpubkey.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:
https://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/
https://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):
https://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
https://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:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2 assurance, e-commerce, and some x9.59
https://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.
https://www.garlic.com/~lynn/x959.html#aads
https://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
https://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:
https://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:
https://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
https://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:
https://www.garlic.com/~lynn/2001h.html#61 security proportional to risk
slightly related
https://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
https://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:
https://www.garlic.com/~lynn/aadsm12.htm#13 anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa?
https://www.garlic.com/~lynn/2002h.html#71 history of CMS
https://www.garlic.com/~lynn/2002h.html#84 history of CMS
https://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
https://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:
https://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:
https://www.garlic.com/~lynn/subintegrity.html#fraud
https://www.garlic.com/~lynn/subintegrity.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 successful 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:
https://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
https://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
https://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature initiative stalled
https://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
https://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech9 cardtech/securetech & CA PKI
https://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))
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo2 QC Bio-info leak?
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo3 QC Bio-info leak?
https://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
https://www.garlic.com/~lynn/aepay3.htm#x959risk1 Risk Management in AA / draft X9.59
https://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment standard issue
https://www.garlic.com/~lynn/2000.html#46 question about PKI...
https://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:
https://www.garlic.com/~lynn/2001j.html#5 E-commerce security
https://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 successful.
thread somewhat analogous to this one:
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn1
https://www.garlic.com/~lynn/aadsm5.htm#asrn4
slightly related mumblings on security proportional to risk
https://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
https://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 every time
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:
https://www.garlic.com/~lynn/aadsm2.htm#straw
or refs at (under subject aads chip strawman):
https://www.garlic.com/~lynn/x959.html#aads
random evauation refs:
https://www.garlic.com/~lynn/aadsm12.htm#13 anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa?
https://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
Refed: **, - **, - **
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
https://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:
https://www.garlic.com/~lynn/subpubkey.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:
https://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:
https://www.garlic.com/~lynn/2002k.html#12
extract of email i got announcing the award and asking to participate
https://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:
https://www.garlic.com/~lynn/2001h.html#65
misc. other refs:
https://www.garlic.com/~lynn/internet.htm#0
https://www.garlic.com/~lynn/subpubkey.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:
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
https://www.garlic.com/~lynn/2000.html#0 2000 = millennium?
https://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...
https://www.garlic.com/~lynn/2000f.html#79 Cryptogram Newsletter is off the wall?
https://www.garlic.com/~lynn/2001f.html#39 Ancient computer humor - DEC WARS
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#51 future of e-commerce
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001j.html#46 Big black helicopters
https://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral infection?
https://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001n.html#70 CM-5 Thinking Machines, Supercomputers
https://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002h.html#13 Biometric authentication for intranet websites?
https://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
https://www.garlic.com/~lynn/2002l.html#26 Do any architectures use instruction count instead of timer
https://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
https://www.garlic.com/~lynn/2002m.html#8 Backdoor in AES ?
https://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:
https://www.garlic.com/~lynn/subpubkey.html#rpo
and of course ... the misc postings on end-game of why eventually TTPs
would even be issuing server domain name certificates
https://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
https://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:
https://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security paper
https://www.garlic.com/~lynn/aadsm12.htm#18 Overcoming the potential downside of TCPA
https://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
https://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
https://www.garlic.com/~lynn/2001d.html#8 Invalid certificate on 'security' site.
https://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#51 future of e-commerce
https://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001n.html#75 A PKI question and an answer
https://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
https://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002h.html#13 Biometric authentication for intranet websites?
https://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
https://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002j.html#24 Definition of Non-Repudiation ?
https://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
https://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
https://www.garlic.com/~lynn/2002l.html#28 Two questions on HMACs and hashing
https://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.
https://www.garlic.com/~lynn/subpubkey.html#privacy
https://www.garlic.com/~lynn/subintegrity.html#fraud
https://www.garlic.com/~lynn/subpubkey.html#rpo
https://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:
https://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
https://www.garlic.com/~lynn/subpubkey.html#rpo
privacy/identification related postings
https://www.garlic.com/~lynn/subpubkey.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
https://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
https://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
https://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:
https://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security paper
https://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
https://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
https://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
https://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
https://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national ID card?
https://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:
https://www.garlic.com/~lynn/subpubkey.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):
https://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.
https://www.garlic.com/~lynn/aadsm5.htm#asrn1Assurance, e-commerce, and some x9.59 ... fyi
https://www.garlic.com/~lynn/aadsm5.htm#asrn2Assurance, e-commerce, and some x9.59 ... fyi
https://www.garlic.com/~lynn/aadsm5.htm#asrn3Assurance, e-commerce, and some x9.59 ... fyi
https://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:
https://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:
https://www.garlic.com/~lynn/2001h.html#61
and lots of past stuff about various kinds of fraud, exploits, etc:
https://www.garlic.com/~lynn/subintegrity.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:
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.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:
https://www.garlic.com/~lynn/x959.html#aads
as well as work applying it to various ietf internet standards like
Kerberos and RADIUS
https://www.garlic.com/~lynn/subpubkey.html#radius
also
https://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?
> https://www.garlic.com/~lynn/aadsm5.htm#asrn1Assurance, e-commerce, and > some x9.59 ... fyi
> https://www.garlic.com/~lynn/aadsm5.htm#asrn2Assurance, e-commerce, and
> some x9.59 ... fyi
> https://www.garlic.com/~lynn/aadsm5.htm#asrn3Assurance, e-commerce, and
> some x9.59 ... fyi
> https://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
https://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.
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn1
https://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 successful 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
https://www.garlic.com/~lynn/aadsm12.htm#50 Frist Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#51 Frist Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#53 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
the successful 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 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:
https://www.garlic.com/~lynn/x959.html#aads
some past threads involving "registration authority" subject:
https://www.garlic.com/~lynn/2000.html#41 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
https://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001d.html#46 anyone have digital certificates sample code
https://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
https://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key?
https://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001j.html#11 PKI (Public Key Infrastructure)
https://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
https://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature initiative stalled
https://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
https://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))
https://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
https://www.garlic.com/~lynn/aadsm5.htm#ocrp2 Online Certificate Revocation Protocol
https://www.garlic.com/~lynn/aadsm5.htm#ocrp3 Online Certificate Revocation Protocol
https://www.garlic.com/~lynn/aadsm8.htm#softpki3 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki4 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsmail.htm#complex AADS/CADS complexity issue
https://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation checking capability
https://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
https://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
https://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
https://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 business 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
https://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.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
https://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
https://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
https://www.garlic.com/~lynn/subintegrity.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
https://www.garlic.com/~lynn/2001h.html#61 security proportional to risk
and only somewhat related ... my merged security taxonomy & glossary
https://www.garlic.com/~lynn/secure.htm
description of the sources:
https://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):
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
https://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
https://www.garlic.com/~lynn/2002p.html#52
https://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
https://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?
https://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
https://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?
https://www.garlic.com/~lynn/aadsm12.htm#61
https://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:
https://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
https://www.garlic.com/~lynn/aepay3.htm#disputes Half of Visa's disputes, fraud result from I-commerce (more)
https://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002m.html#55 Beware, Intel to embed digital certificates in Banias
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
https://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/aadsm12.htm#16 Feasability of Palladium / TCPA
https://www.garlic.com/~lynn/aadsm12.htm#17 Overcoming the potential downside of TCPA
https://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
https://www.garlic.com/~lynn/aadsm12.htm#25 Cryptogram: Palladium Only for DRM
https://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
https://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:
https://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
https://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))
https://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))
https://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
https://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
https://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
https://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
https://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 updates for (AADS) Relying-Party Certification Business Practices
https://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
https://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
https://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary
https://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
https://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication implementation
https://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#3 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
https://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001d.html#31 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
https://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
https://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 every time a SSL/HTTPS
session anywhere in the world was ever initiated .... aka every time 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:
https://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