Nelson B Bolyard wrote:
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.
Yes, that's correct. My question was with respect to the current
situation, i.e., if we were to approve inclusion of the Hongkong Post
root now and include it in a near-term version of Firefox.
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.
OK, thanks. Now that we know that manually loading the full CRL for
Hongkong Post will work, my next priority is getting more clarification
on what either we or Hongkong Post (or both of us together) can do to
forestall any problems in the future. (It would be lamentable if we
included the Hongkong Post root and then users started getting errors in
the future when NSS and Firefox are upgraded to support new CRL-related
features.)
Here is my current understanding; please correct or confirm my
understanding as appropriate:
* Hongkong Post-issued end entity certs include a cRLDistributionPoints
extension that references the URL
http://crl1.hongkongpost.gov.hk/crl/eCertCA1CRL2.crl
* The CRL located at this URL is a partitioned CRL that has an
issuingDistributionPoint extension flagged as critical. Because NSS does
not recognize the CRL IDP extension and the extension is marked as
critical, NSS throws an error when a user attempts to manually load the
CRL. This error presumably would also occur in future if NSS attempted
to automatically fetch and process the CRL (i.e., as part of CRL DP
support), unless NSS were changed to either implement the necessary IDP
support or otherwise handle this case without error (see below).
* Hongkong Post also maintains a full CRL located at the URL
http://crl1.hongkongpost.gov.hk/crl/eCertCA1CRL1.crl
This CRL works correctly when manually loaded into Firefox today. It
would also presumably work correctly in a future version of NSS with CRL
DP support, if the URL for the full CRL were referenced in the CRL DP
extension in the end entity certs.
* At present plans are for CRL DP support to be implemented in NSS
(i.e., auto-fetching and processing of CRLs identified in the CRL DP
extension), but not support for partitioned CRLs using the CRL IDP
extension.
Given the above, here's my take on possible options for how to handle
this situation in future (i.e., once CRL DP support gets implemented in
NSS).
Option 1: Hongkong Post makes no changes to end entity certs, but
removes the CRL IDP extension from the CRL at the URL referenced in the
CRL DP extension. In this option Hongkong Post puts a full CRL at
http://crl1.hongkongpost.gov.hk/crl/eCertCA1CRL2.crl
instead of a partitioned CRL. Once CRP DP support is implemented in NSS
then NSS will auto-fetch the CRL and should process it normally.
Option 2: Hongkong Post re-issues all end entity certs with a different
URL in the CRL DP extension. In this option Hongkong Post changes the
CRL DP extension in all end entity certs to refer to the URL for the
full CRL
http://crl1.hongkongpost.gov.hk/crl/eCertCA1CRL1.crl
instead of the URL for the partioned CRL. Again, NSS with CRL DP support
would fetch this full CRL and should process it without problems.
Option 3: Hongkong Post re-issues all end entity certificates to include
two URLs, one for the full CRL and one for the partitioned CRL. NSS
would then have to fetch the CRLs at both URLs, recognize that it
couldn't use the partitioned CRL with the IDP extension, and instead use
the full CRL. This behavior, if implemented, would seem to be consistent
with RFC 5280 as discussed below.
Option 4: Hongkong Post makes no changes to either its CRLs or its end
entity certs, and NSS ignores partitioned CRLs encountered in CRL DP
processing. In this option Hongkong Post would make no changes
whatsoever to its current practices. NSS would fetch the partitioned CRL
located at the URL referenced in the CRL DP extension, find that it had
a CRL IDP extension marked as critical, and then simply ignore the CRL,
treating the revocation status of the certificate as unknown.
Here I'm following RFC 5280, section 5.2.5 ("Issuing Distribution
Point"): "... implementations that do not support this extension MUST
either treat the status of any certificate not listed on this CRL as
unknown or locate another CRL that does not contain any unrecognized
critical extensions." As I read it, this allows NSS to not throw an
error but instead to simply act as if no CRL were present -- in other
words, as would happen today by default in the absence of CRL DP support.
An additional twist is if the user had previously manually loaded the
full CRL. My reading of RFC 5280 is that NSS could use that CRL in
preference to the CRL identified in the CRP DP extension -- i.e., in
this case NSS is able to "locate another CRL that does not contain any
unrecognized critical extensions". This would let "power users" to
enable revocation checking (just as they can do today) even if typical
users don't get this benefit.
From my point of view option #3 is the most preferred option, but
option #4 would be acceptable: It would ensure that typical users would
not see any errors, and that power users could still enable revocation
checking by loading the full CRL manually -- in other words, it would
maintain the same situation we're in now in the absence of CRL DP
support in NSS.
Your thoughts?
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
