Nelson B Bolyard wrote:
1. As you may know, the EV spec says that a client should not give a
cert the full EV treatment unless/until it has done some successful
revocation check (CRL or OCSP, this year) at least on the EE cert.
Beginning with FF 3.1 (IINM) FF will enforce that rule. This will
mean that certs whose revocation cannot be checked may be OK for non-EV
SSL but won't be recognized as EV certs.
Yes, I should have mentioned this: My comments were with reference to
the non-EV case; IIRC Hongkong Post is not asking for EV treatment. If
and when Hongkong Post does ask for EV treatment then it's going to have
to support some mechanism by which Firefox et.al. can do revocation
checking without manual loading of CRLs.
2. FF has a periodic CRL fetcher that historically has fetched no CRLs
until the user loads the first one, and requests that FF automatically
fetch additional ones from the same thereafter. Work is underway to
pre-load FF 3.1's periodic CRL fetcher with the URLs of the EV CAs who
use only CRLs, so that FF 3.1 will attempt to fetch them, as if the user
had manually downloaded those CRLs. Details are still being worked out.
See https://bugzilla.mozilla.org/show_bug.cgi?id=477244 and the other
bugs to which it links.
Yes, I'm familar with this.
A note for representatives of Hongkong Post: What's being implemented in
bug 477244 is a temporary measure only. If you want to support EV
certificates then I recommend that you support OCSP for revocation
checking of those certificates.
This might be OK if the HK Post's certs listed both partitioned and full
CRLs in the cert's CDP extension, because the automatic CDP-based fetcher
would eventually fetch a full CRL, and then cache it. But as long as the
HK Post certs list ONLY the partial CRL, it's a pain.
For Hongkong Post: I think the suggestion to include URLs for both the
full and partial CRLs in your CRL DP extension is a good one. You could
do this for new certificates issued in the future.
For Nelson: What would be the recommended behavior of NSS for
certificates that have two different HTTP URLs in the CRL DP extension?
Would it just try to fetch each CRL in turn until it found one it liked?
(Obviously it couldn't tell in advance which was the full CRL and which
the partial.)
I have some more thoughts which I'll post as a followup to your earlier
post about RFC 5280.
I'm looking forward to reading your comments on this. As I wrote, I
don't yet fully understand this particular section of RFC 5280.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
