Tag Info

New answers tagged

0

A CA based model of validation fails as it is not capable of performing revocation of itself; there is no trust agility when a Root CA is compromised, as you have to replace your trust anchor. If this is merely an issuing CA rather than a root, the revocation event can succeed. However, let's review basic approaches to validation: Certificate Revocation ...


0

Yes, the machine may trust the Issuing CA certificate until November 2016. There are a few "solutions" in use -mainly in web browsers- when there's a certificate that which "must be revocated": Launch a new browser version including the revocation. Really inefficient, but it works. Chrome pushes revocation lists (crlsets) separatedly thorough their update ...


1

You guessed well: revocation is asynchronous. When you revoke a certificate, this becomes really effective only when the last pre-revocation CRL expires. If you issue CRL that are valid for one year, then a revoked certificate may still be trusted by other systems for up to one year. One should envision CRL as a damage containment feature: with CRL, you can ...


20

There is a standard for that, and, more generally, for all communications with a PKI. It is called CMP. Revocation requests are specified in section 5.3.9. Now, finding a PKI that actually implements CMP... this may be challenging.


6

If the entity is supposed to sign CRL but not certificates, then it is not a CA -- it is a CRL issuer. It is often called an indirect CRL issuer because, by definition, it is distinct from the CA that issued the certificates whose revocation status is specified by the CRL. A certificate may be validated as a CA only if (among other things) it has a Basic ...



Top 50 recent answers are included