> How about the subject key ID? Did it change?
No, it didn't. The key and SKI stayed the same.
...
> New Mozilla browsers released after this date do not and will not have the
> problem you described above. So, it should not be necessary to retain the
> MD2 certs in the root list for these new
> How about the subject key ID? Did it change?
No, it didn't. The key and SKI stayed the same.
...
> New Mozilla browsers released after this date do not and will not have the
> problem you described above. So, it should not be necessary to retain the
> MD2 certs in the root list for these new
> How about the subject key ID? Did it change?
No, it didn't. The key and SKI stayed the same.
...
> New Mozilla browsers released after this date do not and will not have the
> problem you described above. So, it should not be necessary to retain the
> MD2 certs in the root list for these new
On 2009-05-29 09:22 PDT, Rick Andrews wrote:
> On May 28, 3:12 pm, Nelson B Bolyard wrote:
>> On 2009-05-28 10:52 PDT, Kathleen Wilson wrote:
>>
>>> Just to make sure I understand…
>>> In the VeriSign case the MD2 roots expire on 2028-08-01, and the SHA1
>>> roots expire on 2028-08-02, so the SHA1
On May 28, 3:12 pm, Nelson B Bolyard wrote:
> On 2009-05-28 10:52 PDT, Kathleen Wilson wrote:
>
> > Just to make sure I understand…
>
> > In the VeriSign case the MD2 roots expire on 2028-08-01, and the SHA1
> > roots expire on 2028-08-02, so the SHA1 roots would take precedence in
> > NSS. There
On 2009-05-28 13:09 PDT, Frank Hecker wrote:
> Nelson B Bolyard wrote:
>> An SSL server that sends out a full chain with a SHA256 root could
>> conceivably cause a problem for a remote SSL client that does not understand
>> SHA256 signatures and that chooses to check the signature on the received
>
Frank Hecker wrote:
Nelson B Bolyard wrote:
However, Izenpe may want to consider only including the SHA1 root
because many of their customers may be using operating systems that
don’t yet support SHA256.
I think that covers all the considerations that would go into a decision
of whether to in
Nelson B Bolyard wrote:
However, Izenpe may want to consider only including the SHA1 root
because many of their customers may be using operating systems that
don’t yet support SHA256.
I think that covers all the considerations that would go into a decision
of whether to include only a SHA1-bas
Nelson B Bolyard wrote:
An SSL server that sends out a full chain with a SHA256 root could
conceivably cause a problem for a remote SSL client that does not understand
SHA256 signatures and that chooses to check the signature on the received
root cert rather than, or in addition to, relying on it
On 2009-05-28 10:52 PDT, Kathleen Wilson wrote:
> Just to make sure I understand…
>
> In the VeriSign case the MD2 roots expire on 2028-08-01, and the SHA1
> roots expire on 2028-08-02, so the SHA1 roots would take precedence in
> NSS. Therefore, there is no benefit in keeping the MD2 roots, and
Just to make sure I understand…
In the VeriSign case the MD2 roots expire on 2028-08-01, and the SHA1
roots expire on 2028-08-02, so the SHA1 roots would take precedence in
NSS. Therefore, there is no benefit in keeping the MD2 roots, and the
MD2 roots should be removed when the SHA1 roots are ad
Nelson B Bolyard wrote re retaining copies of old roots after their
replacement by new roots:
I recommend that for CAs whose newer root certs bear exactly the same
notBefore and notAfter dates as the older certs. In that case, it may be
necessary to retain all the relevant root certs, all marked
Rob Stradling wrote, On 2009-05-27 01:35:
> Frank, Nelson, just in case it's useful...
> I recall that GlobalSign recently refreshed their "GlobalSign Root CA":
> https://bugzilla.mozilla.org/show_bug.cgi?id=406794
>
> When the new GlobalSign Root CA certificate (which expires in 2028) was added
(Sorry for the apparent tardiness of this reply. I wrote it the day that
I read Frank's message, and thought I sent it, but evidently did not send
it until today.)
Frank Hecker wrote, On 2009-05-22 07:24 PDT:
> So, just to clarify: I *think* you're proposing that we do the following
> in cases w
Frank, Nelson, just in case it's useful...
I recall that GlobalSign recently refreshed their "GlobalSign Root CA":
https://bugzilla.mozilla.org/show_bug.cgi?id=406794
When the new GlobalSign Root CA certificate (which expires in 2028) was added
to NSS, the old certificate (which expires in 2014)
Nelson Bolyard wrote:
On 2009-05-20 13:58, Kathleen Wilson wrote:
When processing a cert chain, does Mozilla use a specified algorithm/
order for determining which root to use when there are two roots
included that are identical except for signature algorithm and serial
number?
The algorithm f
Eddy Nigg wrote, On 2009-05-21 15:15:
> On 05/21/2009 03:46 AM, Nelson Bolyard:
>>> Also related, in bug #490895 VeriSign has requested inclusion of the
>>> SHA-1 version of their roots to replace the corresponding old MD5
>>> version of their roots. At the time of inclusion of the SHA-1 version
>>
On 05/21/2009 03:46 AM, Nelson Bolyard:
Also related, in bug #490895 VeriSign has requested inclusion of the
SHA-1 version of their roots to replace the corresponding old MD5
version of their roots. At the time of inclusion of the SHA-1 version
of the roots, is there any reason to keep the old
On 2009-05-20 13:58, Kathleen Wilson wrote:
When processing a cert chain, does Mozilla use a specified algorithm/
order for determining which root to use when there are two roots
included that are identical except for signature algorithm and serial
number?
The algorithm for choosing from among
Certificate-chain validation, primarily, works based on the Subject
Key Identifier and the Authority Key Identifier extensions. When
validation code is presented with multiple certificates that have
the same AKIs in the chain, a good programmer will attempt to use
the stronger certificate if it c
20 matches
Mail list logo
