Ian,
Ian G wrote:
Is there any reason why the message cannot be delivered by the
current channels? CRL, OCSP?
Yes, there is one : the fact that trust anchors are specifically
excluded from CRL and OCSP revocation checking in PKIX standards.
In other words, no PKIX-compliant software, including but not limited to
NSS, is ever going to try to look for CRLs or check OCSP revocation
status for a root.
Leaving aside the standards question,
that is...
I don't think we can leave it out . That is the core issue.
Is a self-reference in a CRL or OCSP:
defined? Banned? Undefined? Going to cause chaos?
Undefined.
(Where, Chaos is defined as making matters worse for the software
that otherwise has to deal with a rogue root out in the wild serving
up the devil's contract every 3rd packet to grandma...)
That would completely depend on how you are making that special CRL
available.
Most likely, NSS/PSM, would never even obtain it, so it would not do
anything at all.
It would seem that, if the root list is delivered by party A, and
the software is written by party A, and the revocation is
distributed to software of party A, then it should all tie together.
And it could - party A can deliver a revised root list.
Updating software with a new root module is a lot simpler. Of course
that process has its own set of security issues as well.
Hey, if it's good enough for Debian ... ;)
I don't have any what Debian does, but I would prefer we don't stray too
much off topic. We could talk about the Mozilla clients update process,
but that would deserve at least its own thread here. And I have no
involvement with it, nor much of the NSS team.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
