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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Signed response acceptance criteria

A
  1. The certificate identified in a received response corresponds to the certificate identified in the corresponding request
  2. The signature on the response is valid
  3. The identity of the signer matches the intended recipient of the request
  4. The signer is currently authorized to provide a response for the certificate in question
  5. The time at which the status being indicated is known to be correct (thisUpdate is sufficiently recent)
  6. 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Hash-based revocation

A
  • No explicit revocation necessary
  • But explicit validation
  • By publishing “not revoked” information
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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