Re: [cryptography] PKI in practice: is there a list of (widely deployed) client-certs-issuing CAs?

2012-05-01 Thread Martin Paljak
On Sat, Apr 28, 2012 at 05:25, ianG i...@iang.org wrote:

 Well, to the extent above.  My db has a table for all certs, and a table for
 all users, with a join by cert identifiers between the two tables.
I hope you actually bind the actual public key instead of any kind of
identifiers?

Or would that not be against the single principle of an enduser
controlling a private key, in which case the normal CA guarantee of
a unique identifier (serial) under a given CA (which, in practice,
should be out of picture) ?

Martin
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Symantec/Verisign DV certs issued with excessive validity period of 6 years

2012-05-01 Thread James A. Donald

On 2012-05-02 12:23 AM, Peter Gutmann wrote:

Thor Lancelot Simont...@panix.com  writes:


NIST says 2048 bit RSA keys should have a 3 year lifetime.  Who here really
wants to explain to customers (or investors!) that he willfully ignored that
recommendation and just reused the same old key when making the CSR for that
new certificate?


This is standard practice in a significant chunk of the industry, to the
extent that renew a certificate means get the same key recertified.  You
don't wilfully ignore NIST recommendations, you click on renew
certificate.  Dealing with cert rollover is painful enough already without
having to try and find PKI documents you've never heard of telling you what to
do.



That certs are painful, means they will be done wrong.

Despite numerous assurances that certs are easy, and I must be a 
complete idiot to find them difficult, I have never found them easy, and 
I have been the certificate guy in various companies because every 
single other person in the company found them more difficult than I did.


Rather than having an elaborate and disfunctional certificate revocation 
system, if certificates are needed, what is needed is a system where 
certificates have an expiry time of a week or so, and a new key is auto 
generated and certified every week or so if humans do nothing about it 
and know nothing about it.


Of course, attempting to implement such a system immediately brings us 
to the fact that the certifying authority does not know the people it is 
certifying, nor what it is certifying, which is why certification is 
difficult.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


Re: [cryptography] Symantec/Verisign DV certs issued with excessive validity period of 6 years

2012-05-01 Thread Nico Williams
The idea of using fresh certs (not necessarily short-lived) came up in
the TLS WG list in the context of the OCSP multi-stapling proposal.

So far the most important objection to fresh-lived certs was that it
exacerbates clock synchronization issues, but I'm willing to live with
that.  Short-lived certs would be much easier to implement than OCSP
multi-stapling.

Nico
--
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography