1 / 24

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?. A public key infrastructure (PKI) is not intrinsically useful!

shantell
Download Presentation

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Rethinking PKI:What’s Trust Got to do with It? Dr. Stephen Kent Vice President, Chief Scientist- Information Security

  2. 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!

  3. 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

  4. The Fundamental CA Requirement Establish and maintain an accurate binding among the attributes contained in a certificate

  5. 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?

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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?

  18. 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

  19. Two Certification Path Examples Amex Visa Bank Bank SETCO MC MIT LCS BBN D4J Client Client Client Client User B User A Client Client

  20. 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, …

  21. 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”

  22. Questions?

More Related