On 31-07-2013 19:56, Salz, Rich wrote:
This is not possible according to PKIX. RFC5280 states "The trust anchor for the
certification path [of the crl] MUST be the same as the trust anchor used to validate the
target certificate."
The root certificate creates a crl-signing cert. The root certificate includes
a cRLDistributionPoint that names that crl-signing cert, and has cACompromise
in its ReasonFlags.
Wouldn't it be just as good to have a cRLDistributionPoint which does
not restrict the available ReasonFlags and then put "cACompromise" in
the CRL if/when that disaster happens?
Wouldn't it be equally good to use the same crl-signing cert already
used for the regular CRL of revoked next-level certs?
Would it be possible to use the same CRL and cRLDistributionPoint
for both child certs and self-revocation (abdication)?
Would it be possible to use the above techniques without a separate
crl-signing cert?
The crl-signing cert immediately issues an empty CRL. Whenever you give someone
the CA cert, you give them the crl cert, and the empty CRL as well. The
relying party now has the key that will sign the CRL, and a signed piece of
data using that key.
This is more theory than practice -- how many angels can dance on the head of a pin? -- but it does
securely give you a way to be sure that you only trust a "proper" root revocation.
Whether or not that is something to do (as opposed to playing it safe and not worry about whether
or not someone has compromised the root to sign its own CRL "death warrant") is for
others to argue.
I prefer the term "abdication", similar to what a king or other potentate
can do.
My idea is that by combining the simplifications above, the only "extra"
infrastructure needed would be to have a cRLDistributionPoint in the
root cert, same as in the child certs it issues.
Then when clients download the CRL (to check a child cert), it may get
the message that the whole hierarchy is now dead.
Another use for such abdication CRLs is the "Superseded" scenario, such
as revoking a 1024-bit root before its time, once all the intentionally
issued child certs are no longer used and the new 2048-bit root has been
fully deployed (by then the CA may already have published an 8192-bit
root, given the current pace of things).
Note about the risk of someone compromising a root to sign its abdication,
the fact that someone has done so is itself proof that the root is now
compromised, even if the legitimate root operator has not signed his own
version of such a message. So as a client, the fact that an abdication
has been signed by someone with access to the root key is proof enough
regardless of the fact that this is then the last and only trust of the
key.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
