Functions of an X.509 Certification Authority (CA) esMD AoR Functions of an X.509 Certification Authority (CA)
CAs and trusted online transactions Table of Contents Slide Title 3 Trust and PKI 8 Certification Authorities 14 Certificates 19 Identity Proofing 24 PKI Services 28 Direct Transaction Process 29 Direct Provisioning 30 Q & A 31 Acknowledgements 32 About DigiCert
Trust Trust occurs between people: Technology by itself is not sufficient to solve “Trust” issues A Trust Framework is a set of standards that combines technology with policies on how and when a technology is utilized/applied, who the participants are, and what their roles and responsibilities are in the system Public Key Infrastructures are a common methodology for implementing trust frameworks
What is PKI? Public Key Infrastructure Comprehensive security technology and policies using cryptography and standards to enable users to: Identify (authenticate) themselves to network services, access policies, and each other to prove source of origin and destination. Digitally sign electronic documents, email and other data to provide authorization and prove integrity. Encrypt email, data, and other documents to prevent unauthorized access.
Why PKI? Uniform way to address securing many different types of applications Enables reliable authentication, digital signing and encryption of data/documents/identities Overcomes many weaknesses of using password based protocols on open networks Facilitates easy setup of shared secrets between previously unknown parties Strong and proven underlying security technology Widely included in technology products
Applications of PKI Authentication and Authorization of end points in an internet transaction e.g. users and servers, server to server, user to user This is the basis for the SSL protocol used to secure web connections using https. Secure Messaging e-mail (signed and encrypted) Secure instant messaging Electronic signatures Documents, data, agreements Prescriptions, Insurance authorizations, case notes Data encryption Medical records, Diagnostic datasets, Business documents, Financial data, databases, executable code Network data protection (VPN, wireless)
Components of PKI Certification Authority (CA) Policy (CP) & Practices (CPS) Registration Authority (RA) Practices (RPS) Local Registration Agent (LRA) X.509 Digital Certificates Contents Identity, Usage, Public Key, Validation Types Trust Anchors & enablers Root Certificates, issuing authorities, cross-certificates End Entities Client, Server, Device, Group, Role Cryptography Algorithms & Protocols Asymmetric Keys Public Key, Private Key Services Authentication, Digital Signature, Encryption
What is a Certification Authority? An organization that creates, publishes, and revokes certificates. Verifies the information in the certificate, binds identities to cryptographic keys. May outsource identity verification to Registration Authority Protects general security and policies of the system and its records. Allows you to check certificates so you can decide whether to use them in business transactions. Has one or more trusted Roots, called a trust anchor embedded in applications
What is a Registration Authority? An organization that collects and verifies the identity information that will be used in a certificate based on published standards. Represents a Certification Authority for any face-to-face validation of identity Must be authorized by the relevant Certification Authority for this purpose Audit of processes required Archival of evidence data required
CA – RA Relationship Certificate Authority (CA) Audit Identity/Trust Verification Certificate Validation Service Certification Practices Statement Certificate Signing Services Revocation Services Audit Registration Practices Statement Audit RA Agreement Registration Authority (RA) Compile/Validate Identity and Trust Documentation Source: DirectTrust.org February, 2012
Health Information Service Provider (HISP) Duties of a HISP: provide subscribers with account and Direct addresses provide web portal or EHR/PHR integration arrange for identity verification - org and individual [RA function] arrange for digital certificate issuance, management [CA function] maintain integrity of trust and security framework stay current with federal policies and regulations
HISP Configurations HISP HISP HISP HISP A HISP may run its own CA, but outsource RA functions to an accredited RA A HISP may run its own CA, and RA functions internally HISP HISP A HISP may run its own RA, but outsource CA functions to an accredited CA A HISP may outsource both CA and RA functions to accredited entities HISP HISP
What is a Certificate? Signed data structure (x.509 standard) binds some information to a public key. Trusted entity, called a Certification Authority (CA) asserts validity of information in the certificate, enforces policies for issuing certificates. Certificate information is usually a personal identity, a server name, or a service identifier, with authorizations for how the keys should be used. Think of a certificate with its keys as an electronic: ID card, encoder/decoder device, and official seal or notary-style stamp.
X.509 Certificate
X.509 Certificate
X.509 Certificate
Types of Certificates DigiCert issues a number of different types of certificates. These are governed by the policy(s) they are issued under and the profile being applied: SSL certificates (standard, Wildcard*, UC) EV, OV, DV Code Signing (including EV Code Signing) Client Certificate (individual, group, role) Level 1 Personal, level 1 Enterprise, Level 2 Corporate, Level 3 High Assurance / FBCA med / Direct, Level 4 High Hardware Assurance / FBCA Medium Hardware, PIV-I Authentication Only IGTF & Grid-Only Device and Host certificates L1 through L4
Identity Proofing for Certificates Cert Type Identity Vetting Required Level 1 Client Certificates – Personal (email certificates) (Equivalent to NIST 800‐63/Kantara Level 1 and FBCA CP Rudimentary) Applicant's control of the email address or website listed in the certificate. Level 1 Client Certificates ‐ Enterprise (Equivalent to NIST 800‐63/Kantara Level 1, FBCA CP Rudimentary and Citizen & Commerce Class Common CP (C4) Assurance Level‐2.16.840.1.101.3.2.1.14.2) Any one of the following: 1. In‐person appearance before a Registration Authority or Trusted Agent with presentment of an identity credential (e.g., driver's license or birth certificate). 2. Using procedures similar to those used when applying for consumer credit and authenticated through information in consumer credit databases or government records, such as: a. the ability to place or receive calls from a given number; or b. the ability to obtain mail sent to a known physical address. 3. Through information derived from an ongoing business relationship with the credential provider or a partner company (e.g., a financial institution, airline, employer, or retail company). Acceptable information includes: a. the ability to obtain mail at the billing address used in the business relationship; b. verification of information established in previous transactions (e.g., previous order number); or c. the ability to place calls from or receive phone calls at a phone number used in previous business transactions. 4. Any method used to validate a Level 2, 3, or 4 Client Certificate.
Identity Proofing for Certificates Cert Type Identity Vetting Required Level 2 Client Certificates and IGTF Classic/MICS Certificates (Equivalent to NIST 800‐63 Level 3/Kantara Levels 2 and 3, and FBCA CP Basic) 1. In‐person proofing before a Registration Authority or Trusted Agent with presentment of a government‐issued photo ID, examined for authenticity and validity. An entity certified by a state, federal, or national entity as authorized to confirm identities may also perform in‐person authentication on behalf of the RA, provided that the certified entity forwards the information collected from the applicant directly to the RA in a secure manner. Packages secured in a tamper‐evident manner by the certified entity satisfy this requirement; other secure methods are also acceptable. Such authentication does not relieve the RA of its responsibility to verify the presented data. 2. Remotely verifying information provided by applicant (including name, date of birth, and current address or telephone number) using (i) a government‐issued photo ID and (ii) one additional form of ID such as another government‐issued ID, an employee or student ID card number, a financial account number (e.g., checking account, savings account, loan or credit card), or a utility service account number (e.g., electricity, gas, or water) for an address matching the applicant’s residence. The CA or an RA confirms that the following are consistent with the application and sufficient to identify a unique individual: (a) the name on the referenced photo‐ID; (b) date of birth; and (c) current address or personal telephone number. DigiCert or an RA may confirm an address by issuing credentials in a manner that confirms the address of record and may confirm a telephone number by recording the applicant’s voice during a communication after associating the telephone number with the applicant in records available to DigiCert or the RA. DigiCert or an RA may request additional information if necessary to ensure a unique identity and may use alternative information if it leads to at least the same degree of certitude when verified. 3. Where DigiCert or an RA has a current and ongoing relationship with the Applicant, identity may be verified through the exchange of a previously exchanged shared secret (e.g., a PIN or password) that meets or exceeds NIST SP 800‐63 Level 2 entropy requirements, provided that: (a) identity was originally established with the degree of rigor equivalent to that required in 1 or 2 above using a government‐issued photo‐ID, and (b) an ongoing relationship exists sufficient to ensure the Applicant’s continued personal possession of the shared secret. 4. Any of the methods used to verify the identity of an applicant for a DigiCert Level 3 or 4 Client Certificate.
Identity Proofing for Certificates Cert Type Identity Vetting Required Level 3 Client Certificates (Equivalent to NIST 800‐63/Kantara Level 3 and FBCA CP Medium and Medium Hardware) In‐person proofing before an RA, Trusted Agent, or an entity certified by a state, federal, or national entity that is authorized to confirm identities. A certified entity must forward the collected information directly to DigiCert or an RA in a secure manner. The Applicant must supply one unexpired Federal/National Government‐issued Picture I.D. (e.g. a passport), a REAL ID, or two unexpired Non‐Federal Government I.D.s, one of which must be a photo I.D. (e.g., driver’s license). DigiCert or an RA examines the credentials for authenticity and validity. For each Level 3 Client Certificate issued, DigiCert or the RA reviews and records a Declaration of Identity that is signed by both the Applicant and the person performing the in‐person identification. DigiCert or an RA may request additional information if necessary and perform database record checks to corroborate an Applicant’s name, date of birth, current address of record, and other personal information sufficient to ensure a unique identity. A trust relationship between an RA or Trusted Agent and the applicant that is based on an in‐person antecedent (as defined in FBCA Supplementary Antecedent, In‐Person Definition) suffices as meeting the in‐person identity proofing requirement provided that (1) it meets the thoroughness and rigor of in‐person proofing described above, (2) supporting ID proofing artifacts exist to substantiate the antecedent relationship, and (3) mechanisms are in place that bind the individual to the asserted identity. For all Level 3 Client Certificates, the identity of the Applicant must be established no earlier than 30 days prior to initial certificate issuance.
Identity Proofing for Certificates Cert Type Identity Vetting Required Level 4 Client Certificates (Biometric ID certificates) (Equivalent to NIST 800‐63/Kantara Level 4 and FBCA CP Medium Hardware) In‐person proofing before an RA, Trusted Agent, or an entity certified by a state, federal, or national entity that is authorized to confirm identities. A certified entity must forward the collected information directly to an RA in a secure manner. The Applicant must supply one unexpired Federal/National Government‐issued Picture I.D. (e.g. a passport), a REAL ID, or two unexpired Non‐Federal Government I.D.s, one of which must be a photo I.D. (e.g., driver’s license). The entity collecting the credentials must also obtain at least one form of biometric data (e.g. photograph or fingerprints) to ensure that the Applicant cannot repudiate the application. DigiCert or an RA examines the credentials for authenticity and validity. For each Level 4 Client Certificate issued, DigiCert or the RA reviews and records a Declaration of Identity which shall be signed by the applicant and the person performing the in‐person identification. For all Level 4 Client Certificates, the use of an in‐person antecedent is not applicable, and DigiCert establishes the identity no more than 30 days prior to initial certificate issuance. Level 4 Client Certificates are issued in a manner that confirms the Applicant’s address of record. Organizational Identity with Domain Names DigiCert validates the Applicant’s right to use the domain names that will be listed in the certificate using one or more procedures including: A domain authorization letter, provided the letter contains the certificate requester’s letterhead, the signature of an authorized entity, a date that is on or after the certificate request, a list of the approved fully‐qualified domain name(s), and a statement granting the Applicant the right to use the domain names in the certificate. DigiCert also contacts the domain name holder using a reliable third‐party data source to confirm the authenticity of the domain authorization letter. Organizational Identity If the certificate contains organization information, DigiCert obtains documentation from the organization sufficient to confirm that the individual has an affiliation with the organization named in the certificate.
Identity Proofing for Certificates Group Certificates DigiCert may issue a group certificate (a certificate that corresponds to a Private Key that is shared by multiple Subscribers) if several entities are acting in one capacity and if non‐repudiation is not required. DigiCert or the RA records the information identified above for a sponsor before issuing a group certificate. The sponsor must be at least an Information Systems Security Officer or of the equivalent rank or greater within the organization. For Direct certificates, the HISP ISSO and the Provider organization representative are both validated Device Certificates DigiCert issues Level 1, 2, 3 or 4 Client and Federated Device Certificates for use on computing or network devices, provided that the entity owning the device is listed as the subject. In all cases, the device has a human sponsor who provides: Equipment identification (e.g., serial number) or service name (e.g., DNS name), Equipment public keys, Equipment authorizations and attributes (if any are to be included in the certificate), and Contact information. Sponsor is also vetted according to processes defined of individual at required LoA Identity is revalidated according to the following schedule: Device Certs: at least every 39 months Individual Certs (levels 1 thru 4): at least every 9 years (if 3-year cert)
PKI Services Certificates (containing public keys) and corresponding private keys are used to provide a range of cryptographic services: Confidentiality (encryption) Integrity (digital signature) Authentication (digital signature) Multiple algorithms and standards can be used Federal Information Processing Standards (FIPS) exists for federal agencies e.g. FIPS 186 for Digital Signatures
Encryption Asymmetric encryption prevents need for shared secrets. Anyone encrypts with public key of recipient. Requires some mechanism for discovering intended recipient’s public key Only the recipient can decrypt with their private key. Private key is secret, so “bad guys” can’t read encrypted data.
Digital Signatures Compute message digest, encrypt with your private key. Reader decrypts with your public key. Re-compute the digest and verify match with original – guarantees no one has modified signed data. Only signer has private key, so no one else can spoof their digital signature.
Authentication A CA - Certification Authority, signs a certificate attesting that the public key belongs to the entity named in the certificate Certificate Policy indicates what steps are taken to verify identity and how the CA systems operate to ensure security and integrity CA is a Trusted Third Party providing a seal of authenticity Use of certificate provides reliability and non-repudiation in the identity of the source or destination of a transaction public public
Transactions Certificates vetted to FBCA Medium LoA standard ensures strongest binding between PKI keys and identity listed in the cert HIPAA Covered Entity Assertion governed by DirectTrust CP PKI Encryption ensures confidentiality in messages PKI Digital Signatures ensures integrity and reliability of messages PKI Authentication provides authenticity and trust of message reaching intended recipients
Direct Identity, Trust, and Address Provisioning Certificate Authority (CA) Identity/Trust Verification Certificate Validation Service Certificate Signing Services Revocation Services The CA and RA enforce the policies specified in the DirectTrust.org and FBCA Certificate Policies (CPs). 6. Certificate Signing Request 7. Direct Organization Certificate 2. Request Direct Organization Certificate Registration Authority (RA) Assume has Digital Identity Certificate 3. Credentials and Documentation Compile/Validate Identity and Trust Documentation HCO Representative Representative FBCA Credentials Representative Authorization Legal Entity Documents Membership/Trust Agreement HIPAA status Healthcare Organization (HCO) 4. Direct Organization Domain 5. CSR + Public Key 8. Direct Organization Certificate Domain Name System (DNS) Health Information Service Provider (HISP) 1. Enroll with HISP 9. Direct Address/ Org Certificate LDAP Name System Source: DirectTrust.org February, 2012
Related CA Questions and Answers What ability is there to issue multiple digital credentials with one identity proofing? This is perfectly allowable process, typically an already credentialed entity presents their original certificate as proof of identity binding and can be issued a certificate of equal or less LoA Identity must be revalidated periodically via original process (at least 39 months for device, 9 years for individual (including group certs) What is the Revocation process DigiCert provides a Managed PKI interface (hosted web portal) that allows for issuance, revocation and renewal of certificates. DigiCert also provides an API (REST-based) for application integration that has similar functionality What about Proxy Certificates for delegation of rights Proxy certificates are issued by end entities and not by a CA. As such they are typically not trusted in browsers without appropriate plugins to circumvent the trust validation up to an embedded Root Proxy certs are used quite successfully in other communities e.g. IGTF and where purpose built application manage them appropriately
Questions? Scott Rea, CISSP VP GOV/EDU Relations and Sr. PKI Architect DigiCert, Inc. Lindon UT 84042 (Also note: Member of DirectTrust.org) Scott@DigiCert.com (801) 701-9636 http://www.digicert.com/news/bios-scott-rea.htm http://www.DigiCert.com/
About DigiCert 146 Countries and Growing! A Few Facts DigiCert – a local interface to your global trust community. DigiCert established in 2003, a Root CA DigiCert’s management has combined about 100 years experience in internet security Frost & Sullivan and Netcraft survey ranks DigiCert 3rd largest high-assurance CA DigiCert is growing fast WebTrust audited DigiCert growing its business globally 146 Countries and Growing!
About DigiCert Who Uses DigiCert? DigiCert provides encryption and authentication services to over 50,000 customers.
DigiCert Trusted Roots About DigiCert DigiCert Trusted Roots DigiCert Trusted Roots Already Embedded In: Web Browsers AOL Firefox Google Chrome Internet Explorer Safari Konqueror Camino Mozilla Netscape Opera Mobile Devices Android OS Blackberry OS iPhone OS Nokia E-Series Phones Palm Symbian OS Windows Mobile
About DigiCert Rapid Growth DigiCert is the 3rd largest provider of high assurance SSL certificates and among the world’s fastest growing companies:
About DigiCert Testimonials DigiCert features more 5-star reviews than any other Certificate Authority on sslshopper.com. Here are a few user-generated quotes: “This company is 5/5 for me, and I’m the kind of guy who could rate something as 4.97 / 5 out of sheer pickiness” (Dec 16, 2010) “These guys have provided the best level of customer service I have ever experienced anywhere.” (Dec 22, 2010) “Miles above the other well known names. Thanks a million to DigiCert and their team” (Oct 22, 2010)
About DigiCert 99.5% Browser Compatibility Unlimited Server License Features DigiCert SSL Certificates Feature: 99.5% Browser Compatibility Unlimited Server License Secure Trust Seal Award-winning 24/7 customer support $1,000,000 Warranty
About DigiCert Managed-PKI Easily manage thousands of SSL certificates with our enterprise-grade, web-based PKI. Instantly approve or reject certificate requests. Intuitive user interface with multiple levels of authority. Assign business units to sub-accounts with limited access. Centralize control while distributing workload.
About DigiCert CA/Browser Forum Industry Leader DigiCert leads the industry toward better practices by participating actively in the following groups: FBCA CA/Browser Forum Four Bridges Forum
About DigiCert Awards DigiCert has been recognized multiple times for its excellence in customer value, customer support and the workplace.