What is PKI

1
What is PKI?

• PKI is supporting structures for large scale
  application of public key technology
• PKI consists of technological and legal aspects
• PKI supports a set of highly diversified
  organizations
• PKI can be expensive and risk-prone to deploy and
  operate
• Core components
• CA and related certificate management facilities
• How do CAs combine together
• Electronic signature laws

2
CA structures Traditional Models

• Trust model
• the structure of how CA certify other CAs
• It should make the finding and validating of
  certification paths simple, convenient, and
  efficient.
• Top-down hierarchical structure (tree)
• All certification paths start from the root CA
• Everyone absolutely trusts the top CA and use it
  as root CA
• Good scalability
• Easy to find certification path
• Unique certificate path for any end entity
• Disadvantage
• A single failure point (top CA in hierarchy),
  therefore need very strong security for top CA
• For commercial world, hard to identify a top CA

3
CA structures Traditional Models (continued)

• Forests of trees
• Multiple trees
• Points of trust
• User-controlled direct
• User enables certain roots to be trusted
• Used by Web browsers
• Domain-controlled direct
• Force local domain to a particular set of root
  CAs
• Suitable within an enterprise
• User-controlled cross-certification
• User system issues locally signed certificates
  for a particular set of root CAs
• Used in Lotus Notes
• Domain-Controlled cross-certification
• Domain administrator issues locally signed
  certificates within its domain

4
CA structures Traditional Models (continued)

• Certification Path Validation
• Verifying the digital signature and checking
  basic constraints
• Checking that the subject of every certificate is
  the issuer of the next certificate
• Checking the validity periods
• Checking that each certificate has not been
  revoked
• Checking the required certificate policies
• Checking name constraints

5
Certificate Policies

• When a CA issues a certificate (to either a
  person or an organization), identity is checked
• the registration and authentication process can
  be in different quality.
• Depending on different application, different
  quality of registration is needed
• Certificate Practice Statement (CPS)
• a statement of practice and procedures carried
  out by a CA
• Due to different registration practice, the
  certificate generated will have restriction on
  how it is used
• Certificate policy in X.509
• Information on whether the cert is appropriate
  for certain application purpose
• The public-key infrastructure can be designed to
  support different certificate policies

6
X509 Certificate Policy (CP)

• A set of rules that indicates the applicability
  of a cert to a class of applications with common
  security requirement
• e.g. a policy might mention applicability of a
  type of cert to the authentication of EDI
  transactions for the trading of goods within
  10,000
• CPs need to be a registered Object Identifier
• To be recognized by both the issuer and users

7
X.509 V3 Cert Policy Extension

• X.509 assumption
• the cert policy acceptance decision can be made
  by the user in advance.
• This allows the certs to be processed and
  accepted automatically, provided that the usage
  of cert policy is preprogrammed before
• An X.509 V3 cert contains the Certificate
  Policies extension fields
• non-critical Certificate Policies
• the policy is applicable but not necessarily
  mandatory
• critical Certificate Policies
• the cert is restricted to one of the identified
  policies (this somehow release the responsibility
  of the CA)

8
X.509 Policy Constraints Extension

• A kind of certification path constraints
  related to how to manipulate policies in a
  certification path
• Contains two optional indicator fields
• Require explicit policy indicator
• this indicator flags that in all further certs in
  the certification path, an explicit acceptable
  policy id must be present in every cert
• e.g. with the local CA, no policy check is
  needed, but with one external CA, cert policy for
  each CA in the path is needed
• Inhibit policy mapping indicator
• inhibit policy mapping in the remainder of the
  certification path

9
Certificate Policy Contents

• No standard definition, some typical contents
  suggested in RFC2527
• Community and applicability restrictions
• restricting certain group of users, and/or for
  certain purpose
• Identification and authentication policy
• the practice used by CA in identifying/authenticat
  ing the certificate subject
• Key management policy
• CAs measure to manage the key, and expectation
  on subscribers key protection
• Operational policy
• CAs practices in operating its services (e.g.
  how frequent CRLs are issued, audit trail
  procedures)

10
Certificate Policy Contents (continued)

• Local security policy
• measures by CA/LRA/end-entity to ensure its
  environment is safe, including physical security,
  personnel security, product assurance,
  network-access security
• Legal provisions
• a statement of limitations of liability asserted
  by CA on use of the certificate under a
  particular certificate policy, or other legal
  disclaimers or provisions
• Policy administration
• the name and contact details of the policy
  defining authority, and details of how the policy
  definition is maintained and published

11
X.509 Name Constraints

• for cross-certification cases
• e.g. company 1 (uses CA1) only wants to certify
  employee cert of company 2 (uses CA2)
• in which the employee is in U.S.A.,
• then when CA1 issues the cross-certificate for
  CA2s public key, a restriction to Country
  US, can be imposed
• This limits the risk (and responsibility) of CA1
• rules can restrict certain sub-tree of CA2s
  subject name space, exclude certain sub-tree of
  CA2s subject name space, etc
• Constraints can act on subject name, email
  address, etc

12
Certificate Management Protocols

• PKCS standards
• PKCS 10
• Standard for a message to request issuance of a
  cert from a CA
• PKCS 7
• An enveloping format for protect messages
• Adopted by S/MIME
• A degenerate form of PKCS 7 has been popularly
  used for delivering issued cert back to an
  applicant
• Certificate Management over CMS (CMC)
• CMS stands for Cryptographic Massage Syntax
• PKCS-based protocol
• Provided all the functions of CMP

13
Certificate Management Protocols (continued)

• Certificate Management Protocol (CMP)
• Initialization/certification
• Request and response messages for issuance of a
  certificate for a public key
• Proof of possession
• CA verify that certificate applicant indeed
  possesses the private key corresponding to the
  public key in the cert
• Key update
• User requests a new certificate
• Key recovery
• User requests recovery of a lost private key
• Revocation request
• Requests revocation of a certificate
• Cross-certification
• A CA requests that another CA issue it a
  certificate for use in certificate path
• Announcements
• CA announce update of a CA's key pair, new cert,
  CRL, etc.

14
Multienterprise PKI

• Real-world multienterprise PKI
• Privacy Enhanced Mail (PEM)
• Secure Electronic Transaction (SET)
• Indentrus
• The VeriSign Trust Network
• VeriSign PKI Hierarchy
• The Federal Bridge Certification Authority
• The Government of Canada PKI

15
Multienterprise PKI PEM PKI

• PEM PKI
• Internet Policy Registration Authority (IPRA)
• Top-level CA
• Operated by international, non-profit
  organization
• Policy Certification Authority (PCA)
• Second-level CA, only certified by IPRA
• Each one has a different statement of policy
  regarding users and subordinate CAs
• Lower-level Certification Authority (CA)
• different organization, etc
• Additional links
• from a PCA to a non-subordinate CA, allowing the
  ability of associating one of several available
  policies with a certification path

16
Multienterprise PKI PEM PKI (continued)

• PEM has three types of policies
• Organizational CA
• company employees
• Residential CA
• geographical basis
• Persona CA
• a special case for users to conceal his/her name
  while making use of PEM
• Name subordination rule
• a CA can only issue certificates for entities
  whose names are subordinate in the X.500 naming
  tree
• This is a practical way to limit the damages
  resulting from CA mistakes, etc

17
Multienterprise PKI SET PKI

• SET Public Key Infrastructure
• SET (Secure Electronic Transaction) Parties
• Issuer the bank issue the credit card to
  cardholder
• Cardholder the customer (C)
• Merchant store that accepts electronic payment
  (M)
• Acquirer the bank servicing the Merchant.
  Acquirer or its supporting partner will act as
  payment gateway (A)
• Certification Authority
• need a public key infrastructure which is a
  Top-down hierarchy of five layers

18
Multienterprise PKI SET PKI (continued)

• SET Hierarchy
• Top level
• Root CA, an organization agreed by the entire
  industry
• Brand CA
• for different brands, currently is Visa and
  MasterCard
• Different brand can have different policies
• Geo-political CA (optional level)
• for different geographic or political regions
• Cater for different local rules
• Cardholder CA/ Merchant CA
• the CA to generate and distribute Cardholder/
  Merchant certificates
• Can be Issuer/Acquirer or another party
• Cardholder/Merchant
• End-users

19
Multienterprise PKI SET PKI (continued)
20
Multienterprise PKI SET PKI (continued)

• Pros and Cons of SET PKI
• Top-down hierarchy is simple
• Appropriate for one single application
• Credit Card payment
• Trust among financial institutes already existing
• Infrastructure planned NOT to support other
  applications
• Infrastructure planned NOT to interoperate with
  any other infrastructure
• Limit the risk of using the certificates for
  unintended purposes

21
Next Session Highlights

• Non-repudiation