On 24/11/2009 10:25, Jean-Marc Desperrier wrote:
Nelson B Bolyard wrote:
CAs that
make this mistake typically have to abandon and completely replace their
entire PKI (entire tree of issued certificates) when a CA cert expires
and
its serial number appears in the AKI of other subordinate certs. More
than
once I've seen entire corporate PKIs have to be replaced due to this
error.
I feel a bit awkward about that description of the problem.
I'd say it becomes a huge problem only when you want to do a *silent* CA
upgrade. And there's a list of common problem in PKIs, their deployment,
and the PKI software stack, that have the consequence that silent
upgrade is often the only way forward.
That is worrying. Elsewhere I have seen advice that the silent upgrade
(as you describe it) cannot be done because of these same software problems.
E.g., if you have an MD5 problem, you are facing an entire recreation.
Silent CA upgrade mean here generating a new CA certificate, with a
longer timespan, *without* changing the private key, and keeping the
same DN, so that you can use it instead of the old certificate to verify
the signature of the old certificates issued below it.
Nod. This should be possible and routine.
But in an ideal world, you could change the private key, the software
stack would handle this properly, old certificate would be verified by
the old CA, new one by the new CA, you'd even have a way to change your
root CA private key and have the new certificate handled as equivalent
to the old one.
The world is not ideal, but we hope for a change someday, I prefer to
properly tell that the real source of problems is the software that
don't let you update private keys of existing CAs in practice, leading
to the consequence that you'd better be cautious and not include
issuer's issuer name and serial number inside AKI.
Thanks for that explanation, this is very helpful. Now it begins to
make much more sense.
So, because software is (a) over-zealous and (b) variable between
different implementations, the recommendation might be:
AKI should include only the keyID, and not the issuer name/serial
number.
CAs should not do silent upgrades, that is, should not re-issue
certs over private keys already in other root or subroot certs.
or?
It's important to point out that there is a pragmatic,
lowest-common-denominator logic to this recommendation, so as to reduce
the need to wave theories and RFCs around.
Does the same story apply more or less as painfully over EE certs.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
