(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 where CAs issue new root certificates with stronger signature > algorithms (e.g., upgrading MD2 or MD5 roots to use SHA-1): > > 1. We should keep the old root certificates in the root list, at least > for now. Rationale: It does no harm to keep the old roots, since we do > not check signatures on roots, and it may prevent possible errors when > Firefox, Thunderbird, etc., receive a full cert chain that includes the > old root. 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 trusted. However, for the more common case where the newer cert does not have identical notBefore and notAfter dates, but has either a) a newer/later notBefore date, or b) the same notBefore date and a newer/later notAfter date, it is not necessary to retain the older certs. > 2. We should encourage CAs to issue the new replacement roots with > notBefore and notAfter dates that are later than the corresponding dates > for the old roots. Rationale: This ensures that NSS will > deterministically select the newer root in cases where there is a choice > to be made. Yes. I'd recommend a newer notAfter date, even if it only differs from the previous notAfter date by no more than a single second. > (Does this include the case when Firefox, etc., receive a > full cert chain that includes the old root?) Yes. Note: above, where I said "date" or "dates", I meant the entire date/time value, including the time as well as the date. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
