Ian,
Ian G wrote:
The part means that the new CRL could de-include the root, thus
un-revoking it. So we would need:
* a root revocation is to be cached and not replaced.
Which is something completely foreign to any PKIX standards today. There
is no persistence of any revocation information. Most software does not
even have it, certainly not for OCSP, and even CRLs are often fetched
into RAM only and then discarded when the software exits.
The PKIX standards explicitly require that current revocation always be
retrievable at any time for unexpired certificates. I think that's a
very reasonable requirement.
What about the case where somebody installs old software that contains a
revoked root ? How does he get the suicide note ?
If you are going to define suicide notes, you will have to ensure that
somebody is keeping track of all of them, and that software can get to
them again at any time.
How do we revoke Mozilla's root?
By updating mozilla software :)
How does the CRL / OCSP get delivered / run? Are we now asking each
certificate check to also chain up and check two or more OCSPs?
Can we eliminate the whole CA notion by just using a single sig over
the list from a "root" ... and just deliver signed updates?
Have you read RFC3280 ?
But if that is the case, then you don't need the cert, just the key,
because you can get all the content info in the online revocation
checkup.
Wrong. Multiple certs can use the same public key in X509, and
frequently do, especially in cases of cross-certification.
Thus you cannot retrieve everything else just from the key.
Also, even if it could be done, it would be much more of a strain on the
network to retrieve the whole cert content than just sending the serial
number and obtaining a status code + revocation reason as OCSP does.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
