James A. Donald" writes:
The key, and the hash of the key, is a long string of random
gibberish. It should not be visible to end users. Experience
demonstrates that showing it repels 99% of end users.
On 2013-03-06 9:33 PM, StealthMonger wrote:
Merchant includes its telephone number in ever
On Wed, Mar 6, 2013 at 6:33 AM, StealthMonger
wrote:
> ...
>
>> The key, and the hash of the key, is a long string of random
>> gibberish. It should not be visible to end users. Experience
>> demonstrates that showing it repels 99% of end users.
>
> Merchant includes its telephone number in ever
I don't think most non-programmers would differentiate between a string of hex
digits and an arbitrary alphanumeric string, so you might as well use base 32.
But do you really need to encode more bits? With a ZRTPish hash commitment /
key exchange / confirmation code structure you can detect a M
On 6/03/13 14:33 PM, StealthMonger wrote:
Your only argument is that the key ID is "longer" or more "random".
This of course is the ZT challenge. The issue isn't that Zooko's
Triangle can or can't be squared, but that we the developer have to
square it [0].
A
solution is redesign of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
"James A. Donald" writes:
> On 2013-03-06 4:41 AM, StealthMonger wrote:
>> 2. Prospective customer verification of merchant: Merchant includes
>> the ID of its signing key in every advertisement and repeatedly
>> admonishes prospects to "Accept No Su
On Wed, Mar 6, 2013 at 10:40 AM, James A. Donald wrote:
> Can you implement your above design while hiding the keys in urls, rather
> than inflicting them on the suffering user?
There's a saying in Estonian, literally translated: "who wants to eat
sausages is better off not knowing how sausages a
On 2013-03-06 4:41 AM, StealthMonger wrote:
What's wrong with the following simple idea:
1. p2p: The parties opportunistically verify out-of-band after
exchanging keys via public key servers or (insecure) email.
2. Prospective customer verification of merchant: Merchant includes
the ID of its s
On 2013-03-06 4:41 AM, StealthMonger wrote:
2. Prospective customer verification of merchant: Merchant includes
the ID of its signing key in every advertisement and repeatedly
admonishes prospects to "Accept No Substitutes".
The key, and the hash of the key, is a long string of random gibberish
On Tue, Mar 5, 2013 at 2:38 PM, James A. Donald wrote:
> On 2013-03-06 1:18 AM, Jeffrey Walton wrote:
>>
>> That's Patient 0. Its the key distribution problem. Its the cause of
>> all the troubles.
>>
>> Web of Trust, Hierarchy of Trust, DNSSEC/DANE, Sovereign Keys,
>> Convergence, {Certificate|Pu
On 2013-03-06 1:18 AM, Jeffrey Walton wrote:
That's Patient 0. Its the key distribution problem. Its the cause of
all the troubles.
Web of Trust, Hierarchy of Trust, DNSSEC/DANE, Sovereign Keys,
Convergence, {Certificate|Public Key} Pinning, Key Continuity, etc are
all band-aides for the first p
On 5 March 2013 18:41, StealthMonger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jeffrey Walton writes:
>
>> Its the key distribution problem. Its the cause of all the troubles.
>
> I don't understand. Please explain.
>
> What's wrong with the following simple idea:
>
> 1. p2p:
On Tue, Mar 5, 2013 at 1:41 PM, StealthMonger
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jeffrey Walton writes:
>
>> Its the key distribution problem. Its the cause of all the troubles.
>
> I don't understand. Please explain.
>
> What's wrong with the following simple idea:
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey Walton writes:
> Its the key distribution problem. Its the cause of all the troubles.
I don't understand. Please explain.
What's wrong with the following simple idea:
1. p2p: The parties opportunistically verify out-of-band after
exchangi
str...@riseup.net wrote:
Hi,
Can anyone enlighten me why client TLS certificates are used so rarely? It
used to be a hassle in the past, but now at least the major browsers offer
quite decent client cert support, and seeing how most people struggle with
passwords, I don't see why client certs co
On Tue, Mar 5, 2013 at 9:18 AM, Martin Paljak wrote:
> On Tue, Mar 5, 2013 at 2:08 PM, ianG wrote:
>> This whole argument that certs aren't portable across devices is something
>> of a strawman. Companies deploy SSL certs across accelerators all the time,
>> so why not client certs? The reason
On Tue, Mar 5, 2013 at 2:08 PM, ianG wrote:
> This whole argument that certs aren't portable across devices is something
> of a strawman. Companies deploy SSL certs across accelerators all the time,
> so why not client certs? The reason is the assumptions that are designed to
> stop you doing th
Hello,
On Mon, Mar 4, 2013 at 9:22 AM, wrote:
> Can anyone enlighten me why client TLS certificates are used so rarely? It
> used to be a hassle in the past, but now at least the major browsers offer
> quite decent client cert support, and seeing how most people struggle with
> passwords, I don'
On 5/03/13 03:26 AM, Joe St Sauver wrote:
Hi,
strife asked:
#Can anyone enlighten me why client TLS certificates are used so rarely? It
#used to be a hassle in the past, but now at least the major browsers offer
#quite decent client cert support,
Not quite seeing eye-to-eye with you on the "qu
Hi,
strife asked:
#Can anyone enlighten me why client TLS certificates are used so rarely? It
#used to be a hassle in the past, but now at least the major browsers offer
#quite decent client cert support,
Not quite seeing eye-to-eye with you on the "quite decent client cert
support" point, I'm
On Sun, Mar 3, 2013 at 11:22 PM, wrote:
> Hi,
>
> Can anyone enlighten me why client TLS certificates are used so rarely? It
> used to be a hassle in the past, but now at least the major browsers offer
> quite decent client cert support, and seeing how most people struggle with
> passwords, I don
On 03/04/2013 11:15 PM, Open eSignForms wrote:
Step 10 will make it impossible for you mom. ;-)
10. You write your message, sign it with your private key, encrypt
it with your public key and deliver the ciphertext to
https://guidos-secure-mail.com/deliver?to=StealthMongersMom&ciph
On 03/04/2013 06:10 PM, StealthMonger wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
Peter Gutmann writes:
... sit behind her with your arms crossed so you can't point to
anything or type stuff out for her, and walk her through the process
of acquiring and using one without leaving
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Gutmann writes:
> writes:
>>Can anyone enlighten me why client TLS certificates are used so
>>rarely? It used to be a hassle in the past
> They're still a huge pain to work with, and probably always will be.
> If you don't believe me, go to
With respect to:
>...
> - repudiation: there is no way deny writing a message; leading to self
> censoring.
>
> In other words, everything I sign with my Thawte client certificate is
> tied to my identity *for life*. That's why I don't use that thing. In
> fact, I've long since lost the priva
On 03/04/2013 08:22 AM, str...@riseup.net wrote:
Hi,
Can anyone enlighten me why client TLS certificates are used so rarely? It
used to be a hassle in the past, but now at least the major browsers offer
quite decent client cert support, and seeing how most people struggle with
passwords, I don't
writes:
>Can anyone enlighten me why client TLS certificates are used so rarely? It
>used to be a hassle in the past
They're still a huge pain to work with, and probably always will be. If you
don't believe me, go to your mother, sit her in front of a computer, sit
behind her with your arms cro
On 4/03/13 10:22 AM, str...@riseup.net wrote:
Hi,
Can anyone enlighten me why client TLS certificates are used so rarely?
My thoughts only, not authoritative.
The big answer today is momentum, I would say.
In the past, I would say that forces were deployed against TLS
certificates. The CA
Hi,
Can anyone enlighten me why client TLS certificates are used so rarely? It
used to be a hassle in the past, but now at least the major browsers offer
quite decent client cert support, and seeing how most people struggle with
passwords, I don't see why client certs could not be beneficial even
28 matches
Mail list logo
