> Here you're talking about "reputation of nyms", which doesn't require
> third parties or certs, just well-kept secret keys of a PK pair.
> If the remote entity keeps using the same PK keys, you can reasonably
> update reputation
> based on that alone. (They're essentially signing their behavio
>[The
>question isn't some sort of mystification of identity -- it is being
>able to know that you're talking to the same "Dear Abby" your friends
>have talked to and that you talked to last week.
Here you're talking about "reputation of nyms", which doesn't require
third parties or certs, just
On Tue, 15 Jan 2002, D. A. Honig wrote:
> [Moderator's note: Except that's precisely the point: "Modulo MIM
> attacks" is like saying "we're all immortal, modulo death". The
> question isn't some sort of mystification of identity -- it is being
> able to know that you're talking to the same "Dear
At 01:59 PM 1/14/02 -0800, Eric Rescorla wrote:
>Saying that SSL without certificates is fine as long as you
>don't have active attacks is kind of like saying that leaving
>your front door open is fine as long as noone tries to break
>in.
No, its more. SSL sans certs is like using envelopes to w
Carl Ellison <[EMAIL PROTECTED]> writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> At 02:47 PM 1/14/2002 -0800, Eric Rescorla wrote:
> >> Meanwhile, the information that the user
> >> really looks at to make a security decision (the Palm logo and the
> >> little padlock) aren't rela
At 02:47 PM 1/14/2002 -0800, Eric Rescorla wrote:
>> Meanwhile, the information that the user
>> really looks at to make a security decision (the Palm logo and the
>> little padlock) aren't related at all.
>No possible security system can protect people who trust
>whatever logo happens to be tra
At 12:09 PM -0500 1/14/02, John S. Denker wrote:
>...
>Returning to PKI in particular and software defects in
>particular: Let's not make this a Right-versus-Wrong
>issue. There are intricate and subtle issues here.
>Most of these issues are negotiable.
>
>In particular, you can presumably get s
Carl Ellison <[EMAIL PROTECTED]> writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> At 02:19 PM 1/14/2002 -0800, Eric Rescorla wrote:
> >> Of course you do. That's why https://store.palm.com/ is such a
> >> problem. You thought you were talking to (and wanted to talk to)
> >> Palm C
At 02:19 PM 1/14/2002 -0800, Eric Rescorla wrote:
>> Of course you do. That's why https://store.palm.com/ is such a
>> problem. You thought you were talking to (and wanted to talk to)
>> Palm Computing, just like the logos and page layout said you were.
>> You're not. You're talking to a MITM.
Carl Ellison <[EMAIL PROTECTED]> writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> At 09:44 AM 1/14/2002 -0800, Eric Rescorla wrote:
> >"Stef Caunter" <[EMAIL PROTECTED]> writes:
> >> Does a user of ssl services care to know absolutely that they are
> >> communicating verifiably with
At 09:44 PM 12/26/2001 +, Phillip Hallam-Baker wrote:
[snip]
>What we are not seeing is demand for naming semantics of the form 'the
>person who fred call's jim'.
You're right. That was a nice feature of SDSI, but I have see no call for it either,
and I probably would before you would.
At 09:44 AM 1/14/2002 -0800, Eric Rescorla wrote:
>"Stef Caunter" <[EMAIL PROTECTED]> writes:
>> Does a user of ssl services care to know absolutely that they are
>> communicating verifiably with whom they believe they have contacted, or does
>> the user care to know absolutely that their communi
"Stef Caunter" <[EMAIL PROTECTED]> writes:
>
> > "Stef Caunter" <[EMAIL PROTECTED]> writes:
> > > Does a user of ssl services care to know absolutely that they are
> > > communicating verifiably with whom they believe they have contacted, or
> does
> > > the user care to know absolutely that thei
- Original Message -
From: "Eric Rescorla" <[EMAIL PROTECTED]>
To: "Stef Caunter" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "SPKI Mailing List"
<[EMAIL PROTECTED]>
Sent: Monday, January 14, 2002 12:44 PM
Subject: Re: CFP: PKI
"Stef Caunter" <[EMAIL PROTECTED]> writes:
> Does a user of ssl services care to know absolutely that they are
> communicating verifiably with whom they believe they have contacted, or does
> the user care to know absolutely that their communication is completely
> private?
These are inextricably
At 10:49 AM 1/12/02 -0800, Carl Ellison wrote:
>
>If that's not good enough for you, go to https://store.palm.com/
>where you have an SSL secured page. SSL prevents a man in the middle
>attack, right? This means your credit card info goes to Palm
>Computing, right? Check the certificate.
>
Mor
[EMAIL PROTECTED] wrote:
>...
> People running around in business selling
> products and services and then disclaiming any liability with regard
> to their performance _for_their_intended_task_ is, IMHO, wrong.
IMHO this presents an unsophisticated notion of
"right versus wrong".
By way of ana
Does a user of ssl services care to know absolutely that they are
communicating verifiably with whom they believe they have contacted, or does
the user care to know absolutely that their communication is completely
private?
I believe that the latter is most important; transparency through
certific
Eric Rescorla wrote:
>
> Ben Laurie <[EMAIL PROTECTED]> writes:
>
> > Michael Sierchio wrote:
> > >
> > > Carl Ellison wrote:
> > >
> > > > If that's not good enough for you, go to https://store.palm.com/
> > > > where you have an SSL secured page. SSL prevents a man in the middle
> > > > attac
[EMAIL PROTECTED] wrote:
> If an automaker disclaimed liability for a vehicle, and a negligent
> design or manufacture resulted in injury or loss, it is my
> understanding that the liability disclaimer notwithstanding, the
> automaker would be held responsible. Why do we believe that the same
>
<[EMAIL PROTECTED]> writes:
> Eric Rescorla writes:
> > <[EMAIL PROTECTED]> writes:
> > > If an automaker disclaimed liability for a vehicle, and a negligent
> > > design or manufacture resulted in injury or loss, it is my
> > > understanding that the liability disclaimer notwithstanding, the
Eric Rescorla writes:
> <[EMAIL PROTECTED]> writes:
>
> > Eric Rescorla writes:
> > > Ben Laurie <[EMAIL PROTECTED]> writes:
> > > > And most (all?) commercial CAs then disclaim any responsibility for
> > > > having actually checked that right correctly...
> > > While this is true, I'd
<[EMAIL PROTECTED]> writes:
> Eric Rescorla writes:
> > Ben Laurie <[EMAIL PROTECTED]> writes:
> > > And most (all?) commercial CAs then disclaim any responsibility for
> > > having actually checked that right correctly...
> > While this is true, I'd point out that all the security software
>
Eric Rescorla writes:
> Ben Laurie <[EMAIL PROTECTED]> writes:
>
> > Michael Sierchio wrote:
> > >
> > > Carl Ellison wrote:
> > >
> > > > If that's not good enough for you, go to https://store.palm.com/
> > > > where you have an SSL secured page. SSL prevents a man in the middle
> >
Ben Laurie <[EMAIL PROTECTED]> writes:
> Michael Sierchio wrote:
> >
> > Carl Ellison wrote:
> >
> > > If that's not good enough for you, go to https://store.palm.com/
> > > where you have an SSL secured page. SSL prevents a man in the middle
> > > attack, right? This means your credit card i
Michael Sierchio wrote:
>
> Carl Ellison wrote:
>
> > If that's not good enough for you, go to https://store.palm.com/
> > where you have an SSL secured page. SSL prevents a man in the middle
> > attack, right? This means your credit card info goes to Palm
> > Computing, right? Check the cert
to be fair ... most commercial CA's have to verify with the domain name
infrastructure as to the owner of the domain name ... before issuing a SSL
domain name server cert. Note however, one of the justifications for having
SSL domain name server cert is because of concerns with regard to domain
n
Michael Sierchio <[EMAIL PROTECTED]> writes:
> Carl Ellison wrote:
>
> > If that's not good enough for you, go to https://store.palm.com/
> > where you have an SSL secured page. SSL prevents a man in the middle
> > attack, right? This means your credit card info goes to Palm
> > Computing, rig
At 11:31 AM 1/12/2002 -0800, Michael Sierchio wrote:
>Carl Ellison wrote:
>
>> If that's not good enough for you, go to https://store.palm.com/
>> where you have an SSL secured page. SSL prevents a man in the
>> middle attack, right? This means your credit card info goes to
>> Palm
>> Computing,
Carl Ellison wrote:
> If that's not good enough for you, go to https://store.palm.com/
> where you have an SSL secured page. SSL prevents a man in the middle
> attack, right? This means your credit card info goes to Palm
> Computing, right? Check the certificate.
To be fair, most commercial
Carl Ellison <[EMAIL PROTECTED]> writes:
> If that's not good enough for you, go to https://store.palm.com/
> where you have an SSL secured page. SSL prevents a man in the middle
> attack, right? This means your credit card info goes to Palm
> Computing, right?
No. It means that your credit card
At 05:45 PM 12/26/2001 -0500, Perry E. Metzger wrote:
>
>
>"Phillip Hallam-Baker" <[EMAIL PROTECTED]> writes:
>> Methinks you complain too much.
>>
>> PKI is in widespread use, it is just not that noticeable when you
>> use it. This is how it should be. SSL is widely used to secure
>> internet pa
Russ Neson writes:
> 3. Cryptography, and therefore PKI, is meaningless unless you first
> define a threat model. In all the messages with this Subject, I've
> only see one person even mention "threat model". Think about the
> varying threat models, and the type of cryptography one would propose
one of the largest financial networks ... slightly different kind
http://www.garlic.com/~lynn/2001n.html#22
again financial ... discussion of additional kinds of risks/threats
Sound Practices for the Management and Supervision of Operational Risk
http://www.bis.org/publ/bcbs86.htm
Intro ...
The PAIIN model (privacy, authentication, identification, integrity,
non-repudiation) is inadequate to represent the uses of cryptography.
Besides the distinction between privacy and confidentiality, I'd like
to point out some additional uses of cryptography which either don't
fit at all or ar
aka ... lots of people seem to equate privacy with personal privacy (as
well as legislative specification) ... while confidentiality has more of a
non-personal connotation
there seems to be 3-4 postings from yesterday that are still lost in the
ether ... they are recorded at
http://www.garlic.c
well PAIN is out of some standards organization (as is 3-factor
authentication) i agree that privacy and confidentiality is sometimes
thot of as different but others argue that it reduces to the
effectively the same requirements ... even tho different people have
different connotations
repudiation,
> privacy, security)
>
> an aspect of security can be integrity and and aspect of integrity can be
> dependability leading to things like:
> http://www.hdcc.cs.cmu.edu/may01/index.html
>
> which is then related back to my posting on sunday (with regard to
> in
to things like:
http://www.hdcc.cs.cmu.edu/may01/index.html
which is then related back to my posting on sunday (with regard to
integrity)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki10 CFP: PKI research workshop
[EMAIL PROTECTED] on 12/31/2001 8:32 pm wrote:
to which I would add:
3. Cry
somewhat as an aside ... the requirement(s) given the X9A10 financial
standards working group for the development of the X9.59 standard was
* to preserve the integrity of the financial infrastructure for all retial
electronic payments without the use of encryption
"ALL" didn't just mean interne
Andrew Odlyzko writes:
> 1. Cryptography does not fit human life styles easily.
> 2. Novel technologies take a long time to diffuse through society.
to which I would add:
3. Cryptography, and therefore PKI, is meaningless unless you first
define a threat model. In all the messages with this
"Arnold G. Reinhold" <[EMAIL PROTECTED]> writes:
>The EWR monorail had been shut down for the better part of a year to correct a
>pesky track corrosion problem (it's hard to get all the bugs out of a system
>that is not widely used).
Thus making it a perfect analogy for PKI [0].
Peter.
[0] Bef
somewhat as an aside the "gift" cards (and other flavors) that you see
at large percentage of retail check-out counters in the US are effectively
digital cash ... although the current incarnation results in a different
card at every retailer. however, they are online, magstripe-based digital
another aspect that overlaps PKIs and quality is the difference between
"application" code and "service" code turning an application into a
service can be hard possibly writing 4-10 times as much code as in the
base application infrastructure and very high-quality code
dealing
everyday life has a lot of cryptography ... for instance ... there is quite
a bit of cryptography involved in every debit transaction (every time you
get money from ATM machine or use point-of-sale terminal).
a lot of PKI revolves around the business process of strong authentication
where s
Several of the comments about the slow uptake of PKI touch on what
seem to be two basic factors that are responsible for this phenomenon:
1. Cryptography does not fit human life styles easily. As an example,
truly secure systems would stop secretaries from forging their boss's
signatures, and t
both atm debit network and domain name infrastructure care capable of local
caching so that timelyness is within seconds to minutes (or a few hrs
as parameter within the needs of the infrastructure). the offline world for
certificates is the analogy of the letters of credit from the days of
nt: Friday, December 28, 2001 2:34 PM
To: Peter Gutmann; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: CFP: PKI research workshop
Let us see.
Monorails are commonplace in airports these days.
Web cams for online chat are used by millions of teenagers
SST ? Wh
ECTED]>
>To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>; [EMAIL PROTECTED]
><[EMAIL PROTECTED]>; [EMAIL PROTECTED]
><[EMAIL PROTECTED]>
>Date: 27 December 2001 21:42
>Subject: Re: CFP: PKI research workshop
>
>
> >>As I never tire of saying, "PKI is
On Thu, 27 Dec 2001 [EMAIL PROTECTED] wrote:
>given that authentication is being performed as part of some business
>process or function ... then it is normally trivial to show it is easier
>to have authentication (even digital signature authentication) integrated
>into such business processes
IL PROTECTED]
<[EMAIL PROTECTED]>; [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
Date: 27 December 2001 21:42
Subject: Re: CFP: PKI research workshop
>>As I never tire of saying, "PKI is the ATM of security."
>
>Naah, it's the monorail/videophone/SST of security. Loo
It seems to me that a very similar argument can be made regarding the
need (or lack there of) for a national identity card. Organizations
that require biometric identity can simply record that information in
their own databases. The business most widely cited as needing
national ID cards, the
I would tend to make the statement even stronger.
large, complex legacy systems tend to have slow technology uptake. most of
the certification authorities can be deployed in simple demos w/o impacting
the legacy systems and business process (possibly as a front-end process
that is pealed off bef
Nelson Minar <[EMAIL PROTECTED]> writes:
>The thing that makes me the most sad is that the PKI situation only seems to
>be getting worse, not better.
The reason for this is that as we work on PKI deployment, we discover more and
more (previously unknown) problems which need to be solved. If you
>As I never tire of saying, "PKI is the ATM of security."
Naah, it's the monorail/videophone/SST of security. Looks great at the World
Fair, but a bit difficult to turn into a reality outside the fairgrounds.
Peter (who would like to say that observation was original, but it was actually
it isn't that you move it to a central authority you move it to an
authority that typically is already established in association with
authorization ... aka in normal business operation, a business relationship
is established that typically consists of creating an account record that
has var
Nelson Minar wrote:
> >Of course, client side certificates barely even exist, although
> >people made substantial preparation for them early on in the history
> >of all of this.
>
> I used to be puzzled by this. Then a couple of years ago I went
> through the process of getting a client-side cert
The ABA Information Security Committee has a mailing list where some
great discussion of this is taking place. It's a closed mailing list;
ABA members only, but the archives are public.
I recommend looking at some of the articles there; this one is a great
starting point:
http://mail.abanet.
for the most part HTTPS SSL is certificate manufactoring (a term we coined
a couple years ago) "infrastructure" typically implies the
administrative and management which would require (at a minimum) CRLs
for a certificate-based PKI.
the interesting thing about the use of SSL domain nam
PHB:
> PKI is in widespread use, it is just not that noticeable when you use it.
> This is how it should be. SSL is widely used to secure internet payment
> transactions.
PM:
> HTTPS SSL does not use PKI.
Could someone define PKI (beyond just what it stands for, Public Key
Infrastructure)? It l
>HTTPS SSL does not use PKI. SSL at best has this weird system in which
>Verisign has somehow managed to charge web sites a toll for the use of
>SSL even though for the most part the certificates assure the users of
>nothing whatsoever.
To be fair, Verisign *is* a PKI. It's not the one a lot of u
"Phillip Hallam-Baker" <[EMAIL PROTECTED]> writes:
> Methinks you complain too much.
>
> PKI is in widespread use, it is just not that noticeable when you use it.
> This is how it should be. SSL is widely used to secure internet payment
> transactions.
HTTPS SSL does not use PKI. SSL at best h
on Wed, Dec 26, 2001 at 07:45:13AM -0800, Carl Ellison ([EMAIL PROTECTED]) wrote:
> Ray,
>
> if you look at PKI as a financial mechanism (like credit cards),
> then I see two major problems:
>
> 1.the PKI vendors aren't financial institutions, so they aren't in a
> position to assume r
I doubt if fast/fstc participants would look at the following example as a
prime example but there are various "age" authentication services that
are available on the internet today ... basically associated with adult
entertainment ... but would also be applicable to online gambling, various
Methinks you complain too much.
PKI is in widespread use, it is just not that noticeable when you use it.
This is how it should be. SSL is widely used to secure internet payment
transactions. S/MIME use is significant and growing.
The financial industry is not looking at offline PKI models in ge
again, why would the financial industry be interested in regressing (at
least) 30 years to a certificate-based offline model?
they do authentication of transactions that they also need to do
authorization for in a model that has prior business relationship
between the parties. certificate-
possibly not the ATM you were thinking of certificate-less digital
signature authentication by NACHA/ATM/debit networks
http://www.garlic.com/~lynn/index.html#aads
specific web page:
http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm
financial industry standard for dig
note that the certificate-based PKI is an offline model it is the
credit card model pre-1970. the certificate-based PKI tends to bear a lot
of other resumblance to pre-1970 offline credit-card model the CRLs
invention is very similar to the paper booklets that were mailed out to
merchan
On Wed, 26 Dec 2001, Matt Crawford wrote:
>As I never tire of saying, "PKI is the ATM of security."
>
>Meaning that has a certain niche relevance, but is claimed by
>proponents to be the answer to every need, and is the current magic
>word for shaking the money tree.
>
In fact, that may be exa
On Wed, 26 Dec 2001, Carl Ellison wrote:
>Ray,
>
> if you look at PKI as a financial mechanism (like credit cards),
>then I see two major problems:
>
>1. the PKI vendors aren't financial institutions, so they aren't in a
>position to assume risk and make money from that
Yep. So far,
Ray,
if you look at PKI as a financial mechanism (like credit cards),
then I see two major problems:
1. the PKI vendors aren't financial institutions, so they aren't in a
position to assume risk and make money from that
2. the current PKI thinking (e.g., with "rebuttable presu
As I never tire of saying, "PKI is the ATM of security."
Meaning that has a certain niche relevance, but is claimed by
proponents to be the answer to every need, and is the current magic
word for shaking the money tree.
-
The
On Sat, 1 Dec 2001, Carl Ellison wrote:
>To a large extent, the hoped-for public key infrastructure (PKI) has
>not "happened yet." PKI for large, eclectic populations has not
>materialized; PKI for smaller, less diverse "enterprise" populations
>is beginning to emerge, but at a slower rate tha
Included below is the ASCII CFP for our upcoming PKI research
workshop. We're especially soliciting papers on ways to use public
key authentication/authorization that solve real problems, rather
than merely follow the traditional marketing patter about PKI.
==
74 matches
Mail list logo
