This document discusses public key infrastructures (PKI) and their components. It describes how PKI can enable secure communication, notarization, time-stamping, non-repudiation, and privilege management through the use of certificates, digital signatures, and trusted third parties. It also outlines some of the pitfalls of PKI, such as key compromises, difficulties with revocation, and human errors in certificate validation. Finally, it examines the technical details of how certificates, certification authorities, certificate paths, and trust models function within a PKI.
Introduction to Public Key InfrastructureTheo Gravity
Adonis Fung and I worked on a project where we defined and built PKI (Public Key Infrastructure) for our local development and deployed environments. I gave a talk to our engineers on how PKI works, covering encryption, signing, trust stores, and how the HTTPS handshake works.
A presentation explaining the concepts of public key infrastructure. It covers topics like Public Key Infrastructure (PKI) introduction, Digital Certificate, Trust Services, Digital Signature Certificate, TLS Certificate, Code Signing Certificate, Time Stamping, Email Encryption Certificate
Introduction to Public Key InfrastructureTheo Gravity
Adonis Fung and I worked on a project where we defined and built PKI (Public Key Infrastructure) for our local development and deployed environments. I gave a talk to our engineers on how PKI works, covering encryption, signing, trust stores, and how the HTTPS handshake works.
A presentation explaining the concepts of public key infrastructure. It covers topics like Public Key Infrastructure (PKI) introduction, Digital Certificate, Trust Services, Digital Signature Certificate, TLS Certificate, Code Signing Certificate, Time Stamping, Email Encryption Certificate
Scott Rea - IoT: Taking PKI Where No PKI Has Gone BeforeDigiCert, Inc.
Presentation by Scott Rea, DigiCert's Sr. PKI Architect, at AppSec California 2015.
Abstract:
Traditional PKI focuses on binding a public key to the keyholder’s identity, which is implicitly assumed to be a well-defined, relatively static thing (such as individual’s full name or email address, or the hostname of a public webserver). However, in the envisioned smart grid, for example, the relevant properties of the keyholder are not just the device’s identity (i.e. this is a meter made by ACME or this is a refrigerator made by GE) but its context: This is a refrigerator in the apartment rented by Alice, who buys power from X.
This context information will not necessarily be known until device installation and also may change dynamically. What if Alice sells her fridge on Craigslist or sublets her apartment to Bob? What if repair personnel replace Alice’s meter? This information may also not be particularly simple. What if Alice’s landlord owns many apartment buildings, and changes power vendors to get a better rate?
If our cryptographic infrastructure is going to enable relying parties to make the right judgments about IoT devices (such as the example provided using Smart Grid), this additional contextual information needs to be available. We can try to modify a traditional identity-based PKI to attest to these more dynamic kinds of identities, and we can also try to adapt the largely experimental world of attribute certificates to supplement the identity certificates in the smart-grid PKI. Either of these approaches will break new ground.
Alternatively, we can leave the identity PKI in place and use some other method of maintaining and distributing this additional data; which would require supplementing our scalable PKI with a non-scalable database.
In any of these approaches, we also need to think about who is authorized to make these dynamic updates or who is authoritative for making these types of attestations. Who witnesses that Alice has sold her refrigerator? Thinking about this organizational structure IoT devices also complicates the revocation problem. If we can’t quite figure out who it is that speaks for where a device currently lives, how will we figure out who it is who is authorized to say it has been compromised?
In this presentation, all of these issues and more will be explored and actionable guidelines will be proposed to build a secure and scalable system of IDs and attributes for the complex networked world that awaits us all.
Infrastructure Saturday 2011 - Understanding PKI and Certificate Serviceskieranjacobsen
In every organization, there is a growing need for a strong well-designed public key infrastructure solution and in many of these; Active Directory Certificate Services will be used. This session will guide you through a solution based on best practice, shed some light on common issues encountered and some shortcuts to assist in management with PowerShell.
Presented at Seminar at Bahria University June 2007
Cryptography Simplified - Symmetric Key, Public Key, PKI, Digital Signature, Certification Authority, Secure Socket Layer (SSL), Secure Electronic Transaction (SET)
Security+ Guide to Network Security Fundamentals, 3rd Edition, by Mark Ciampa
Knowledge and skills required for Network Administrators and Information Technology professionals to be aware of security vulnerabilities, to implement security measures, to analyze an existing network environment in consideration of known security threats or risks, to defend against attacks or viruses, and to ensure data privacy and integrity. Terminology and procedures for implementation and configuration of security, including access control, authorization, encryption, packet filters, firewalls, and Virtual Private Networks (VPNs).
CNIT 120: Network Security
http://samsclass.info/120/120_S09.shtml#lecture
Policy: http://samsclass.info/policy_use.htm
Many thanks to Sam Bowne for allowing to publish these presentations.
Scott Rea - IoT: Taking PKI Where No PKI Has Gone BeforeDigiCert, Inc.
Presentation by Scott Rea, DigiCert's Sr. PKI Architect, at AppSec California 2015.
Abstract:
Traditional PKI focuses on binding a public key to the keyholder’s identity, which is implicitly assumed to be a well-defined, relatively static thing (such as individual’s full name or email address, or the hostname of a public webserver). However, in the envisioned smart grid, for example, the relevant properties of the keyholder are not just the device’s identity (i.e. this is a meter made by ACME or this is a refrigerator made by GE) but its context: This is a refrigerator in the apartment rented by Alice, who buys power from X.
This context information will not necessarily be known until device installation and also may change dynamically. What if Alice sells her fridge on Craigslist or sublets her apartment to Bob? What if repair personnel replace Alice’s meter? This information may also not be particularly simple. What if Alice’s landlord owns many apartment buildings, and changes power vendors to get a better rate?
If our cryptographic infrastructure is going to enable relying parties to make the right judgments about IoT devices (such as the example provided using Smart Grid), this additional contextual information needs to be available. We can try to modify a traditional identity-based PKI to attest to these more dynamic kinds of identities, and we can also try to adapt the largely experimental world of attribute certificates to supplement the identity certificates in the smart-grid PKI. Either of these approaches will break new ground.
Alternatively, we can leave the identity PKI in place and use some other method of maintaining and distributing this additional data; which would require supplementing our scalable PKI with a non-scalable database.
In any of these approaches, we also need to think about who is authorized to make these dynamic updates or who is authoritative for making these types of attestations. Who witnesses that Alice has sold her refrigerator? Thinking about this organizational structure IoT devices also complicates the revocation problem. If we can’t quite figure out who it is that speaks for where a device currently lives, how will we figure out who it is who is authorized to say it has been compromised?
In this presentation, all of these issues and more will be explored and actionable guidelines will be proposed to build a secure and scalable system of IDs and attributes for the complex networked world that awaits us all.
Infrastructure Saturday 2011 - Understanding PKI and Certificate Serviceskieranjacobsen
In every organization, there is a growing need for a strong well-designed public key infrastructure solution and in many of these; Active Directory Certificate Services will be used. This session will guide you through a solution based on best practice, shed some light on common issues encountered and some shortcuts to assist in management with PowerShell.
Presented at Seminar at Bahria University June 2007
Cryptography Simplified - Symmetric Key, Public Key, PKI, Digital Signature, Certification Authority, Secure Socket Layer (SSL), Secure Electronic Transaction (SET)
Security+ Guide to Network Security Fundamentals, 3rd Edition, by Mark Ciampa
Knowledge and skills required for Network Administrators and Information Technology professionals to be aware of security vulnerabilities, to implement security measures, to analyze an existing network environment in consideration of known security threats or risks, to defend against attacks or viruses, and to ensure data privacy and integrity. Terminology and procedures for implementation and configuration of security, including access control, authorization, encryption, packet filters, firewalls, and Virtual Private Networks (VPNs).
CNIT 120: Network Security
http://samsclass.info/120/120_S09.shtml#lecture
Policy: http://samsclass.info/policy_use.htm
Many thanks to Sam Bowne for allowing to publish these presentations.
Presented at Codebits V, 11/11/11 Lisbon.
Video and more info here: https://codebits.eu/intra/s/session/180
note: this talk was co-presented by me and Luís Grangeia (www.slideshare.net/lgrangeia)
Certificate pinning in android applicationsArash Ramez
How to do cryptography right in android
Part #4 / How to mitigate MITM attacks in SSL/TLS channels using server certification validation
watch it on youtube:
https://www.youtube.com/playlist?list=PLT2xIm2X7W7gZ0mtoAA8JrfFrvOKr1Qlp
[4developers2016] - Security in the era of modern applications and services (...PROIDEA
Security is hard. Old days are over and it requires way more then providing login form, comparing password hash and maintaining HTTP session. With the raise of mobile and client side apps, (micro) services and APIs it has become a fairly complex topic. At the same time with security breaches hitting the news on the monthly basis it is everyone's concern. Being an area every developer or architect needs to understand very well. Thankfully a number of modern standards and solutions emerged to help with current challenges. During this talk you will learn how to approach typical security needs using modern token based security and standards like OAuth2, OpenID Connect or SAML. We’ll discuss wide variety of security related topics around multi factor authentication or identity federation and brokering . You will also learn how you can leverage modern open source identity and access management solutions in your applications.
Module 4: Key Management and User Authentication
X.509 certificates- Public Key infrastructure-remote user authentication principles-remote user
authentication using symmetric and asymmetric encryption-Kerberos V5
In this talk, I will explain the foundations of the TLS protocol: symmetric encryption, digital signature, PKI, and how these concepts come together to secure your network connections
Building Trust in Blockchain: How Blockchain Will Revolutionize Businesses in...PECB
While Blockchain technology creates strong cryptographic controls securing the integrity of data, successful, cooperative Blockchain networks must establish trust between a varieties of independent entities to create overall trust. In this presentation, Scott Perry and Drummond Reed will discuss how trust is created in Blockchain systems and the varying layers (i.e. ledger, agent, credential exchange and governance) that add trust within interoperable parties and reliance to external Blockchain’s within the web of trust. As active members of the Sovrin Governance Working Group, including the first robust trust assurance model for Blockchain’s, our presenters will discuss how all Blockchain’s networks can add accountability within stakeholder roles to ensure that Blockchain’s are trustworthy above the embedded cryptographic trust assertions.
The target of this webinar is leaders and participants in the industry who are seeking greater acceptance and assurance in the trustworthiness of their network.
This session will help you learn which role systems auditors, cybersecurity professionals, and risk management experts will have to play to ensure trust must be built and maintained when adopting such cutting-edge technologies.
The webinar covers:
• How Digital Trust is created
• How Blockchain’s novel attributes contribute to digital trust
• Blockchain’s beneficial use cases
• Deeper Dive into Self Sovereign Identity as a unique Blockchain use case
Date: March 18, 2019
Recorded Webinar: https://youtu.be/1lcuf9bJFBQ
Securing the Data in Big Data Security Analytics by Kevin Bowers, Nikos Triandopoulos of RSA Laboratories and catherine Hart and Ari Juels of Bell Canada
IBM Security Strategy Intelligence, Integration and Expertise
by Marc van Zadelhoff, VP, WW Strategy and Product Management and Joe Ruthven IBM MEA Security Leader
How to Make a Field invisible in Odoo 17Celine George
It is possible to hide or invisible some fields in odoo. Commonly using “invisible” attribute in the field definition to invisible the fields. This slide will show how to make a field invisible in odoo 17.
Instructions for Submissions thorugh G- Classroom.pptxJheel Barad
This presentation provides a briefing on how to upload submissions and documents in Google Classroom. It was prepared as part of an orientation for new Sainik School in-service teacher trainees. As a training officer, my goal is to ensure that you are comfortable and proficient with this essential tool for managing assignments and fostering student engagement.
2024.06.01 Introducing a competency framework for languag learning materials ...Sandy Millin
http://sandymillin.wordpress.com/iateflwebinar2024
Published classroom materials form the basis of syllabuses, drive teacher professional development, and have a potentially huge influence on learners, teachers and education systems. All teachers also create their own materials, whether a few sentences on a blackboard, a highly-structured fully-realised online course, or anything in between. Despite this, the knowledge and skills needed to create effective language learning materials are rarely part of teacher training, and are mostly learnt by trial and error.
Knowledge and skills frameworks, generally called competency frameworks, for ELT teachers, trainers and managers have existed for a few years now. However, until I created one for my MA dissertation, there wasn’t one drawing together what we need to know and do to be able to effectively produce language learning materials.
This webinar will introduce you to my framework, highlighting the key competencies I identified from my research. It will also show how anybody involved in language teaching (any language, not just English!), teacher training, managing schools or developing language learning materials can benefit from using the framework.
Unit 8 - Information and Communication Technology (Paper I).pdfThiyagu K
This slides describes the basic concepts of ICT, basics of Email, Emerging Technology and Digital Initiatives in Education. This presentations aligns with the UGC Paper I syllabus.
The Art Pastor's Guide to Sabbath | Steve ThomasonSteve Thomason
What is the purpose of the Sabbath Law in the Torah. It is interesting to compare how the context of the law shifts from Exodus to Deuteronomy. Who gets to rest, and why?
Palestine last event orientationfvgnh .pptxRaedMohamed3
An EFL lesson about the current events in Palestine. It is intended to be for intermediate students who wish to increase their listening skills through a short lesson in power point.
The Roman Empire A Historical Colossus.pdfkaushalkr1407
The Roman Empire, a vast and enduring power, stands as one of history's most remarkable civilizations, leaving an indelible imprint on the world. It emerged from the Roman Republic, transitioning into an imperial powerhouse under the leadership of Augustus Caesar in 27 BCE. This transformation marked the beginning of an era defined by unprecedented territorial expansion, architectural marvels, and profound cultural influence.
The empire's roots lie in the city of Rome, founded, according to legend, by Romulus in 753 BCE. Over centuries, Rome evolved from a small settlement to a formidable republic, characterized by a complex political system with elected officials and checks on power. However, internal strife, class conflicts, and military ambitions paved the way for the end of the Republic. Julius Caesar’s dictatorship and subsequent assassination in 44 BCE created a power vacuum, leading to a civil war. Octavian, later Augustus, emerged victorious, heralding the Roman Empire’s birth.
Under Augustus, the empire experienced the Pax Romana, a 200-year period of relative peace and stability. Augustus reformed the military, established efficient administrative systems, and initiated grand construction projects. The empire's borders expanded, encompassing territories from Britain to Egypt and from Spain to the Euphrates. Roman legions, renowned for their discipline and engineering prowess, secured and maintained these vast territories, building roads, fortifications, and cities that facilitated control and integration.
The Roman Empire’s society was hierarchical, with a rigid class system. At the top were the patricians, wealthy elites who held significant political power. Below them were the plebeians, free citizens with limited political influence, and the vast numbers of slaves who formed the backbone of the economy. The family unit was central, governed by the paterfamilias, the male head who held absolute authority.
Culturally, the Romans were eclectic, absorbing and adapting elements from the civilizations they encountered, particularly the Greeks. Roman art, literature, and philosophy reflected this synthesis, creating a rich cultural tapestry. Latin, the Roman language, became the lingua franca of the Western world, influencing numerous modern languages.
Roman architecture and engineering achievements were monumental. They perfected the arch, vault, and dome, constructing enduring structures like the Colosseum, Pantheon, and aqueducts. These engineering marvels not only showcased Roman ingenuity but also served practical purposes, from public entertainment to water supply.
4. PKI and the Services
♦ CLAIM: PKI can help in all
♦ Question (subjective – GI)
– Where is the source of trust in all these?
– Suggestion (subjective – GI)
• Try to do the same without PKI, using only
symmetric techniques (usually possible!);
find the problem;
see how this problem is manifested and addressed in
the PKI solution.
• Easier to “cheat” (including yourself!) with PKI.
Symmetric techniques are more explicit.
♦ Make all the security & trust assumptions explicit!
6. Pitfalls
♦ Security breaches
– Key compromises
♦ Inherent difficulties
– Revocation
♦ Negligence
– Certificates are routinely not checked or some of the
attributes ignored
– Alarms and warnings ignored
(“certificate not valid. Press OK to proceed.”)
♦ Inconsistencies & human factors
(“that’s not what I meant by this policy!”)
8. Certificates
♦ Introduced in 1978
[Kohnfelder’s Bachelor’s thesis]
♦ X.509 – “the standard standard” today
– v.1 (1988) – not extendable
– v.2 – not much better
– v.3 (1997) is much better – optional extensions
Today, X.509=v.3
– Many other standards extend X.509
♦ Others
– PGP, SPKI, etc.
9. Certificates
♦ Certificates ≠ Signature
– Certificates are implemented using Signatures
♦ Certificates ≠ Authentication
– Authentication can be implemented using
Certificates
– Same for Authorization, etc.
♦ Certificates are static
– Change => Re-Issue
• *This could be challenged, but not in standard x509
11. Certificate Validation
♦ Integrity: signature is valid
♦ Signed by a trusted CA
– or certification path is rooted in a trusted CA
♦ Certificate is valid now:
– We are between Not Valid Before and Not Valid
After time points in the certificate
♦ Not Revoked
♦ Use is consistent with the policy
13. SPKI – A Simple PKI
♦ Authorization certificates
♦ Delegation
♦ SDSI – a Simple Distributed Security
Infrastructure
♦ Question #1:
it may be very nice, but will it ever be used
by anyone?
14. PGP – Pretty Good Privacy
♦ Tendencies
– Email
• Incompatibilities between PGP and S/MIME
• OpenPGP v6.5 supports x509 certs, but still…
– Personal (rather than corporate)
15. SET – Secure Electronic Transaction
♦ Credit card payment protocol
♦ Adopts and extends X.509
– See [AL] pg.84
18. Certificate Policies
♦ Certificate Policy
– “high level what is supported” document
♦ CPS – Certification Practice Statement
– “detailed, comprehensive, technical how policy
is supported” document
♦ No agreement on the roles and meanings of
the above
♦ Might be not public; hard to enforce
19. Certificate Policies
♦ Distinguished by OIDs (Object ID)
– “form letters”
♦ Equivalences
– Policy Mapping ext. declare policies equivalent
♦ Established & registered by
Policy [Management] Authorities
– Internal – e.g. corporate
– External – community
20. CA – Certification Authority
♦ Issuer/Signer of the certificate
– Binds public key w/ identity+attributes
♦ Enterprise CA
♦ Individual as CA (PGP)
– Web of trust
♦ “Global” or “Universal” CAs
– VeriSign, Equifax, Entrust, CyberTrust, Identrus, …
♦ Trust is the key word
21. RA – Registration Authority
♦ Also called LRA – Local RA
♦ Goal: Off-load some work of CA to LRAs
♦ Support all or some of:
– Identification
– User key generation/distribution
• passwords/shared secrets and/or public/private keys
– Interface to CA
– Key/certificate management
• Revocation initiation
• Key recovery
24. Initialization
♦ Registration
– Via RA
– Identity verification
• According to CP/CPS docs
– If on-line, should be protected+authenticated (?)
– Secret shared by user and CA
• New or pre-existing relationship
♦ Key pair generation
♦ Certificate creation & delivery
♦ [Key backup]
25. Key pair generation
♦ Where? (by who?)
– CA
– RA
– Owner (e.g. within browser)
– Other Trusted 3rd Party
♦ What for?
– Non-repudiation ⇒ owner generation
♦ Dual key pair model
– Separate key pairs for authentication,
confidentiality, etc.
26. Key pair generation
♦ Performance
– Laptop, smart cards – used to be too slow
• Today – many smart cards can generate own keys
– Centralized generation
• Scalability: bottleneck for performance & security
♦ Assurance
– “Is the smart card’s random number generator
good enough?”
– Minimal security requirements guarantees
♦ Legal/Liabilities
– Who to sue? Who backs up above assurances?
27. Certificate Creation+Distribution
♦ Creation – CA only
♦ Distribution (to the owner)
– Certificate only
– Certificate + private key
• Deliver key securely!
– X509 rfc2510
– Direct to owner
– To depository
– Both
28. Certificate dissemination
♦ Out-of-band
♦ Public repositories
– LDAP-like directories
– Used mostly for confidentiality
♦ In-band
– E.g. signed e-mail usually carries certificate
Issues:
– Privacy, scalability, etc.
29. Key backup
♦ Backup ≠ Escrow
– Backup= only owner can retrieve the (lost) key
– Escrow= organization/government can retrieve
the key even against owner’s wish
♦ Non-repudiation conflicts with Backup
♦ Where & how to backup securely???
30. Issued Phase
♦ Certificate retrieval
– To encrypt msg or verify signature
♦ Certificate validation
– Verify certificate integrity+validity
♦ Key recovery
– Key backup – automate as much as possible
♦ Key update
– When keys expire: new certificate [+new keys]
31. Certificate Cancellation
♦ Certificate Expiration
– Natural “peaceful” end of life
♦ Certificate Revocation
– Untimely death, possibly dangerous causes
♦ Key history
– For owner: eg to read old encrypted msgs
♦ Key archive
– “For public”: audit, old sigs, disputes, etc.
32. Certificate Expiration
♦ No action
♦ Certificate renewal
– Same keys, same cert, but new dates
– Preferably automatic
– but watch for attributes change!
♦ Certificate update
– New keys, new certificate
34. Certificate Revocation
♦ Requested by
– Owner, employer, arbiter, TTP, ???, …
♦ Request sent to
– RA/CA
♦ Mechanisms for Revocation checks
– Certificate Revocation Lists (CRLs)
– On-line Certificate Status Protocol (OCSP)
• Will it live? (SCVP)
♦ Revocation delay
– According to Certificate Policy
35. Publication Mechanisms
♦ Complete CRLs
♦ Authority Revocation Lists (ARLs)
♦ CRL distribution points (partition CRLs)
♦ Delta CRLs
♦ Indirect CRLs
♦ Enhanced CRL distribution points &
Redirect CRLs
♦ Certificate Revocation Trees (CRTs)
White lists vs Black lists
36. CRL versions
♦ Version 1 (from x509 v1)
– Flaws:
• Scalability
• Not extendable
• Can replace one CRL with another
♦ Version 2 (similar to x509 v3)
– Extensions
• critical and non-critical
• Per-CRL and per-entry
– Format: see [AL] pg.112
37. Complete CRLs
♦ Advantage:
– Self-contained, simple, complete
♦ Problems:
– Scalability
• CRL may grow too big
– Timeliness
• Also results from CRL size
♦ Conclusion: appropriate for some domains
38. Authority Revocation Lists
♦ ARL = CRL for Cas
– Revokes certificates of Cas
– Rarely needed/used
• Decommissioned
• Compromised
39. CRL Distribution Points
♦ Partition CRL into smaller chunks
♦ Static partitions:
– Certificate points to its CRL distribution point
♦ Dynamic partitions
– Enhanced/Redirect CRL DPs
• Certificate points to a Redirect CRL
• Redirect CRL directs to the proper CRL partition
40. Delta CRL
♦ Incremental change
– From Complete or Partition CRL
– CRLnew=BaseCompleteCRLold + DeltaCRL
– Possibly many DeltaCRLs from same BaseCRL
• E.g. complete CRL issued once a week, and a new
DeltaCRL (containing the previous DeltaCRLs)
issued every day
42. Certificate Revocation Trees
– Valicert [Kocher]
– Based on Merkle’s hash trees
– Similar/Relevant work: [Micali; Naor&Nissim]
♦ Construct hash-tree; leaves – certificates
♦ Sign root
♦ To verify a certificate in the tree: path from
the certificate to root + the siblings
♦ Certificate Owner can offer proof of not
being revoked as of the current CRT date!
44. Trust model issues
♦ Who to trust?
– Which certificates can be trusted
♦ Source of Trust
– How it is established?
♦ Limiting/controlling trust in a given
environment
45. Common Trust Models
♦ CA Hierarchy
♦ Distributed
♦ Web
♦ User-centric
Tool
♦ Cross-certification
46. Trust – definition(??)
♦ “A trusts B = A assumes B will behave
exactly as A expects”
– Problem 1: A expects B to try every way of
cheating A that B can find, and A assumes B
will do exactly that == A trusts B?
– Problem 2: Is it a tautology? What’s the
difference between “assumes” and “expects”?
♦ X trusts a CA = X assumes CA will
establish and maintain accurate binding of
attributes and PK’s
– Maintain? Includes secure the binding, CA’s
keys binding, security, etc…
47. Trusted Public Key
♦ PK is trusted by X when X is convinced the
PK corresponds to SK which legitimately
and validly belongs only to a specific
named entity
48. CA Hierarchy
♦ Tree architecture
♦ Single Root CA
– Number of subordinate CA’s
• Etc…
– Parent certifies children
– Leaves are non-CA (end-) entities
♦ Typically CA either certifies other CA’s or
end-entities, but not both
♦ Everyone has Root CA PK
49. Context is important
♦ Privacy Enhanced Mail (PEM) adopted
strict hierarchy of CAs approach and failed
♦ DoD could use hierarchy fine
50. Distributed Trust Architecture
♦ A set of independent hierarchies
– May evolve as independent historically
♦ Cross-certification or PKI networking
– Connect the hierarchies
♦ Fully-meshed – all CAs are cross-certified
♦ Hub & spokes or bridge CA
– Not= Hierarchy
• No root CA: every end-entity holds its CA PK
51. Web Model
♦ A bunch of root CAs pre-installed in
browsers
♦ The set of root CAs can be modified
– But will it be?
♦ Root CAs are unrelated (no cross-
certification)
– Except by “CA powers” of browser
manufacturer
– Browser manufacturer = (implicit) Root CA
52. User-Centric
♦ PGP
♦ User = her own Root CA
– Webs of trust
♦ Good
– User fully responsible for trust
♦ Bad
– User fully responsible for trust
– Corporate/gov/etc. like to have central control
• User-centric not friendly to centralized trust policies
53. Cross-Certification
♦ Mechanism:
– Certificates for CAs (not end-entities)
♦ Intra- vs. Inter- domain
♦ One or two directions
– CA1 certifies CA2 and/or CA2 certifies CA1
♦ Control
– Cross-certificate limits trust
• Name, policy, path length, etc. constraints
54. Entity Naming
♦ What’s the identity?
(the one bound by certificate to the PK [+sk])
– If a certificate is issued to “GeoTrust ”, rather
than “Geotrust”, you may be talking to a
different entity than what you think
55. Name Uniqueness
♦ X.500 Distinguished Name (DN)
– Tree of naming authorities
– X.509 Subject is a DN;
– IP addresses, email, etc. are similar
♦ Problems
– Not too user-friendly
– Central naming authority not always there
• => lots of cooperation required from participating
entities
56. Names (continued)
♦ So, how useful are names?
– SDSI, SPKI, etc – not very
– X.509 allows alternative names
• Extensions subjectAltName
• If this extension is used Subject name (DN) is not
required
– Global uniqueness – not always crucial
– Piggy-back on existing naming/identity
infrastructures
57. Certificate Path
♦ Alice “trusts” CA1
– Alice has CA1’s PK in its browser
• CA1’s PK = “trust anchor”
– “trust anchor” depends on the model
♦ CA1 certifies CA2; CA2 certifies CA3
♦ CA3 certifies Bob
♦ => Alice “trusts” Bob
– Alice associates PK in Bob’s certificate with Bob
58. Certificate Path Processing
♦ Path construction
– Aggregation of necessary certificates
♦ Path validation
– Checking the certificates and the keys
• Includes all steps of certificate validation
59. Path Construction
♦ “Just a [Shortest] Path graph algorithm”
♦ Not so simple – graph is not known
– Edges (certificates) need to be queeried
♦ Once Path Construction is done Path
Validation is straight-forward
One way of adding change without re-issue: Say, certificates are short lived and a new date or new period/generation are required periodically – this is a change. The generation mechanism can be implemented as a hash chain (xi=hash(xi-1)). Some, xn is included in the certificate and every generation the previous x is released.
A more sophisticated change: adding an private attribute. Generate a hash tree on the attributes (with some key bits). Certify root. To add a privilege/attribute send to the owner the attribute leaf value the siblings of the path from the attribute to the root. Can add any subset of attributes. Taking the attributes away is harder. Also, the attributes must be privileges (something the owner wants) – otherwise the owner pretends not to receive the above values.