Frank Hecker wrote, On 2009-02-19 06:26: > Jean-Marc Desperrier wrote: >> The content of the IssuingDistributionPoint is in fact perfectly >> correct, pointing to >> http://crl1.hongkongpost.gov.hk/crl/eCertCA1CRL2.crl just like does the >> cRLDistributionPoints in the cert itself. > > Thank you for clarifying this. I'd like to get a final clarification > from you, Nelson, or someone else: > > According to comments here and in the bug, Hongkong Post apparently > issues full CRLs as well as partitioned CRLs. Am I right that someone > who wished to check revocation status on EE certs in Firefox could just > download the full CRL and use that? (In other words, if we were to > include the Hongkong Post root in NSS then there's no possibility of NSS > throwing errors unless someone tries to use the partitioned CRLs.)
I understand your question to be relating the way FF works today, and NOT to the way it will/might work when CrlDP extension processing causes automatic CRL fetches. With that in mind... Yes, if a user possesses (or can find) the URL from which to download a full CRL, then as long as the CRL served from that URL remains a full CRL, (It's allowed to change, BTW) the user could manually download that CRL and it should work OK for him without any errors ... at least until CrlDP processing happens, and maybe even after that. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
