On Mon, 30 Aug 2010 13:49:54 +0100 Ben Laurie wrote:
> On 02/08/2010 12:32, Ian G wrote:
> > We are facing Dan Geer's disambiguation problem:
> >
> >> The design goal for any security system is that the
> >> number of failures is small but non-zero, i.e., N>0.
> >> If the number of failures is ze
On Mon, 2 Aug 2010 16:20:01 -0500 Nicolas Williams
wrote:
> But users have to help you establish the context. Have you ever
> been prompted about invalid certs when navigating to pages where
> you couldn't have cared less about the server's ID? On the web,
> when does security matter? When you
On Mon, Aug 02, 2010 at 11:29:32AM -0400, Adam Fields wrote:
> On Sat, Jul 31, 2010 at 12:32:39PM -0400, Perry E. Metzger wrote:
> [...]
> > 3 Any security system that demands that users be "educated",
> > i.e. which requires that users make complicated security decisions
> > during the course
minor addenda about speeds & feeds concerning the example of mid-90s payment
protocol specification that had enormous PKI/certificate bloat ... and SSL.
The original SSL security was predicated on the user understanding the
relationship between the webserver they thought they were talking to, a
On Sat, Jul 31, 2010 at 12:32:39PM -0400, Perry E. Metzger wrote:
[...]
> 3 Any security system that demands that users be "educated",
> i.e. which requires that users make complicated security decisions
> during the course of routine work, is doomed to fail.
[...]
I would amend this to say "w
On 1/08/10 9:08 PM, Peter Gutmann wrote:
John Levine writes:
Geotrust, to pick the one I use, has a warranty of $10K on their cheap certs
and $150K on their green bar certs. Scroll down to the bottom of this page
where it says Protection Plan:
http://www.geotrust.com/resources/repository/leg
On 08/01/2010 04:08 PM, Anne & Lynn Wheeler wrote:
Old past thread interchange with members of that specification team
regarding the specification was (effectively) never intended to do
more than hide the transaction during transnmission:
http://www.garlic.com/~lynn/aepay7.htm#norep5 non-repudiat
On 08/01/2010 01:51 PM, Jeffrey I. Schiller wrote:
I remember them well. Indeed these protocols, presumably you are
talking about Secure Electronic Transactions (SET), were a major
improvement over SSL, but adoption was killed by not only failing the
give the merchants a break on the fraud surcha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/01/2010 09:31 AM, Anne & Lynn Wheeler wrote:
> Part of what was recognized by the x9a10 financial standard working
> group (and the resulting x9.59 financial standard) was that relying
> on the merchant (and/or the transaction processor) to provi
On Sun, 1 Aug 2010 15:07:46 +0200 Guus Sliepen
wrote:
> On Sun, Aug 01, 2010 at 11:20:51PM +1200, Peter Gutmann wrote:
>
> > >But, if you query an online database, how do you authenticate
> > >its answer? If you use a key for that or SSL certificate, I see
> > >a chicken-and-egg problem.
> >
> > W
On 07/31/2010 08:37 PM, Jeffrey I. Schiller wrote:
In general I agree with you, in particular when the task at hand is
authenticating individuals (or more to the point, Joe
Sixpack). However the use case of certificates for websites has worked
out pretty well (from a purely practical standpoint).
On Sun, Aug 01, 2010 at 11:20:51PM +1200, Peter Gutmann wrote:
> >But, if you query an online database, how do you authenticate its answer? If
> >you use a key for that or SSL certificate, I see a chicken-and-egg problem.
>
> What's your threat model?
My threat model is practice.
I assume Perry
Guus Sliepen writes:
>But, if you query an online database, how do you authenticate its answer? If
>you use a key for that or SSL certificate, I see a chicken-and-egg problem.
What's your threat model? At the moment if I get a key from a PGP keyserver
for a random contact I have no way of authe
John Levine writes:
>Geotrust, to pick the one I use, has a warranty of $10K on their cheap certs
>and $150K on their green bar certs. Scroll down to the bottom of this page
>where it says Protection Plan:
>
>http://www.geotrust.com/resources/repository/legal/
>
>It's not clear to me how much th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/31/2010 12:32 PM, Perry E. Metzger wrote:
> 1 If you can do an online check for the validity of a key, there is
> no need for a long-lived signed certificate, since you could
> simply ask a database in real time whether the holder of the key
On Sat, Jul 31, 2010 at 12:32:39PM -0400, Perry E. Metzger wrote:
> 5 Also related to 3, but important in its own right: to quote Ian
> Grigg:
>
> *** There should be one mode, and it should be secure. ***
6. Enrolment must be simple.
I didn't see anything about transitive trust. My rule
On 07/31/2010 01:30 PM, Guus Sliepen wrote:
But, if you query an online database, how do you authenticate its answer? If
you use a key for that or SSL certificate, I see a chicken-and-egg problem.
Part of what is now referred to as "electronic commerce" is a payment gateway that
sits between t
On Sat, 31 Jul 2010 19:30:06 +0200 Guus Sliepen
wrote:
> On Sat, Jul 31, 2010 at 12:32:39PM -0400, Perry E. Metzger wrote:
>
> > 1 If you can do an online check for the validity of a key, there
> > is no need for a long-lived signed certificate, since you could
> > simply ask a database in real t
On Sat, Jul 31, 2010 at 12:32:39PM -0400, Perry E. Metzger wrote:
> 1 If you can do an online check for the validity of a key, there is no
> need for a long-lived signed certificate, since you could simply ask
> a database in real time whether the holder of the key is authorized
> to perform
Usability engineering requires empathy. Isn't it interesting that nerds
built themselves a system, SSH, that mostly adheres to Perry's theses? We
nerds have empathy for ourselves. But when it comes to a system for other
people, we suddenly lose all empathy and design a system that ignores
Perry's t
"Perry E. Metzger" writes:
>Inspired by recent discussion, these are my theses, which I hereby nail upon
>the virtual church door:
Are we allowed to play peanut gallery for this?
>1 If you can do an online check for the validity of a key, there is no
> need for a long-lived signed certificate,
Nice theses. I'm looking forward to the other 94. The first one is a
nice summary of why DKIM might succeed in e-mail security where S/MIME
failed. (Succeed as in, people actually use it.)
>2 A third party attestation, e.g. any certificate issued by any modern
> CA, is worth exactly as much as
corollary to "security proportional to risk" is "parameterized risk management"
... where variety of technologies with varying integrity levels can co-exist within the same
infrastructure/framework. transactions exceeding particularly technology risk/integrity threshold
may still be approved gi
23 matches
Mail list logo
