OCSP Flashcards
1
Q
Online Certificate Status Protocol (OCSP)
A
- Client-server architecture, where clients:
-> request status of certificates from an OCSP responder (server),
-> communicate online, in (near) real time
-> can request status of multiple certificates inside a single query
2
Q
OCSP - Responder
A
- Provides signed answers
- Has a certificate with the extension extendedKeyUsage = OCSPSigning
- Possible responses:
-> Unknown (nothing known about the certificate, e.g. issuer unknown)
-> Revoked (certificate revoked or MAY not exist)
-> Good (no such certificate is within its validity period and is revoked)
3
Q
Signed response acceptance criteria
A
- The certificate identified in a received response corresponds to the certificate identified in the corresponding request
- The signature on the response is valid
- The identity of the signer matches the intended recipient of the request
- The signer is currently authorized to provide a response for the certificate in question
- The time at which the status being indicated is known to be correct (thisUpdate is sufficiently recent)
- When available, the time at or before which newer information will be available about the status of the certificate (nextUpdate) is greater than the current time
4
Q
OCSP extensions
A
- Support for all extensions is optional for both clients and responders
- For each extension, the definition indicates:
-> its syntax
-> processing performed by the OCSP responder
-> and any extensions which are to be included in the corresponding response
5
Q
OCSP extensions: Nonce
A
- Binds a request and a response -> prevent replay attacks
- Request: Included as one of the requestExtensions
- Response: Included as one of the responseExtensions
6
Q
OCSP extensions: CRL reference
A
- Points to the CRL where a revoked or suspended certificate can be found
- Specified by:
-> a URL
-> and/or a CRL number
-> and/or the issuing time of the CRL - Included as singleExtensions in the response
7
Q
OCSP extensions: Acceptable response types
A
- Allows a client to specify the response types it understands
-> Given as OID - Included as one of the requestExtensions
- OCSP clients and responders must at least support the basic response type
8
Q
OCSP extensions: Archive cutoff
A
- A responder may retain revocation information beyond a certificate’s expiration
- The archive cutoff extension should be included by responders that support such historical reference
- The archive cutoff date is obtained by subtracting the retention interval from the response date (producedAt time)
- Can be used to prove whether a digital signature was (or was not) reliable on the date it was produced
- Included as singleExtensions in a response
9
Q
OCSP extensions: CRL entry extensions
A
- Besides specific OCSP extensions, all CRL entry extensions are also supported as OCSP singleExtension
- e.g.: Reason code, hold instruction code, invalidity date, certificate issuer
10
Q
OCSP extensions: Service locator
A
- Allows an OCSP server to receive a request and route it to an OCSP server known to be authoritative for the identified certificate
- Includes issuer name and optionally the AuthorityInfoAccess information
-> both obtained from the certificate - Included as one of the singleRequestExtensions
11
Q
Authorized responders
A
- Clients must reject the response if the certificate required to validate the signature on the response does not meet at least one of the following criteria
- The OCSP signature certificate:
1. matches a local configuration of OCSP signing authority for the certificate in question, or
2. is the certificate of the CA that issued the certificate in question, or
3. includes a value of OCSPSigning in the Extended Key Usage extension and is issued by the CA that issued the certificate in question
12
Q
OCSP server revocation
A
- Problem: Is the certificate of the OCSP server valid?
- Approaches:
-> No revocation for the certificates of OCSP responders (special extensions ocsp nocheck, short validity period)
-> Use CRLs
-> Leave it to the verifier
13
Q
X.509 certificate extensions: Authority information access
A
- Indicates how to access CA information and services for the issuer of the certificate
- Information and services may include: online validation services, CA policy data
- This extension does not contain CRL location information
- Must be non-critical
- Two standard access methods defined
-> caIssuers (alternative certificates of the issuer)
-> ocsp (location of the corresponding OCSP responder for validating the certificate)
14
Q
OCSP stapling
A
- During the TLS handshake, servers may return a suitable certificate status response along with their certificate
- Servers can cache OCSP responses and reuse them
-> No additional OCSP request by the client required
-> May reduce load for OCSP servers
-> Support privacy for clients
15
Q
Hash-based revocation
A
- No explicit revocation necessary
- But explicit validation
- By publishing “not revoked” information
16
Q
Certificate revocation system
A
- Instead of producing CRLs, the CA updates the directory daily by indicating the status of each issued certificate
- In order to do this, it uses an authentication system based on a one-way function
17
Q
Revocation in PGP
A
- By publishing the revocation certificate (on PGP key servers)
- The key owner (the subject) is responsible for revocation
- The private key is required to generate the revocation certificate
-> if the private key is lost, and no revocation certificate has been generated before: revocation is impossible
-> there is no mechanism to remove keys once published
18
Q
Problems with standardized revocation mechanisms
A
- Detection:
-> Wrong/malicious certificate must be detected
-> How to do this in a system, where hundreds of CAs can potentially issue certificates - Distribution/availability:
-> Delays in general not accepted (by users)
-> Hard vs. soft fails - Too-big-to-fail:
-> Revocation may endanger functioning of whole infrastructure (large CAs)
19
Q
Approaches (to problems with standardized revocation mechanisms: Detection)
A
- Public key pinning (Pin is a relationship between a hostname and a cryptographic identity)
- Public logs
- DNSSEC + DANE (DNS-Based Authentication of Named Entities)
-> DNSSEC: signed DNS responses
-> DANE: DNS records also contain public keys of servers - Notaries (ask third party)
20
Q
Certificate Transparency
A
- Publicly auditable, append-only, untrusted logs of all issued certificates
- Helped to find many certificate mis-issuance
- Issues:
-> Logs are hard to maintain
-> Computationally expensive (log and client verification)
21
Q
Structure of an OCSP request
A
- Version
- requestorName (optional)
- requestList: List of single requests, one for each certificate that is to be checked (consists of certID + singleRequestExtensions)
-> certID: hash algorithmID + hash of issuer’s DN + hash of issuer’s public key + CertificateSerialNumber - requestExtensions
-> Optional signature
22
Q
Structure of an OCSP response
A
- tbsResponseData
-> version
-> responderID
-> producedAt
-> responses (certID, certStatus, thisUpdate, nextUpdate, singleExtensions)
-> responseExtensions - signatureAlgorithm
- signature
- certs (optional)
23
Q
X.509 certificate extensions: OCSP Must-Staple
A
- X.509 v3 TLS Feature extension
- Should not be marked critical
- Indicates, that server must staple OCSP status information
-> hard fail possible on absence of stapled OCSP info
24
Q
Micali’s CRS Properties
A
- C serves as proof of authenticity or revocation
- Update bandwidth is high, depending on the total number of certificates
- Verification of known certificates is low-bandwidth, but is it fast?
- If a user has never verified a particular certificate before, on day 364, he must calculate f364(C) to verify it
- If we increase the rate of updates, we increase the computation time needed
25
Q
Tree-based CRT
A
- Choose a cryptographically strong (one-way) hash function h
- Randomly generate 2^y numbers as leaves of a binary tree
- Build a hash-tree
- Put the value of the root node into the certificate (replacing Y365 from Micali’s system)
- On day i, release the values of the path from leaf node i and all nodes on the path needed to compute the root
- Better computation time but updates are worse since hash values have to be released every day
26
Q
Approaches (to problems with standardized revocation mechanisms: Distribution/Validity)
A
- OCSP must-staple
- Proprietary push and aggregation mechanisms
- No revocation checking for certificates with a validity period <10 days
27
Q
Approaches (to problems with standardized revocation mechanisms: Too-big-to-fail)
A
- Implementation of chain model for certificate validation
- Fine grained revocation & path validation with forward secure signatures
28
Q
CRLite
A
- Relies on recent advancements, especially Certificate Transparency
- Start with set of all known certificates
- Aggregate revocation information for all known certificates
- Challenges:
-> There are many certificates
-> How to update efficiently?
29
Q
OneCRL
A
- New blocklist: Also used to blocklist harmful things like malicious extensions
- Used to revoke: intermediate CAs, CAs and end-entity
- Manually processed for exceptional cases
