JH> On 30/09/14 03:30, Michael Sierchio wrote:
>> There are many places where a PKI breaks - hash collisions are far
>> down the list. Most internal CA implementations offer no more
>> effective security or trust than just using self-signed certs - the
>> objective seeming to be to make browsers
On 30/09/14 03:30, Michael Sierchio wrote:
> There are many places where a PKI breaks - hash collisions are far
> down the list. Most internal CA implementations offer no more
> effective security or trust than just using self-signed certs - the
> objective seeming to be to make browsers not compla
Out of general interest,
Assuming a "low e" (such as e=65537) RSA public key, how big is the
cost of going from a 2048 bit to a 4096 bit modulus for an
intermediary CA, given that verifications will significantly
outnumber signings for a CA key?
On 29/09/2014 09:26, Kyle Hamilton wrote:
Generall
> There are many places where a PKI breaks - hash collisions are far down the
> list.
What he said.
4KRSA -SHA-256 is fine for a CA. Most likely operational issues will cause you
problems. Invest in an HSM.
--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: Ric
On Sun, Sep 28, 2014 at 11:59 PM, Jason Haar wrote:
> ...
> If I just "click through" the defaults of "openssl ca", I'd probably end
> up with a 2048bit RSA, SHA-2 (256) cert. So my question is, should I
> future proof that by making it 4096bit and maybe SHA-2 (512)? (ie I want
> the CA to be via
Generally, a client doesn't bother checking a certificate that's in its local
trust store. The idea is, if it's in its trusted store, there's no need to
verify its integrity, because the administrator already performed that
verification.
Where this might have an impact is if your new certificat
