On Wednesday 24 September 2008 01:30:15 Paul Hoffman wrote:
> At 4:23 PM -0700 9/23/08, Nelson B Bolyard wrote:
> >There also products today that cannot handle SHA-2 hashes, and that limit
> >RSA key/signature sizes to 2k bits. I would not advise any CA to limit
> >itself to those limits just for
David B Hinz wrote:
>Some of the client applications are written in C++ using the Mozilla
>LDAP 6.0.2 C API. Other client applications are written in Java using
>Mozilla LDAP JDK 4.17 and JSS 3.4 (we have just upgraded to JSS 4.25).
Mozilla's LDAP JDK does not support client authenti
At 4:59 PM -0700 9/23/08, Nelson B Bolyard wrote:
>In finality, you have to pick a table from someone you believe has done a
>really good job of analyzing it.
Right.
>Given that NIST's tables are the basis
>for the US Government's protection of its own secrets, which it guards
>jealously, I'm inc
At 4:23 PM -0700 9/23/08, Nelson B Bolyard wrote:
>Paul Hoffman wrote:
>> At 2:29 PM -0700 9/22/08, Nelson B Bolyard wrote:
>
>>> In CA certs, NSS understands the EKUs to mean "this CA can only issue
>>> certs valid for these purposes", rather than meaning that the CA cert
>>> itself can be use
Ian G wrote:
> Nelson B Bolyard wrote:
> The curiosity here is that the Certificate Policies extension may
> not be shown prominently by software. As the point of the cert is
> to make some claim to the user, and the essence of that claim is
> somehow pertinent to the user's choice, it is underst
Paul Hoffman wrote:
> At 2:29 PM -0700 9/22/08, Nelson B Bolyard wrote:
>> In CA certs, NSS understands the EKUs to mean "this CA can only issue
>> certs valid for these purposes", rather than meaning that the CA cert
>> itself can be used for those purposes.
>
> I would argue that that interpret
(Sorry, missed this before sending my last message.)
At 8:11 PM +0200 9/23/08, Ian G wrote:
>But, either way, the general result seems to be: a top level root
>should not generally include an(y) EKU.
Correct. That follows from the RFC.
>OK. That looks mostly for the EE certs, so I guess there
At 2:29 PM -0700 9/22/08, Nelson B Bolyard wrote:
>Ian G wrote, On 2008-09-22 09:45:
>> Hi all,
>
>Hi Ian,
>This reply isn't complete. I'm just going to discuss the questions with
>easy answers.
>
>> * the following extended key usage fields within roots:
>> + Server Authentication
>>
* Nelson B. Bolyard:
>> * expiry should be?
>> + minimum 8 years?
>> + maximum 30 years?
>
> In that same NIST publication there is a table of recommended key sizes
> to use for secrets that need to be protected until year 2010, 2030, and
> beyond. It's table 4, page 66.
I think they re
Nelson B Bolyard wrote:
> Ian G wrote, On 2008-09-22 09:45:
>> Hi all,
>
> Hi Ian,
> This reply isn't complete. I'm just going to discuss the questions with
> easy answers.
Thanks! This has cleared up a few of my questions at least. For
what it is worth, I have knocked up a starter set of not
10 matches
Mail list logo
