Nelson B Bolyard wrote:
Frank Hecker wrote, On 2009-02-20 16:53:
<snip>
"However, 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." [emphasis added]
That is a rather strange statement, IMO.
I thought this was weird, and am glad someone more knowledgeable than I
agrees. Thanks for the detailed explanation.
Now, imagine with me that some short time down the road, because of some
new attack, we conclude that it's no longer safe to treat non-EV SSL server
certs as OK by default in the absence of revocation information that
affirmatively identifies the cert as unrevoked.
If that were the case prior to CRL DP support being implemented then
that would cause a problem for every non-EV CA not supporting OCSP.
Assuming CRL DP support were implemented by that point then it would
cause a problem for every CA that didn't include a CRL DP extension in
EE certs at all (are there any of these in our root list?), or for whom
the CRL DP extension referenced (only) a partial CRL.
It would force a choice
of either implementing full support for partial CRLs or (effectively)
distrusting HK Post's certs. I think that's a high price to pay. Is the
ability to support HK Post's certs worth all that investment?
We can certainly take the position that if we did need to force
revocation by default (which I think would require implementation of CRL
DP support as a prerequisite) and revocation checking of Hongkong Post
certificates could not be done by default (because their CRL DP
extension referenced only a partial CRL), then Firefox et.al. are going
to throw errors on Hongkong Post-issued SSL certs (and not display the
associated sites) until/unless Hongkong Post re-issues the certs with a
CRL DP extension referencing a full CRL.
This is really up to Hongkong Post: Would they rather have their root
cert included now, knowing that certs they issue may stop working in
future, or would they rather wait to have the root included until such
time as either we implement CIDP support or they reissue all their certs
to include a URL for a full CRL? They can start adding the URL for the
full CRL to the CRL DP extension (along with the URL for the partial
URL) when issuing new certs, and this would minimize the likelihood of
their certs causing problems in future.
To sum up:
1. Hongkong Post is not doing anything today contrary to our policy:
Their certs work as is in Firefox et.al., by default, and people who
want revocation checking can import the full CRL to enable it. In this
respect they're no different than any other non-EV CA not supporting OCSP.
2. We can imagine a scenario in which Hongkong Post-issued certificates
could cause technical problems. However at this point this is merely a
hypothetical scenario; we have no idea whether it will come to pass or not.
3. If the hypothetical scenario were to come to pass, we don't need to
do anything ourselves to fix the problem. Hongkong Post could fix the
problem itself, by reissuing certs with the URL for the full CRL
included. (Or even more simply, it could simply publish the full CRL at
the URL previously used for the partial CRL.) I think Hongkong Post
would be strongly motivated to fix the problem one way or the other.
So I don't think including the Hongkong Post root would cause problems
for either us or our users. It would just mean that Hongkong Post will
need to do some work of its own in order to minimize chances of its
certs having problems in future.
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
