Higher Ed PKI Certificate Policy

Document Sample
Higher Ed PKI Certificate Policy Powered By Docstoc
					 Higher Ed PKI
Certificate Policy
     David L. Wasley
  University of California

   I2 Middleware Camp
       David L. Wasley
     Office of the President
    University of California
 HEPKI   is a cooperative effort of CREN,
  EDUCAUSE/Net@EDU, and Internet2
 Policy Activities Group (PAG) works on trust
  issues and trust framework for PKI
     Why do you trust? How much trust is enough?
     Certificate Policy -- now in DRAFT
     Certification Practices Statement -- T.B.D.
          Will also draft a PKI CP/CPS Implementers Guide
     Directory Policy -- next “interesting” hurdle
        Certificate Policy is …
 the basis for trust between unrelated entities
 not a formal “contract” (but implied)
 a framework that both informs and constrains a
  PKI implementation
 a statement of what a certificate means
 a set of rules for certificate holders
 a way of giving advice to Relying Parties

                HEPKI HE CP
A    “generic” CP for higher ed PKI
     Based on IETF RFC 2527
     A set of rules and requirements intended to foster
      inter-domain trust
     All implementation specific details deferred to
      associated Certification Practices Statement
 Compatible with   the Federal BCA policy
 Four “levels of assurance”
     from “Rudimentary” level (minimal overhead)
     to “High” (requires photo IDs & smartcards)          4
            CP says basically…
 Who is responsible for the RA/CA operation
 What is the community served
     Important for RP to know what meaning to derive
 What are the rules for identifying Subjects
 What’s in a certificate
 What constraints are there on operation of the CA
 What must be done if something goes wrong

                   PKI Players
 Policy   Management Authority (PMA)
     Responsible for developing and enforcing policy
 Certificate Authority (CA)
     Operational unit(s)
     Term also applies to the entire set of PKI functions
 Registration Authority      (RA)
     Optional, given responsibility for I & A
 Subjects and    Relying Parties
 Document     identity
     OID for the CP and OIDs for each LOA
 PMA     and community are defined in the CPS
     Relying Party can’t make assumptions unless so stated
 CP   is transitive throughout the hierarchy
     Authorizing CA has responsibility for authorized CA
 Liability limitations
     CPS can proscribe specific uses of certificates
                 issued certificates is based on
 Applicability of
  Level of Assurance (LOA)
     Rudimentary - very low risk apps; data integrity
     Basic - for apps with minimal risk
     Medium - modest risk, including monetary loss
     High - secure apps; transactions of significant
      financial consequence
 RelyingParty must make the decision about
  what LOA is required
         Obligations of the Parties
 CA,   RA, Subscriber, Relying Party, Repository
     “the right thing” depends on LOA
 RP   is problematic since there is no “contract”
     “Requirements” are advice, e.g. checking CRL
     Sometimes a contract may be needed, e.g. FERPA
 Audit   requirements
     CA must be audited by a qualified third party
     May review audits of subordinate CA’s
 Identification and Authentication
 Different   requirements for each LOA
     Photo ID required for Medium or High LOA
     ID Document S/N’s must be recorded and archived
 Types   of Subject names
     If included, must be meaningful
     Must be unique for all time
 Association ofSubject with “directory data”
  must be accurate
           Operational Requirements
 CA   must protect its private key appropriately
     Must not generate key pairs for Subjects
 Certificate management
     Revocation required at Basic or higher LOA
          Requires standard CRL; allows for OCSP
          Relying Party required to check for revocation
     Suspension not used
 Security Audit        Procedure
     Everything that might affect the CA or RA             11
         Physical, Procedural and
        Personnel Security Controls
 CA   Roles
     Administrator - sysadmin; installs & configures
     Officer - approves issuance and revocation of PKCs
     Operator - routine system operation & backup
     Auditor - reviews syslogs; oversees external audit
 Separation of   roles required
     at least 2 people (Admin./Op. & Officer/Auditor)
     at least 3 at higher LOAs
 Some    tasks require action by 2 out of 4 persons
      Technical Security Controls
 FIPS   140 Technical Security
     Level depends on LOA
     Key sizes and private key protection requirements
 Escrow    of end-entity decryption (private) key
     CA must have possession of key before issuing PKC
     Must NOT escrow any other private key
 Computer  platform and network controls
 Engineering and development controls
 Certificate and CARL/CRL Profiles
 Certificate profile      is x.509v3 or higher
     Details in CPS
     CertPolicyID is the LOA OID
     CPSuri points to the on-line signed CPS
          CPS specifies CP OID and URL for on-line copy
     Certificate serial number must be unique across all
      PKCs issued by this CA
     Considering adding URI to authorityInfoAccess
 CARL/CRL          is x.509v2 or higher
     Other CPs for Comparison
 Federal BCA   Certificate Policy
 EuroPKI CP, Swedish Univ. CP, SURFnet CPS
 Globus Grid CP
 Draft Model Interstate Certificate Policy
 Commercial PKI CPs (very different)
 CP for the State of Washington
 NACHA CARAT guidelines

                  HE CP Status
 Draft   completed
     http://middleware.internet2.edu/certpolicies/
     Being vetted to wider audience, e.g. NACUA
 Companion   HEBCA CP needs to be reviewed
  to ensure compatibility
 Generic OIDs may be acquired for CP, LOAs
 Example CPS(s) will be generated
 Notes for CA implementers will be created

 Cookbook  approach to getting started w/PKI
 Minimal requirements
     Roughly equivalent to issuing student ID cards
 Primarily forintra-campus applications
 Should be sufficient for signed e-mail (S/MIME)
 Simple CP/CPS single document
     See http://middleware.internet2.edu/hepki-tag/
 CREN     may issue the authority certs