Hi,
> Oh, now it makes sense, those are mostly router certs (and various other certs
> from vendors who create broken certs like the Plesk ones). You won't just
> find them in Korea, they're everywhere, in vast numbers, but (at least for the
> router certs) they're usually only visible from the L
Hi,
Sorry, but this is too good. This is the Bavarian tax office, and ELSTER
is the government's tax software:
C=DE, ST=Bayern, L=Muenchen, O=Bayerisches Landesamt fuer Steuern -
Dienststelle Muenchen, OU=ELSTER, CN=Elster HTTPS-Client, 41
I seem to live in the country of offenders.
Ralph
--
D
ianG writes:
>C.f., revocation is broken. The disablement of OCSP checking has been ...
>e widely suggested.
>
>Which leads to a curious puzzler; if it doesn't work for users, who does it
>work for? Ah, the cynicism :P
There are a number of revocation vendors who have (or had, a few years
On 22/09/11 09:37 AM, James A. Donald wrote:
On 2011-09-22 8:20 AM, Joe St Sauver wrote:
Understood that would be the "zipless" ideal, but how would the binding
of the private/public keypair to the email address occur then, eh?
Well, it wouldn't, in those terms, you need to unwrap the judo fli
Hi Arshad,
It occurs to me that we're almost there.
On 22/09/11 02:30 AM, Arshad Noor wrote:
Thirdly, lets assume that the compromised CA has *explicitly* entered
into a cross-certification agreement with one or more other TTP CAs.
Right, they got themselves listed by the browsers, who hid t
On Thu, Sep 22, 2011 at 09:37:42AM +1000, James A. Donald wrote:
> Email client generates private/public keypair. Sends public key to CA
> server. CA server certifies that the owner of the private key
> corresponding to this public key is capable of receiving email at the
> address, emails certi
On Thu, Sep 22, 2011 at 1:32 AM, Chris Palmer wrote:
> On Sep 21, 2011, at 10:11 PM, M.R. wrote:
>
>>> Please look into how code signing on Android works and what it means.
>
>> A quick summary would be appreciated, especially on the "meaning" part.
>
> Google: [ android code signing ]
>
> http://
Let's be honest, without any methamatical/design/architectural
assumptions, about the current PKI practical context. One of the
weakest links of PKI is trust delegation to some sort of governement
based legislated system. As said, somewhere on this maling list, CA's
are companies in those same legi
Ben Laurie writes:
>Well, don't tease. How?
The link I've posted before (but didn't want to keep spamming to the list):
http://www.cs.auckland.ac.nz/~pgut001/pubs/pki_risk.pdf
Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lis
Hi,
> study this more carefully and sooner as possible. SSL Observatory from
> EFF is a step forward but we need more.
Their distributed observatory is probably going to help much here, but I
can offer the data sets from our paper. I'll put the paper online
tomorrow and paste the link here.
> 1
The way you position yourself in the network infra-structure is of
very importance when doing data collection.
Users of a given ISP may have rogue certificates while others at the
same country but another ISP may not. We as researchers need to
position ourselves at different network scopes in orde
On Sun, Sep 18, 2011 at 11:22 AM, M.R. wrote:
> On 18/09/11 10:31, Ian G wrote:
>>> On the other hand, a perfectly adequate low-level retail
>>> transaction security system can best be achieved by using a
>>> trusted-third-party, SSL-like system.
>>
>> That's a marketing claim. Best ignored in any
On Thu, Sep 22, 2011 at 09:37:42AM +1000, James A. Donald wrote:
Email client generates private/public keypair. Sends public key to CA
server. CA server certifies that the owner of the private key
corresponding to this public key is capable of receiving email at the
address, emails certificate
On Thu, Sep 22, 2011 at 09:37:42AM +1000, James A. Donald wrote:
Email client generates private/public keypair. Sends public key to CA
server. CA server certifies that the owner of the private key
corresponding to this public key is capable of receiving email at the
address, emails certificate
On 2011-09-23 8:33 AM, Nico Williams wrote:
In your view then, is the alternative at all a public key based
crypto system? If yes, is it SSH (or SSH-like) "trust on first
contact" or something else?
In order to shop, one needs a third party mediating transactions
*THEY* should issue certificat
15 matches
Mail list logo
