Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

Hot answers tagged

3

Each CA has their own revocation list. When your device validates a certificate, it determines what CA was used to sign it, downloads the CRL (whose URL is included in the CA certificate) and checks if the serial number of the certificate is included in it. Since all certificates have expiration dates, then any certificate in a CRL can be removed from the ...


3

OK, let's go over them: Fail-Safe Defaults: this is the most important one, as a CRL doesn't provide on-line information and may not be available or out-of-date; Economy of Mechanism: a CRL may contain information about many certificates, so the mechanism isn't as economic as it could be; Complete Mediation: CRL's are public info while complete mediation is ...


3

No. A CRL is as public as the certificate it revokes; it has to be signed to guarantee authenticity, but not encrypted. There are no optional confidentiality requirements for CRL distribution in RFC 5280. It is not even common practice to use anything other than plain http for the CRL distribution points. The whole idea with CRLs is to get them out there to ...


3

OCSP is not susceptible per se to MITM attacks, but it does have other problems: Most browsers used to soft-fail, e.g., if they couldn't get the OCSP response for some reason, it allowed the connection to go through. So the attacker only needed to block the OCSP response. Privacy issues: an attacker can see the OCSP query going through and can gain some ...


2

The Key Usage field is represented as a bit string, where each bit represents one of the options, so that multiple options can be set. The value 6 it's just the constant of the bit position that identifies "CRL Signing". From RFC 5280: KeyUsage ::= BIT STRING { digitalSignature (0), nonRepudiation (1), -- recent editions of X.509 ...


2

The end entities (phones, PCs, etc.) doesn't store the CRL files. I mean doesn't store permanently. :) In the Certificate there's a field called CRL Distribution Points where the CRL file could be downloaded. These files are issued by the CA and contains the list of revoked certificates. While the validation process this file is downloaded and checked ...


2

Using a time stamp is certainly allowed, provided it is truly monotonically increasing. What I want to point out here is that computers have knowledge of the current date and time through their internal clock, which may be subject to drift and therefore to alterations to put it "back in line". Some systems will rely on NTP, a network protocol which is not ...


2

That depends on the concrete CRL. As long as you have access to your private key, you can sign the revocation request. This prevents anyone without access to the private key from issuing a faked revocation request. With access to the private key, a faked revocation request can be sent. But in this case the damage is already done, and a revocation is ...


2

Yes one could do this, the repudiation wouldn't be very convincing. The CRL really isn't very relevant. A person can always claim his private key was stolen. His credit card was stolen or his car was stolen. We see people commit hit and run, realize what they have done park the car somewhere and report it stolen. Denying a credit card transaction etc. If ...


1

At some point your Root CA has to have control over it's subordinate CAs. If there was a scheme where it delegates this control to another server (such as your OCSP-like suggestion), the Root CA would still need to have control over this service in some way or another. In order to assert this control you would at some point need to power up the Root CA. A ...


Only top voted, non community-wiki answers of a minimum length are eligible