lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: security at brvenik.com (Jason)
Subject: PGP vs. certificate from Verisign


Steve Poirot wrote:
> I'm 98% sure that the key pair is generated on the client machine and 
> that just the public key is transmitted to the CA.  The reason I say 98% 
> instead of 100% is that it's possible that a CA just makes it look like 
> that's what's happening.  This could be verified by sniffing the session. 
> Steve Poirot
> 

It is not possible when properly implemented for the CA to make it look 
like you generated your private key when it ( the CA ) actually did, the 
resulting certificate would not validate against your previously 
generated keypair. In the case of an implementation faulire you would 
have to verify this... which is what you should _always_ do with 
_proper_ certificates since they can be legally binding. I know this to 
be the case in the US and Europe at least.

There have been cases however where it is possible to cause a 
certificate to look like a trusted issuing authority after import when 
it should have been an end entity, this would allow for inferred trust 
without a warning but that is for a different time...



[snip]


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ