On Thu, Apr 26, 2012 at 12:22 AM, Nico Williams wrote:
> Also,
>
> On Wed, Apr 25, 2012 at 10:11 PM, Zooko Wilcox-O'Hearn
> wrote:
[big snip]
>> I don't question the usefulness of the Authenticated Encryption
>> abstraction for protocols that fall into that category.
>
> Right, me either. I c
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
On 2012-05-02 12:23 AM, Peter Gutmann wrote:
Thor Lancelot Simon 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
On Sat, Apr 28, 2012 at 05:25, ianG 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 a
>So does the expiry period actually matter that much? Intuitively yes,
>rationally, no.
That's a point that I've made as well in the past:
Having said that, the idea that a short certificate lifetime is better seems
to be accepted more as an article of faith than as a product of any real
a
On Wed, May 02, 2012 at 02:23:47AM +1200, Peter Gutmann wrote:
> Thor Lancelot Simon 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
Thor Lancelot Simon 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
