Information Security

Outline
• Message Digests
• Message Authentication and Digital Signatures
• Non-repudiation
• Certificates
• Certificate Validation

1
 Information Security

Message Digests
• Public key technology is very slow
• public-key encryption
– use public-key encryption to send a secret key with
confidentiality
– actual traffic is encrypted using secret key
• Public-key digital signatures
– cannot sign big messages

Original message,no limit to size Message digest Message digest 128 bit/160 bit
Algorithm

Hard
2
Easy
 Information Security

Message Digest

For performance reasons, sign the message digest but
not the message

also known as message authentication codes

One way hash functions: H(M) = m
– H is the one-way function
– easy to compute but difficult to invert
– m = H(M) is easy to compute
– M = H-1(m) is hard to compute
– M is a long message (say 1 megabyte)
– m is a short (say 128 bit) digest

authenticity of a message can be checked by computing
H(M) = m, and comparing with the transmitted m

this requires that the digest m be either
– transmitted over a more secure channel than M, e.g., M is a disk
transmitted by mail, m is transmitted via phone, or
3
– m be digitally signed which may be easier than signing M
 Information Security

Good Hash Functions

• The computation of message digests should be fast
and efficient
– allowing the hashing of messages several gigabytes in size
• Since a document is usually much larger than its hash
value, the mapping is a many-to-one function.
– For each specific hash value there potentially exist many
documents possessing this fingerprint
• It should be practically infeasible to find a document
that produces a given fingerprint
– This is why a good hash function is called one-way.

4
 Information Security

Good Hash Functions

• The message digest value should depend on every bit
of the corresponding message.
• If a single bit of the original message changes its
value, or one bit is added or deleted, then about 50%
of the digest bits should change their values in a
random fashion

5
 Information Security

Good Hash Functions

• A good hash function achieves a pseudo-random
message-to-digest mapping
– causing two nearly identical messages to have totally different
hash values
• Due to the pseudo-random nature of a good hash
function and the enormous number space of possible
hash values
– it becomes quite impossible that two distinct messages will
ever produce the same digest value

6
 Information Security

Desired Characteristics
• Weak hash function
– difficult to find M' such that H(M') = H(M)
– given M and m = H(M) try messages at random to find M' with H(M') = m
– 2k trials on average, k= 64 is considered to be safe
• Strong hash function
– difficult to find any two M1 and M2 such that H(M1) = H(M2)
– try pairs of messages at random to find M1 and M2 such that H(M1) = H(M2)
– 2k/2 trials on average, k=128 to be safe
– k = 160 is better
– for a n bit digest birthday attack will allow M1, M2 to be found in 2n/2
operations
– (if there are >= 23 people, the chance of two of them have the same birthday is
>50%)

7
 Information Security

Message Digests
• MD5
– proposed by Ron Rivest (of RSA)
– 128 bit digest
– simple, compact and fast
• NIST SHA
(https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpub
lication800-107r1.pdf)
– SHA-1, SHA224, SHA256, SHA384, SHA512, SHA512/224, SHA512/256

8
 Information Security

Digital signatures
Insecure Channel
Encrypted MD + plaintext

MD of plaintext Verification Yes/No

A
Signature
Algorithm Algorithm B

Alice’s private key Alice’s public key

• Verification
– Generate MD from plain text
– Generate MD from decrypting the “encrypted MD” using Alice’s public key
– Compare the two MDs
• If the answer is no, one of the following is true
– someone is trying to impersonate Alice
– the message itself has been altered
– an error occurred during transmission
• problems
– collision may occur (birthday attack)
– someone could pretend to be Alice and sign documents with a key pair they claim is Alice’s

9
 Information Security

Keyed message digests

• secret key technique to provide efficient authentication and integrity
• does not provide non-repudiation
• also called HMAC (Hash function based Message Authentication code)
• unlike digital signatures, MACs are computed and verified with the same
key, so that they can only be verified by the intended recipient.

Insecure Channel
Plain Text + signature

Verification Yes/No
A
Plain Text Signature
Algorithm Algorithm B

K K
Signature = MD of (plaintext + K)
11
 Information Security

Non-Repudiation

In general, non-repudiation requires a notarized
signature, involving a third party in addition to A and
B

In large systems this can involve hierarchies of
notarization

12
 Information Security

Outline
• Message Digests
• Message Authentication and Digital Signatures
• Non-repudiation
• Certificates
• Certificate Validation

13
 Information Security

Public-key certificates
• Binding of public key to an individual or entity
• public-key encryption
– sender needs the public key of the receiver
• public-key digital signatures
– receiver needs the public key of the sender
• public-key agreement
– both need each other’s public keys
• Reliable distribution of public-keys is critical
– otherwise, an intruder can substitute a different public key resulting
in disclosing of encrypted contents to unintended parties
• Easier for small groups of cooperating parties
• A public-key certificate system where a certification
authority issue certificates for the holders of key pairs

14

X.509 certificate
• Comprises of
– version
– serial number
– signature algorithm ID
– issuer name
– validity period
– subject (user) name
– subject public-key information
– signature on the above fields
Information Security
• Example
– 0
– 1234566679079950956
– RSA+MD5,512
– c=us,s=nj,o=rutgers,ou=msis
– 1/1/2010-1/1/2022
– c=us,s=nj,o=rutgers,cn=Vijay Atluri
– RSA,1024,XXXXXXXXX
– signature
16
 Information Security

Certificate Trust
• The primary benefits of the certificate system
– one can reliably obtain a large number of parties starting with the knowledge
of one party’s public-key
– scalability
• how to acquire public key of the issuer to verify signature
• whether or not to trust certificates signed by the issuer for this
subject

17
 Information Security

PGP Bottom Up Trust Model

• How does Alice get Bob’s public key
– directly from Bob through some secure channel (e.g., mail, phone, floppy)
– from Cathy, who is known to both Alice and Bob and introduces Bob to Alice
– from a trusted certifying authority
• PGP has mechanisms to support these, and related, alternatives

18
 Information Security

Certification Paths
• One certificate authority to issue certificates for all!!
– Key distribution problem is solved
– is it feasible?
• Need multiple certification authorities
• not practical for a public-key user to have the public-keys of
all CAs
• the certificate paradigm can be applied recursively to obtain
the public keys of a progressively larger number of CAs
– called certificate chain or certificate path

19
 Information Security

Certificate path

20
 Information Security

Validity and revocation

• Public-key and private-key pairs are not valid for ever, but
have a restricted lifetime
• Certificate Revocation List: Format
signature algorithm ID
issuer name
last update
next update
revoked certificates
signature
serial number
revocation date
21
 Information Security

Legal relationships
• Closed community
– CA and its subscribers are all part of one legal entity
– e.g., subscribers are ATMs, bank is the CA
• open community
– CA is an independent legal entity (third party)
– e.g., commercial CA service provider issues certificates to people who
subscribe

22
 Information Security

Subject authentication
• the CA must make sure that the holder of the private key
corresponding to the certified public key is indeed the same
person or entity
• physical presence - a strong confirmation of identity
• identification documents - passport, employee id, driver’s
license
• Local registration authority may be used for approving the
certificate application (but LRA is not a CA, it does not issue
certificates)

23
 Information Security

Key management
• Key pair generation
– generation where the private key is held (requirement in the
ANSI X9.57)
– generation at a central system
• Private key protection
– storage in a tamper-resistant hardware module (such as a
smart card)
– storage in an encrypted file within a computer system

24
 Information Security

Different Keys For Different Purposes

• RSA is the only known public-key crypto system in which the same
public-private key pair can be used for
– digital signatures
– encryption
• perceived as a major advantage

25
 Information Security

Signature Keys
• private key: must be private for entire life, may never leave smart
card
– needs to be securely destroyed after lifetime
– no need for backup as protection against accidental loss of key (would conflict
with above)
– no need for archiving (would conflict with above)
– if disclosed even after long time of active use, it may still be used to forge
signatures on old documents
– no need to weaken or escrow due to law
• public key: must be archived possibly for a long time
– to verify old signatures

26
 Information Security

Encryption Keys
• private key: backup or archive required for recovery
– should not be destroyed after lifetime
– may be weakened/escrowed due to law
• public key:
– no need to backup RSA or other encryption keys
– need to backup Diffie-Hellman key agreement keys

27
 Information Security

Different Keys For Different Purposes

• Needed because of
– different export controls
– different key lengths
– different crypto periods
– key escrow

28
 Information Security

X.509 Certificates
• X.509 version1 (1988)
– very basic
• X.509 version2 (1993)
– adds unique identifiers to prevent against reuse of X.500 names
• X.509 version3 (1996, revised 1999)
– adds many extensions
– can be further extended

29
 Information Security

Need for extending X.509

• distinguish various certificates
– signature, encryption, key-agreement
• identification information in addition to X.500 name
• name other than X.500 name
– email address
• issuer can state policy and usage
– good enough for casual email but not good enough for signing checks
• limits on use of signature keys for further certification

30
 Information Security

X.509 versions 1 and 2

VERSION
SERIAL NUMBER
SIGNATURE ALGORITHM
ISSUER X.500 name
VALIDITY
SUBJECT X.500 Name
SUBJECT PUBLIC KEY INFO
Issuer unique identifier
Subject Unique identifier
SIGNATURE

31
 Information Security

Directory Services
• Certificate distribution can be done via a directory
service
• X.500 - the ISO standard
• LDAP (Lightweight directory access protocol) has a
standard protocol for accessing information in the
directory service public key certificates
• proprietary directory services - Microsoft exchange
directory, Novell’s Netware directory, Lotus Notes
directory

32
 Information Security

Name Structure

33
 Information Security

X.509 version3 Extensions

• X.509 version3 same as X.509version2 but adds extensions
• provides a general extension mechanism
– extension type: registered just like an algorithm is registered
– standard extension types: needed for interoperability
• criticality
– non-critical: extension can be ignored by certificate user
• alternate name can be non-critical
– critical : extension should not be ignored by certificate user
• limit on use of signatures for further certification
– criticality is flagged by certificate issuer
• certificate user may consider non-critical extensions more important than critical ones
• certificate user may refuse to use certificate if some extensions are missing
– critical extensions should be few and should be standardized

34
 Information Security

X.509 version3 Names

• internet email address
• internet domain name
• EDI party name
• web url
• IP address
• X.400 email address
• X.500 directory name
• registered identifier
• other name

35
 Information Security

Standard Extensions in X.509 version3

• Key and policy information
• Subject and issuer attributes
• Certification path constraints
• Extensions related to CRLs

36
 Information Security

Key and Policy Information

• key usage: purpose for which the key is used
– critical: intended only for that purpose, limits liability of CA
– non-critical: advisory to help find the correct key, no liability implication
• private-key usage period
– certificate valid for 2 years for verifying signature
– key valid only for one year for signing
• certificate policies and policy mapping
– for CAs

37
 Information Security

Subject and Issuer Attributes

• Subject alternative names
• Issuer alternative names
• Subject directory attributes
– whatever you like
– position, phone, address etc.

38
 Information Security

Certification Path Constraints

• Basic Constraints
– can or cannot act as CA
– if can act as CA limit on certification path
• limit=1 means cannot certify other CAs
• Name Constraints
– limits names of subjects that this CA can issue certificates for
• Policy Constraints
– concerned with CA policies

39
 Information Security

Certificate Revocation Lists

• A timestamped list of revoked certificates
• CRLs issued periodically as per CA policy
– off-cycle CRLs may also be needed (no guarantees)
– blank CRLs can be issued
• CRL distribution
– pull method (no need for secure transmission)
– push method (need to transmit via a secure channel)
• DMS (Defense Messaging System) example
– pull method with push for compromised key list (CKL) which is broadcast via
secure email, single CKL for entire system
– does not scale well and may not be applicable to other environments

40
 Information Security

Certificate Revocation Lists

• immediate or real-time revocation
– needs to query CA on every certificate use
– works well in small closed communities
• Revocation Time-line

• Authorization certificates can be short lived

– minutes, hours, days instead of months, years
41
 Information Security

X.509 CRL Extensions

• General Extensions
• CRL distribution points
• Delta-CRLs
• Indirect-CRLs
• Certificate Suspension

42
 Information Security

General Extensions
• CRL Number (incrementing sequence number)
• Reason Code
– Key Compromise
– CA Compromise
– Affiliation changed
– Superseded
– Cessation of operation
– Remove from CRL: defer till Delta-CRL
– Certificate hold: defer
• Invalidity Date

43
 Information Security

CRL Distribution Points

• CRLs can get very big
– version 1 CRL (1988, 1993)
• each CA has two CRLs: one for end users, one for CAs
• end user CRL can still be very big
– version 2 CRL
• can partition certificates, each partition associated with one CRL distribution point
• also can have different distribution points for different revocation reasons
• certificate extension field, says where to look
• CRL extension fields
– CRL distribution point: distribution point for this CRL and limits on scope and reason
of revocation
– issuing distribution point: protects against substitution of a CRL from one distribution
point to another

44
 Information Security

Delta-CRLs
• Delta CRL indicator
– only carries changes from previous CRL
– If clients have secure storage facilities, then there is no need to download the
base CRL all the time.
• Remove from CRL reason code causes purge from base CRL (stored
at certificate user)
– removal due to expiry of validity period or restoration of suspension

45
 Information Security

Indirect-CRL
• CRL can be issued by a different CA than the issuer of certificate
– allows all compromise revocations to be one list
– allows all CA revocations to be on one list (simplify certificate chasing)
– extension field: certificate issuers

46
 Information Security

Certificate Suspension
• Certificate hold reason code in CRL
• Supporting CRL entry extension
– Instruction code: instructions on what to do with held certificate
• call CA, repossess token

47
 Information Security

General Hierarchical Structure

48
 Information Security

General Hierarchical Structure With Additional

Links

49
 Information Security

Top-down Hierarchical Structure

50
 Information Security

PEM Certification Graph

51
 Information Security

Forest of Hierarchies

52
 Information Security

SET PKI

53
 Information Security

MISSI PKI

54
• MISSI: Multi-level Information System Security Initiative 
 Information Security

Outline
• Message Digests
• Message Authentication and Digital Signatures
• Non-repudiation
• Certificates
• Certificate Validation

55
 Information Security

Why Validation?

 Joe resigns or is fired on Friday at 2pm

 His certificate is revoked
 Can he logon to company computers and copy or delete
sensitive data? If so, for how long?
 Can he obligate the company by signing a PO with his
certificate?
 Even if his certificate is valid, is he authorized?

56
 Information Security

Certificate Validation

• Validation Solutions and Challenges

– Technical Approaches (CRLs, CRLDP, OCSP, SCVP,…)
– Validation Authorities

57
 Information Security

Validation Protocols
• The Problem
– Find Marty Yam’s Phone Number
1. CRLs (Certificate Revocation List)
– Call an operator for Marty’s phone number, get back the whole
phone book
2. CRLDPs (CRL distribution points)
– Call an operator for Marty’s phone number, get back only the
pages dealing with “Y”
3. OCSP (on-line certificate status protocol)
– Call an operator for Marty’s phone number, get back his
number from an operator
4. SCVP (simple certificate validation protocol)
– Call an operator and get automatically connected to his phone

58
 Information Security

1. Certificate Revocation List

• A signed “Black List” of Revoked Certificates

• Each Entry:
– Serial Number of Certificate
– Time of Revocation (e.g. Jan 15th, 2014 at 10:05 a.m.)
• Issuer Name
– MSIS Department, Business School, Rutgers University, US
• Time of Issuance (thisUpdate)
• Time “at or before which new information will be available”
(nextUpdate)
• Other information (entry extensions) optional
• e.g. Reason for revocation

59
 Information Security

Certificate Revocation List

Cert SSL Cert

? ?

CRL CRL

CA CA
System/CRL System/CRL
Sever Sever

60
 Information Security

CRLs - Advantages

+ Widely Used, fine for small, self-contained PKIs

+ Ability to Cache
+ Easy to manage for small numbers
+ Works with all issued certificates
+ Industry standard

61
 Information Security

CRLs -Disadvantages
- Size -- Storage,
- Huge bandwidth all the way to the clients
- Unscalable
- Does not scale past 10,000 users for large number of clients
- Requirement to Cache
- does not provide real-time certificate status information
- since issued on a periodic basis
- Painful to Find CRLs from online directories for end-user
applications,
- especially if certificate chains are involved and CRLs are required to be
fetched from different locations
- do not provide a positive response regarding a “particular”
certificate being "good"

62
 Information Security

CRL - Applications
• Ideal for deployment
– small user base (a company with several thousand employees)
• Simple applications
– use ID cards to access a building
– use smart cards to log onto their computers

63
 Information Security

2. CRL Distribution Points

• A clever mechanism to break up a CRL into smaller

chunks

• Revocation Data is split into multiple buckets

• Each bucket is a “mini” CRL

• Every certificate contains data that allows applications to

determine which bucket to look at to check validity

64
 Information Security

CRL Distribution Points – Advantages

and Disadvantages
+ Can be cached
+ Reduces amount of data that needs to be exchanged
+ Better than CRLs, can work in larger systems
+ Bucket for a certificate is fixed when it is issued
+ Tiny bandwidth between CA and clients
+ No trusted server required
+ Scales to hundreds of millions of users
- Somewhat higher implementation complexity

65
 Information Security

3. OCSP
• An “online” mechanism
• Simple Client-Server model

• Certificate accepting application (Client) asks OCSP Responder

(Server) for a certificate’s status

• response-request used for obtaining online certificate

revocation information from a trusted entity
• OCSP Responders provide immediate revocation information
on specific certificates rather than a list as in CRL
• Server responds with yes (with time of revocation, reason for
revocation), or no. The response is signed.

66
 Information Security

OCSP Model

Cert SSL Cert

OCSP OCSP

Validation Validation
Server Server
(Secure) (Secure)

67
 Information Security

Anatomy of an OCSP Transaction

[CA1,sn1] [CA1,sn2] [CA2,sn3]

PKI Transaction
Relying OCSP
+
Party ([CA1,sn1,y] [CA1,sn2,y] [CA2,sn3,n])sign Responder
Certificate(s)

68

OCSP Division of Labor
Client Tasks
• Build Certificate Chain
• Perform Offline Verification of
Certificate
• Deal with Policy Issues
Information Security
Server Tasks
• Provide Status Information for
all Certificates Requested
• [Optional] Provide Other
Attribute Information
69
 Information Security

OCSP Advantages and Disadvantages

+ Best for high value transactions
+ Up-to-Date and faster dissemination of revocation Information
+ Small Response Size
+ Response may be Cached
- Responder needs to sign each response
- Responder key is online => must be in a secure site, introduces
vulnerabilities
+ Small bandwidth between responder and clients
+ Works with all issued certificates
+ Industry standard
- Requires trusted responders (extremely expensive)
- Requires digital signing at each transaction (very slow)
- Does not scale past 100,000 users
- Loss of security if any responder is compromised

70
 Information Security

OCSP- Applications
• works well for deployments
– with tens of thousands of users
– in close proximity to one another
• Example:
– a university with a single large campus
• could issue smartcards to all its students that allow them access to
dormitories, libraries, and campus-wide computer networks

71
 Information Security

D-OCSP Advantages and Disadvantages

+ No trusted responders required
+ Scales to ten million users
+ Computationally simple (no signing per transaction)
+ Works with all issued certificates
+ Industry standard
- Bandwidth to responders is larger than with OCSP

72
 Information Security

D-OCSP - Applications
• works well for deployments
– anywhere from several thousand to hundreds of millions of users
• Example:
– A government agency with a number of centers of operation scattered
throughout the world
• issues smart cards that allow access to a networked fileserver containing
sensitive information, or
• allow entry to field offices

73
 Information Security

4. SCVP
• allows a client to delegate certificate path construction
and certificate path validation to a server
• The path construction or validation (e.g. making sure
that none of the certificates in the path are revoked)
is performed according to a validation policy, which
contains one or more trust anchors
• It allows simplification of client implementations and
use of a set of predefined validation policies.
• Simplify the Relying Party
• Enable Widespread Use of PKI
• Allow for Centralized Certificate Policy Management

74
 Information Security

4. SCVP
• When a SCVP Client wants to obtain a certification
path, validate a public key certificate or both
simultaneously
– it must send a SCVP Validation Request (SCVPRequest)
message to a capable SCVP entity (server)
– SCVP server builds and returns the certification path to the
client, to validate the certificate presented by the client or both
– SCVP server must respond to the client a SCVP Validation
Response (SCVPResponse) message which contains the new
certificate path and/or the certificate status.

75

SCVP Division of Labor
Client Tasks
• Send over Certificate(s)
• Send over Desired Usage
• [Optional] Send over Trusted
Roots
• [Optional] Send over
Intermediate Certificates
Information Security
Server Tasks
• Build Certificate Chain
• Perform Offline Verification of
Certificate
• Find Status Information of
Chain
• Figure out Applicability of
Certificate for Usage
• [Optional] Provide other
attribute information
76
 Information Security

SCVP Advantages
• Simplify Client
• Enable Faster PKI Integration
• Reduce Client Implementation Flaws
– Keep them simple
• Centralized Control Over Trust
• Ability to Support Complex Certificate Hierarchies
• Centralized Certificate Policy Management

77
 Information Security

SCVP Disadvantages
• Place a lot of “Power” in the SCVP Server
– SCVP Server is a Single Point of Attack
• Server is Complicated

78
 Information Security

Resources
• PKIX
– Public Key Infrastructure (X.509) (RFC 6818 – Jan 2013)
– http://www.rfc-editor.org/rfc/rfc6818.txt
• CRL
– Certificate Revocation Lists (RFC 6818 – Jan 2013)
• CRLDP
– Certificate Revocation Lists - Distribution Points (RFC 6818 – Jan 2013)
• OCSP
– Online Certificate Status Protocol (RFC 6960 – June 2013)
http://tools.ietf.org/html/rfc6960
• SCVP
– Simple Certificate Validation Protocol (RFC 5055 – Dec 2007)
– https://tools.ietf.org/html/rfc5055

80
 Information Security

Browser capabilities
• All major browsers do some form of revocation checking, that
includes Opera, Safari, Chrome, Firefox and Microsoft Edge.
• Internet Explorer starting with version 7 on Windows Vista (not
XP) supports OCSP checking
• All versions of Mozilla Firefox support OCSP checking. Firefox 3
enables OCSP checking by default
• Safari on Mac OS X supports OCSP checking. It is enabled by
default as of Mac OS X 10.7 (Lion). Prior to that, it has to be
manually activated in Keychain preferences
• Versions of Opera from 8.0 to the current version support OCSP
checking
• Google Chrome disabled OCSP checks by default in 2012, citing
latency and privacy issues
– uses its own update mechanism to send revoked certificates to the browser
• No Browser implements SCVP

81
 Information Security

Browser capabilities
• When a user visits a website protected with SSL, it
validates the certificate the web server presents
– important because you need to know if the server you are talking to
really is who they say they are before you start to trust them – that’s
why when browsers do OCSP and CRLs they do this validation before
they download the content from the web page.
– This means that your content won’t be displayed to the user until
this check happens and this can take quite a while.
• For example in the case of Microsoft Edge and Chrome
(when it does standards based revocation checking on
Windows) it uses CryptoAPI which will time-out after 15
seconds of attempting to check the status of a certificate.
– The scary part is that calls to this API do actually time out and when
they do this delay is experienced by the users of your website!

82
 Information Security

Browser capabilities
• So what can you do about it?
– It’s simple really you have to be mindful of the operational capacity and
performance of the certificate authority you get your certificate from.
• GlobalSign Inc.
– consistently outperforms every other CA for the performance of their
revocation infrastructure in most cases it’s nearly 6x as fast and in
others is much more than that.
• Also, today the default behavior of browsers when checking
the status of a certificate via OCSP or CRLs is “soft-revocation
failure”.
– This basically means that if they fail for any reason to check the status
of a certificate (usually due to performance or reliability issues) they will
treat the certificate as good anyways. This is an artifact of CAs not
operating sufficiently performant and reliable infrastructure to allow the
browsers to treat network related failures critically.

83
 Information Security

Browser capabilities
• Each of these browsers all have options you can use to
enable “hard” or “strict” revocation checking but until
the top CAs operate infrastructure that meets the
performance and reliability requirements of the
modern web no browser will make these the default.
• It is also important to understand that even with this
“soft-failure” your website experiences the
performance cost of doing these checks.

84
 Information Security

Google Chrome
• Google does revocation checking through a
proprietary mechanism called CRLsets.
– CRLsets are basically a combination of CRLs, Google crawls the
web gathers CRLs and merges them together into a “mega-
crl”.
– This mega-crl is formatted differently than other CRLs but it’s
essentially the same thing
– but there are some important differences
• due to size concerns, Google selectively chooses which CAs it
includes in the CRL set and within those CRLs which revoked
certificates to include.
– Google introduce this new mechanism that is not as
comprehensive as the standard based ways to deal with
revocation checking for performance and reliability.

85
 Information Security

Google Chrome
– With CRLsets Google ensures quick delivery of the revocation list because
they can intelligently pick which revoked certificates are important
– This has implications for users, Chrome trusts certificate authorities for which
it has no revocation information for it also intentionally treats some revoked
certificates as good which exposes you to some risk.
• This is problematic for enterprises that use Chrome and leverage
PKI
– there is essentially no chance Google will decide to include your CRL.
– This is also problematic for those who encounter certificates from those CAs.
• But what do you do if you want a more holistic solution to
revocation checking?
– You can turn on the standards based revocation checking mechanisms and
Chrome will use them in addition to the CRLset,
– go to Settings and expand choose Advanced Settings
– re-enable the standards based revocation checking mechanisms
– then chrome can do a more holistic job protecting you from the known bad
actors on the internet.

86