rethinking pki what s trust got to do with it n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Rethinking PKI: What’s Trust Got to do with It? PowerPoint Presentation
Download Presentation
Rethinking PKI: What’s Trust Got to do with It?

Loading in 2 Seconds...

play fullscreen
1 / 24

Rethinking PKI: What’s Trust Got to do with It? - PowerPoint PPT Presentation


  • 135 Views
  • Uploaded on

Rethinking PKI: What’s Trust Got to do with It?. Dr. Stephen Kent Vice President, Chief Scientist- Information Security. Why Do We Care about PKI?. A public key infrastructure (PKI) is not intrinsically useful!

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Rethinking PKI: What’s Trust Got to do with It?' - shantell


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
rethinking pki what s trust got to do with it

Rethinking PKI:What’s Trust Got to do with It?

Dr. Stephen Kent

Vice President, Chief Scientist- Information Security

why do we care about pki
Why Do We Care about PKI?
  • A public key infrastructure (PKI) is not intrinsically useful!
  • Applications that rely on digital signatures for “broadcast authentication” or non-repudiation, or that make use of key agreement may need a PKI
  • Applications use certificates for authentication and/or authorization of users, devices, organizations, processes, …
  • Neither authentication nor authorization need be based on trust!
some pki terminology
Some PKI Terminology
  • Certificate: a digitally signed attestation of the accuracy of attributes bound together under the signature
  • Public Key Certificate: a certificate containing a public key
  • Certification Authority (CA): an issuer of a certificate, and thus an entity that vouches for the accuracy of the attributes in a certificate
  • Subject: an entity to which a certificate is issued; for a public key certificate, the subject holds the corresponding private key
  • Certification Practice Statement (CPS): a characterization of the policies and procedures that a CA employs in issuing and revoking certificates
  • Relying Party (RP): a user or software agent who acts based on the presumed accuracy of attributes in a certificate
the fundamental ca requirement
The Fundamental CA Requirement

Establish and maintain an accurate binding among the attributes contained in a certificate

understanding the ca requirement
Understanding the CA Requirement
  • Usual requirement interpretation: accurate binding of attributes to a public key
  • Attribute types: identity, authorization, management
  • If present, authorization attributes may be more important than identity attributes, depending on how the certificate is employed
  • Management attributes affect processing, may amplify or constrain identity and authorization attributes
  • Question: Is the CA authoritative for the attributes in the certificate, or must we trust the CA?
x 509 public key certificate syntax
X.509 Public Key Certificate Syntax

Version

Serial Number

Signature Algorithm

Issuer

Management

Validity Period

Subject

Subject Public Key

Identity

Subject/Issuer Alt Names

Management Extensions

Authorization

Authorization Extensions

are more attributes better
Are More Attributes Better?

Steve’s Rule of Revocation:

“The effective lifetime of a certificate is inversely proportional to the square* of the number of attributes it contains”

*OK, maybe its really just n log N, or even linear, but you get the point

what s in a name
What’s in a Name?
  • Identity attributes (names) are the focus of many PKI discussions, directory schema, CPS’s etc.
  • But, identity is a complex concept
  • Identity attributes may be used directly for implicit authorization, may be inputs to an explicit authorization algorithm, or may be inputs to a human-executed value judgment
  • For most types of names, there exist real world entities who are authoritative, i.e., they manage the spaces from which the names are assigned
names in a pki
Names in a PKI
  • Names used in a PKI must be unique relative to some well-defined context
  • A CA must ensure uniqueness among subject names in the certificates it issues
  • It’s easy to make a name globally unique: just add qualifiers
  • However, many names that are globally unique are not globally meaningful
  • Most names are meaningful only in context
  • Relying parties need meaningful names to make authorization decisions or value judgments
personal example name spaces
Personal Example Name Spaces

US

Video Signals

MA

Boxborough

BBN Technologies

Steve Kent

Boxborough

XXXX

Stephen Kent

60 Stonehedge Place

01719

Stephen Kent

xxxx

US Government

US Government

Visa/MC/Amex

Dept. of State

Social Security Admin

Stephen Thomas Kent

xxxxxxxxx

Stephen T. Kent

xxxx-xxxx-xxxx-xxxx

Stephen Thomas Kent

xxx-xx-xxxx

more name space examples
More Name Space Examples

United Airlines

US Airways

Marriott

Hertz

com

Dr. Stephen Kent

xxxxxxx

Stephen Kent

xxxxxxxxxxx

Stephen Kent

xxxxxxxxx

Stephen Kent

xxxxxxx

bbn

kent

net

verizon

Stephen.Kent

cas names and trust
CAs, Names, and Trust
  • Individuals typically have lots of names, each of which can be made globally unique, but each is meaningful only in a well-defined context
  • Most organizational names are only locally unique (note that trademarks are scoped)
  • Transactions must use names that are meaningful to the participants (relying parties)
  • As we move physical world relationships to cyberspace, we often can make use of the same names, and extant organizations could act as CAs
  • Such CAs do not require explicit trust, since they are authoritative for the names they certify
an organizational pki
An Organizational PKI
  • A PKI for use only within an organization
  • Organizations: companies, colleges, professional societies, …
  • Subjects are employees, students, members, etc.
  • Subject names are drawn from existing databases
  • CA name could be arbitrary, but is pays to plan ahead, think globally!
  • The Mao Zedong approach?

Org A

CA

CA operations can be out-sourced

when authoritative organizations

are PKI-challenged

an inter organizational pki
An Inter-Organizational PKI
  • Connects organizational PKIs
  • Direct cross-certification using Name Constraints, avoids “trust” issues, just recognizes organizations as authoritative for name spaces
  • Helps if organizations choose their CA names wisely
  • O(n2) cross certificates, but often that’s OK
  • Users within each organization see it as a root

Org A

CA

Org B

CA

Org C

CA

the bridge ca model
The Bridge CA Model
  • A CA acts as intermediary for a set of organizations
  • O(n) alternative to direct, cross-certification
  • Bridge CA must be accepted by organizations it serves
  • Bridge CA puts Name Constraints in certificates it issues
  • May issue consolidated CRLs for all organizations
  • Adopted by several national governments for internal use, some commercial groups too

Org A

CA

Org B

CA

Bridge

CA

Org C

CA

Org D

CA

large scale pkis
Large Scale PKIs
  • Another way to avoid O(n2) cross certification: use a CA with broad scope, e.g., a government or private sector organization that is authoritative for many names
  • The DNS provides one obvious choice
  • Government agencies also are appropriate for individuals and some types of organization names

DNS or

Government

Org A

CA

Org C

CA

Org B

CA

trusted third party ttp cas
Trusted Third Party (TTP) CAs
  • No CAs are authoritative for all attributes nor are any CAs universally trusted
  • Many public CAs have no a priori relationship with subjects or with replying parties
  • These CAs are authoritative for no name spaces
  • It seems appropriate to label such CAs as TTPs, since they require users and relying parties to trust them and since they are very much third parties
  • Use of TTPs negates the benefits of the Name Constraints extension in cross certificates (principle of least privilege)
  • Is this a good idea?
what s trust got to do with it
What’s Trust Got to do with It?
  • Trust is a complex notion
    • trust is not transitive
    • trust is not readily quantifiable
    • trust is relative
  • If a CA is authoritative for a name space, the elusive notion of trust is irrelevant
  • One does not ask if Company X is trusted to identify its employees, the U.S State Department to identify U.S. Citizens, AOL to identify members, ...
  • The VCR programming experience argues that people cannot manage trust-based PKIs
two certification path examples
Two Certification Path Examples

Amex

Visa

Bank

Bank

SETCO

MC

MIT

LCS

BBN

D4J

Client

Client

Client

Client

User B

User A

Client

Client

is there a role for trust
Is there a Role for Trust?
  • When authorization is determined algorithmically, based on identity or authorization attributes in a certificate, the CA should be authoritative, not trusted
  • If a human user makes a value judgment based on identity attributes in a certificate, it’s best if the CA is authoritative for those attributes
  • When no entity is authoritative for an attribute, then the term “trust” is entirely appropriate
    • Web site ratings
    • Movie & book reviews
    • Sexiest man/woman, worst software, …
conclusions
Conclusions
  • Explicit trust is unnecessary for many PKIs
  • Names in certificates must be contextually meaningful, or they will be dangerous
  • Users cannot understand or manage complexity in PKIs
  • TTPs have been important in promoting PKI, but authoritative CAs are preferable, to minimize complexity and maximize security
  • Large scale CAs can be operated by governments, DNS TLD managers, etc.
  • Organizations can safely cross certify, without “trust”