PKI Tutorial
Model Policy Workshop
Ann Geyer - Bill Pankey
tunitas @ earthlink.net
www.tunitas.com
925-631-1244
Session Goals

Prepare participants for Workshop
– Language and application of public key cryptography
– Meaning and use of digital certificates and signatures
 mechanics of certificate use
 lifecycle of digital certificate

Develop common understanding of PKI
– Potential sources of “trust” in a PKI and its use

Introduce the components of a Certificate Authority
– Role and substance of Certificate Policy & Practice Statements
– Software components and business functions

Introduce relevant standards
– From IETF -- PKCS and PKIX
– From ABA -- Digital Signature Guidelines
– From NACHA -- CARAT Guidelines
Agenda

Authentication in Healthcare
– Overview of the problem set

Cryptography Basics
– Security foundation in open networks

Digital Certificates
– Structure of authentication “credentials”

Certificate Issuance and Management
– How certificates are created, maintained, used, and revoked

PKI Trust Models
– How trust can be extended to unknown parties

Certificate Policies
– Support the use of certificates by third parties.
Authentication in Healthcare
Module 1
Authentication in Healthcare
Requirements

Authentication is designed to positively corroborate identity of remote user
or electronic correspondent
– Necessary component of any network security solution
 authentication - authorization - access control - audit
– Necessary condition for disclosure of patient identifiable data

HIPAA, HCFA Internet Policy, industry good practice

Healthcare authentication has specific requirements
– Support unique individual identification as required by HIPAA
– Recognize persistent personal roles (e.g. physician)
 roles assigned to individuals independent of resource or organization
– different organizations respond to a role in a similar way
e.g. all plans contract with physicians as providers and so have similar
authentication requirements
 roles may have presumptive access privileges and disclosure permissions
Authentication in Healthcare
Requirements

Healthcare authentication has specific requirements (cont)
– Must respond to industry reliance on “proxy” roles
 assigned independently of resource by principal, e.g. provider staff

Healthcare context impacts authentication
– Multiple affiliations
– Mesh Industry
– Heterogeneous business relationships
– Heterogeneous computing platforms
– Cost Avoidance
– Regulatory Scrutiny
– Risk Avoidance
Authentication in Healthcare
Value of PKI

Digital certificates & PKI have gained tentative acceptance
as the solution with greatest potential
– Can be very secure
 if authenticated persons accept personal responsibility for key integrity
– Can be highly scalable
 if plans and provider institutions can take advantage of common shared CA
resources
– Can acquire high degree of provider acceptance
 if solution simplifies provider requirements to authenticate self and staff to a large
number of resources
– assumes that plan & institutions will use common CA resources
– Can reduce regulatory risk
 if there is explicit industry recognition of common solutions
 if HCFA supports the creation and adoption of defacto standards and solutions
(HCFA policy & Internet “trial”)
– Can be low cost security solution
 unbundles authentication from application and resource
 allows cost sharing based on a common industry solution
Authentication in Healthcare
PKI Collaboration

Several collaborative models that aim to facilitate a common solution
– Healthcare specific rootCA
 requires significant industry commitment but lacks suitable model
– Domain specific policy management
 instantiated in the userType Management Model
– CMA model for a physician PKI proposed by Tunitas Group
 involves collaboration specific to classes of persons and organizations
 leverages existing professional and trade associations
– vision generally lacking within association management
– Promulgate defacto standard CA vendor for some user classes (buying coalition)
 failed model; excluded vendors have no choice but to respond by working to fracture
the coalition or otherwise abandon the market
– Develop and standardize on the common healthcare certificate requirements to have
greatest impact on interoperability . . .
Authentication in Healthcare
Interoperability Issues

X.509 Standardization
– Defacto implementation standard for digital certificates
– Flexibility at the risk of voiding interoperability
 uneven support for multiple algorithms
– Reliance on imputed semantics at the risk of voiding interoperability
 e.g. special interpretation of DN inserting comments as ou= ;
 e.g. special use of “serial number” say by inserting Employee ID,

Certificate Extensions
– Certificate Profile publishes locally defined fields
– Provides semantics not supported by X.509 standard
 e.g. certificate Type or Class
– Must be understood within domain or otherwise risk voiding interoperability

Certificate Policies
– Policies define appropriate applications of certificate
– Meaning and trustworthiness of certificate depends on policy
 reliance on certificate is by definition reliance on policy
– Interoperability implies common understanding of policy
Authentication in Healthcare
Workshop Goals

Build a FRAMEWORK for consistent and potentially
interoperable healthcare PKI implementations by independent
certificate authorities
– Common healthcare certificate policies and framework
– a Policy Authority provides a sustainable governance model
Secondary Goals

Provide a forum for continuing PKI collaboration

Advance the general understanding of PKI issues and healthcare’s Internet use
– Additional Tunitas Group seminars
 Healthcare use of Internet Mail (late Q1 - Q2)
– s/MIME -- locus point for encryption, SMTP alternatives
 Access control for health Information (Q3)
– multi-level access control using client certificates, directories, and SSL
(technical seminar on the use of SSL in conjunction with authorization DB includes NSAPI & ISAPI)
Authentication in Healthcare
Test Case Applications

Workshop solutions will support authentication mechanisms required by:
– Internet Mail
– Exchange of patient data through extranet
– Non-reputiation of electronically submitted forms
– EDI over the Internet (EDIINT)
– Electronic communication with patients/members

Will use these applications as test cases
Authentication in Healthcare
Internet Mail

Internet mail security requirements
– Encrypt messages to protect the confidentiality of message content
– Provide assurance of correspondent authenticity
 needed for both senders and receivers
 mail addresses and context are not adequate for authentication
– Two potential models
 proprietary “mail” - mailboxes hosted on a secure server
– implies “secure file transfer” ability
– requires partners to support correspondents’ mail processes
 SMTP mail
– messages must be “cryptographically enveloped” and self-authenticating

s/MIME is the defacto secure Internet mail standard
– HCFA explicitly acknowledges suitability of this protocol
– s/MIME is supported by all browsers ( 3.x and later)

s/MIME protocol requires authentication using digital certificates
Authentication in Healthcare
File transfer across Extranets

Requirements
– Mutually assure client & server authenticity
– Protect file integrity and confidentiality during network transit
– Leverage existing client software (e.g. browsers)
– Support connectivity solutions of trading partners

SSL is the defacto internet standard for secure client server exchange
– Provides authentication and “negotiates” encryption parameters
– HCFA explicitly acknowledges its suitability
– Software support found in all browsers (3.x and later)
– “Session layer” protocol which supports HTTP& FTP (among others)
 also object communication with IIOP/SSL and telnet/SSL

SSL requires digital certificates for authentication
– Supports weaker client authentication using login / pswd (optional)
Authentication in Healthcare
Form Signing

Requirements
– Provide non refutable assurance of the identity of an electronic form submitter
 protect against fraud in Medicare billing; anticipated HCFA requirement
– Bind the electronic signature to the electronic document
 SSL binds identity to a session and only indirectly to the information submitted
– Leverage existing client software and language-level APIs

Digital Signature is the defacto standard for electronic signature
– HIPAA mandates that healthcare electronic signature will be a digital signature
– Supported by existing language-level API (JavaScript; Java) and current browser
editions

Digital signatures require digital certificates of signers
Authentication in Healthcare
EDI over the Internet

Requirements from HCFA & HIPAA
– Mutual authentication of trading partner EDI processes
– Encryption

EDIINT is the established protocol for exchanging structured messages
(EDI) over the Internet
– Place structured messages in s/MIME envelope
– Use transport protocol of choice (FTP, HTTP, SMTP )to communicate enveloped EDI
– EDIINT recommendations include message disposition notification to support receipt
and delivery guarantee

EDIINT requires that certificates be issued to trading partner EDI resources
Authentication in Healthcare
Communicating with Patients

Benefits
– Member/patient satisfaction - JAMA reports increased email communication between
physicians and patients
 Need guidelines for appropriate use. Without guidelines and true authentication,
providers significantly exposed
– Support future Privacy Act required patient authorization before disclosure

Requirements
– Positively identify unique patient. Requires corroboration of patient identifier beyond
just name.
 National Patient Identifier ? < not likely >
– Positively identify appropriate parents/caretakers
– Assurance that patient is using appropriate encryption software
– Support very large scale authentication solutions

Digital certificates can support required authentication
– Can be used to bind person identifiers to patient / member ID
– Portability across computing platforms
– Large scale deployments anticipated
Authentication in Healthcare
Communicating with Patients

Digital certificates support the requirements and are expected to be deployed
into consumer markets
– Certificate based security used for corporate intranets and next generation network OS
(NT5, NetWare 5)
 potential to leverage authentication solutions used for the purchaser’s intranet to
support member communication with health plans and providers, e.g. Netscape
employee communications with Prudential Health Plan
– Financial services SET (electronic bank card) initiatives
– Some other drivers
 smart cards in university environments, UCLA certificate project
 Province of Ontario to issue certificates to entire population !!!

Include certificate on “smart card” member enrollment card

Issue member certificates in conjunction with service

Most solutions will requires patient/member directory
– Digital certificates for members
– Online application to bind patient provided credential to unique patient identifiers
– Publish to providers and staff
Cryptography Basics
Module 2
Cryptography Basics

What is Cryptography?

Secret Key Cryptography

Public Key Cryptography

Message Digest

Digital Signature

Standards

Software Considerations
Cryptography Basics
What is cryptography?


The art of scrambling information into gibberish
in a way that allows for a secret method of unscrambling
Ancient roots
– From the Greek: krupto (secret) +
grafh (writing)
– substitute letter with one appearing k digits later
example: {(d,a) (e,b), etc}



Earliest documented use attributed to Julius Caesar
Most popular use in Captain Midnight Secret Decoder Rings
Provides for multiple services
– Confidentiality - controlling who can read and correctly interpret messages
– Integrity checking - assure that message is unaltered
– Authentication - verifying identity
Cryptography Basics
What is cryptography? (cont)


Represents information as numbers where the numbers are the result of
some mathematical manipulation
Terminology:
plaintext

encryption
ciphertext
decryption
Cryptographic schemes usually involve:
– Algorithm
 usually public but can be secret
 knowledge of algorithm alone is insufficient to decrypt ciphertext
– Secret value (key)
 shared by good guys
 analogous to the combination for a combination lock
plaintext
Cryptography Basics
What is cryptography? (cont)

Fundamental Tenets of Cryptography
– Algorithms that have successfully withstood continuous scrutiny and challenge are not
easily compromised
 algorithm “owners” encourage attacks by offering rewards to those who successfully
challenge the algorithm’s strength
– Cryptographic algorithms are efficient to compute
– The number of potential keys is extraordinarily large
 set of all possible keys known as the keyspace

Security of strong algorithms depends upon the size of keyspace
– Effectively, the only known attacks would be brute force attacks
 exhaustively attempt decryption with each possible key
until something intelligible is recovered
 practical strength of the encryption is a function of:
– available computing power
– size of key (40 bit, 56 bit, 128 bit)
Cryptography Basics
Secret Key Cryptography

Single key for encryption and decryption
– typically used for “bulk” encryption
– referred to as “symmetric key” cryptography
insecure channel
plaintext
Encryption
algorithm
ciphertext
Decryption
algorithm
secure channel
secret key (k)
secret key (k)
plaintext
Cryptography Basics
block encryption example
The quick brown fox will meet the lazy dog behind the woodshed tonight at midnight.
Bring plenty of catnip.
plaintext coding
0
0
1
1
1
0
1
0
0
1
...
0
1
0
1
8 bit substitution functions derived
from the key
S1
0
1
1
0
1
loop for n
rounds
0
...
1
1
0
1
1
1
0
1
0
S8
0
0
0
64 - bit intermediate
permutations possibly
based on the key
64 - bit output
ciphertext
0
1
1
0
1
0
1
0
...
0
1
0
0
0
0
1
A5 73 30 6B 7B 27 E6 7C D4 77 6A 5A 79 F5 68 35 82 0D FF EA F1 ...
1
Cryptography Basics
Secret Key Cryptography (cont)

Example
1 Alice encrypts message using key, K
2 Alice securely shares K with Bob
3 Alice transmits ciphertext to Bob over insecure channel
4

Bob decrypts ciphertext using K
Issues
– Alice and Bob must agree upon choice of algorithm
– Key Management Alice and Bob must securely communicate shared key
 out of band via some private method
 in band using public key methods
Cryptography Basics
Secret Key Cryptography (cont)

Advantages
– Relative “simplicity”
– Computational efficiency
 linear “computational complexity” i.e. proportional to message length

Some Algorithms
– DEA (data encryption algorithm)
 AKA DES - (Data Encryption Standard ) currently FIPS* encryption
 multiple variants 40 bit, 56bit, triple DES (112bit,168 bit)
 56 bit DES current defacto standard for bulk encryption
– AES (Advanced Encryption Standard)


once selected will replace DES as the FIPS
candidates include CAST-256, DEAL, RC6, SAFER+
* Federal information processing standard
Cryptography Basics
Public Key Cryptography

Different but related keys for encryption and decryption
– typically used for “signature” and key exchange
– aka, “symmetric key” cryptography
– related keys called key pair - private key & public key
insecure channel
plaintext
Encryption
ciphertext
algorithm
public key (k)
Decryption
algorithm
private key (k*)
reliable channel
e.g.. secure directory
plaintext
Cryptography Basics
Public Key Cryptography (cont)

Fundamental Tenets of Public Key Cryptography
– What the public key encrypts, the private key decrypts, and
what the private key encrypts, the public key decrypt
– As a practical matter, security is based on the non-feasibility of computing
one key from knowledge of other key
 deriving the private key from the value of a public key is involves solving what is known
as a hard problem
 In RSA this is equivalent to finding prime factors of very large numbers
– all known solutions are computationally very complex
– computational effort grows exponentially with size of number
– In practice, security depends upon keeping the association of public and private key secure
Cryptography Basics
Public Key Cryptography (cont)

Ownership
– Public key pairs are “owned” and identified with persons or other entities
– Ownership of public key is published and widely known;
the related private key kept under strict control of owner

Example
1 Alice encrypts message using Bob’s public key
2 Alice transmits cipher text over insecure channel
3
Bob decrypts message using Bob’s private key
Cryptography Basics
Public Key Cryptography (cont)

RSA: example of public key algorithm
– First practical public key algorithm
 widely implemented; defacto international standard for signatures
– Public keys are very large prime numbers, typically 1024 bits (~350 digits) or larger
 density of primes decreases with size, require very large primes to assure an
effectively large key space
– Encryption / decryption involves exponentiation with keys
 computational requirement limits practical use to small plaintext

Other Public Key Examples
– Digital Signature Standard (DSS)
 digital signature only
– Diffie-Hellman Key Exchange
 used with DSS for key exchange
– Elliptic Curve Cryptosystem (ECC)
 order of magnitude more complicated and stronger than RSA
 implemented in chips for niche markets
 high performance / more efficient use of key space than RSA
Cryptograhy Basics
RSA encryption example
mySecretKey
standard encoding of message (PKCS #1)
BER (basic encoding rules)
DER (distinguished encoding rules)
0 0 1 1 1 0 1 1 0 1 0 1 0 1 1 1 0 0 1 0 1 1 1 0 0 1 0 1 0 0 1 0 1 1 1 0 1 1 1 0 0 1 0 1 0 0 1 0 0 1 1 0 1 0 1 0 0 1 0 1 0 1 1 0
encoded message = m (a number)
<k,n> (a public key)
number
cruncher
(exponentiation modulo n )
decryption similar;
use related
private key, k*
K*
c mod n = m
mkmod n = c
exponrents are very large (on the order of
350 digits i.e.1024 bits)
(ciphertext)
a5 73 30 6b 7b 27 e6 7c d4 77 6a 5a 79 f5 68
35 82 0d ff ea f1 2e da 10 53 68 6a 11 eb 42
dd 59 0d ba 41 4c 41 0e bf d5 9c 82 90 4c 1c
21 8b 44 0e 6a 51 d8 21 ad 52 18 bf a0 d7 ce
0a 2e e6 b9 0c 2a db b6 79 ef
ciphertext
Cryptography Basics
Message Digest

Summarizes content of message
– Aka “one-way hash”
– Maps variable length message into fixed length digest

Fundamental properties of message digest
– “One way” function
 message determines digest;
 digest does not uniquely determine message
– Easy to compute, hard to invert

Digest verifies message integrity
– Compute message digest
– Compare with a digest transmitted with the message
 requires secure channel or “signature”

Examples
– MD5 (Message Digest 5) - 128 bit digest
– SHA (Secure Hash Algorithm) - 160 bit digest
Cryptography Basics
Public Key Digital Signature

Verifies origin & integrity of transmitted message
verify
hash
Message
Digest
insecure channel
sign
Encryption
algorithm
message’s
digital signature
Recompute
digest and
compare w/
transmitted
signature
Decryption
algorithm
private key (k)
reliable channel
e.g. secure directory
public key (k*)
Cryptography Basics
Public Key Digital Signature (cont)

Supports non-repudiation
– Signature confirms application of signer’s private key
 only holder of private key can generate identical signature
– Requires protection against invalid public key
 PKI or secure directory provides that protection

Can be combined with encryption to support both confidentiality and nonrepudiation
Cryptography Basics
Exchange of Session Keys

Using public key encryption to exchange a symmetric (session or message)
encryption key
generate key
and sign
Encryption
algorithm
insecure channel
encrypted
session key
extract key
and verify
signature
Decryption
algorithm
Alice
Bob's public key (k)
reliable channel
e.g. secure directory
bob
Bob's private key (k*)
Cryptography Basics
Standards

Symmetric key standards from NIST
– DES
– AES
– Federal Information Processing Standard (FIPS)

Public Key Cryptography Standards (PKCS)
– Promulgated by RSA
– Multiple parts supporting different aspects of public key crypto
 some PKCS standards are superceded by PKIX
– Examples
 PKCS #1 (Public Key Standard) signing and encrypting with RSA
 PKCS #7 (cryptographic message syntax)
 PKCS #11 (crypto standard for smart cards, PCMCIA devices)
 PKCS #13 (elliptic curve cryptosystem) signing and encrypting with ECC
Cryptography Basics
Computer Issues

Sources of transparent (to the app) support for cryptography
– Operating system
 NT, Novell NetWare
– omnipresent in next generation OS
– Application Server Platforms
 session layer encryption
– e.g. Netscape SuiteSpot or other SSL compliant

Security Frameworks to embed cryptography services into applications
– Does not require extensive cryptography knowledge
 may be appropriate for enabling legacy applications
– RSA PKI Framework
– Netscape Security Services
– IBM KeyWorks
Cryptography Basics
Computer Issues

Major Cryptographic APIs (CAPI)
– Use requires knowledge of cryptography basics
 to manage cryptography functions
 requires modules that support low level cryptography functions
– CDSA (Common Data Security Architecture)
 applications can be written as algorithm independent
 supports “pluggable” crypto
– Microsoft CryptoAPI
 proprietary version of pluggable crypto
– GSS (Generic Security Service)
 distributed protocols, e.g. peer entity (object) authentication
 IETF developed and supported
– JAVA Security API

“Cryptographic Service Providers” (toolkits)
– code modules that implement cryptography algorithms
 RSA, Microsoft CSP, Cyclink, Certicom …
Cryptography Basics
Basic References

Good Textbooks
– Network Security, Private Communication in a Public World
 Charlie Kaufman et al (mathematical introduction)
– Applied Cryptography: Protocols, Algorithms and Source
 Bruce Schneier (classic text)
– Email Security
 Bruce Schneier (informal introduction)

Cryptography resources on the Internet
– RSA Laboratories; http://www.rsa.com
 leading crypto vendor; links
– CounterPane Systems; http://www.counterpane.com/
 Bruce Scheier’s company
 includes an online crypto course and critical analyses of current events
– Microsoft
http://www.microsoft.com/security/tech/cryptoapi/default.asp?ID=22&Parent=4
 FAQ, links and information on MSFT’s CryptoAPI
Digital Certificates
Module 3
Digital Certificates

What are digital certificates?

Architecture
– Subject identification
– Algorithms and attestations
– Extensions
– Form and format

Implementation
– Ownership assumptions
– Software considerations and models
– Hardware devices

Relevant Standards
Digital Certificates
What are digital certificates?

A “credential” that identifies a person, resource or “entity”

Formally, a signed data structure
– Specifies that a specific public key is owned by a specific named entity
– Generally, ownership of public key implies “exclusive” control of related private key
– Named entity can be person, server, software agent or other object
– Signature “binds” the public key to its named owner (subject)

Support attribution of private key use to the subject
– Allows for encrypt messages for specific individual without prior key exchange
– Non reputation of digital signature

Used extensively in Internet security protocols
– s/MIME, TLS / SSL, IPsec
Digital Certificates
What are digital certificates? (cont)
controls use >
Private Key
1
1
1
Name
/ owner
1
signs >
1
Issuer
*
1
binds >
Entity
*
Certificate
Name
Public Key
Attestation
Public Key
Digital Certificates
Architecture - Required Info

Certificate Information
– Serial Number - unique to certificate authority
– Validity period
 date first valid / date expired
– Signature algorithm

Authority Information
– Unique name of issuer

Subject Information
– Unique name of subject
– Subject public key
– Subject public key algorithm (usually RSA)

Digital Signature
– Using issuer’s private key
Digital Certificates
Architecture - Optional Info

Standard Extensions support additional CA attestation
– Subject and Issuer Attributes
 e.g. altNameExtension
– Key Use
 e.g. certificateType
Used to further identify certificate actors
Defines intended use by class of application
(s/MIME, SSL. …)
– Certificate Constraints
 e.g. pathLengthConstraint
Limits certification chain, i.e who can use the cert
 e.g. nameConstraint
Restricts signing ability to specific X.500 subtree
– Policy Extensions
 Identify policies of CA used to issue this certificate

Extensions may or may not be “critical”
– Relying party must be able to meaningfully process extensions. If not, then the
certificate can not be used for authentication and must be rejected
 Reliance on certificates forces prior recognition of the CA’s practice statement
prior to certificate use
Digital Certificates
Architecture - Customization

Custom Extensions support additional requirements imposed by a CA or
user community
– Support added semantics of user community
 e.g. Specialization
 e.g. nationalProvbiderIdentifier
 e.g. authorizedDelegateFor
– Attribute values will be attested to by CA
 CA must leave unspecified if unknown
– Standard syntax for definition (ASN and BER)

“Certificate Profile” includes
– Definition of all custom extensions
– Standard extensions
– Algorithms
Digital Certificates
CMA MediPass example
Digital Certificates
Architecture - Subject DN

Subject Distinguished Name (DN)
– Name for the public key owner
– Follows the X.500 distinguished name format

e.g.. cn=common name, ou=department name, o= organization, c=country

X.500 provides standard “components of DN”

can use other DN components
– e.g. uid=userID, e=email address, l=locality
– vendor support sometimes uneven for other than c=, o=, ou=, c=, e=
– X.500 presumes unique DN for every individual
 based on subordination and location
– X.509 anticipates but does not require assigned DN’s will be “globally” unique
 uniqueness defined and enforced within a domain
Digital Certificates
Architecture - Subject DN (cont)

Namespace design is a critical cost factor
– Robustness of certificate solution is dependent on the stability of DN
 change in DN requires reissue of certificates
 benefit of stable name assignment
– Require simple solutions to avoid name “collisions”
 arbitrary jDoe, JohnDoe, JohnDoe1, JohnDoe2
solutions are costly to create and support

Namespace design is a critical interoperability factor
– Interoperability implies cross domain recognition & meaning
 problematic for providers with multiple affiliation
 problematic for providers known in different contexts
– cn=DrBobJones, ou=HillPhysicians, o=BlueShieldHMO
– cn=DrBobJones, ou=DrBobJonesPA, o=BlueCrossPPO
– are these the same person?
AXIOM:
Names that may be simple for the issuer may be complex for the subject and
unrecognizable by the subject’s peers
Digital Certificates
Architecture - Subject DN (cont)

Namespace design considerations
– Subject “distinguished name” (DN) should be meaningful
 unique in some well defined context
– reflect real world ways in distinguishing real world entities
 simplifies certificate management
– Robustness requires simplicity and stability across
 multiple affiliations for typical providerPersons
 organizational restructuring
– e.g.. cn=DrBobJones, ou=FriendlyHills, o=TakeCare
– Interoperability requires mutual understanding of namespace
 root names in broadest context
– Flatter structures are more stable but uniqueness bigger issue
 e.g. e=emailAddr, cn= common name, ou=Physician, o=CMA.org
 eg. uid=MedLicense#, l=state, o=physicianPersons
Digital Certificates
Architecture - Alternate Names

subjectAltName used for optional name attribute
– Allows additional (1 or more) identities to be bound to certificate
– Options include:
 electronic mail addresses
 DN names, e.g.
– subjectAltName=4567829.PP0.BlueShield
 IP addresses
 URI (uniform resource identifiers)
 other X.500 names !!!
 locally definition
– Issuer must confirm each subjectAltName
– Not well supported in client software
 browsers generally don’t parse and display
Digital Certificates
Implementation - Ownership

Digital certificates contain only PUBLIC information

Public key & certificate “owned” through control over the related private key
– Private key maintained in some sort of persistent store, for example:
 desktop “key rings” protected by owner selected/maintained passphrase
– browsers and mail clients
– PKCS #12 provides specification
 hardware devices under physical control of owner
– PCMCIA (fortezza) cards, JAVA crypto rings, chip cards
– Model does not imply that use control must be direct

for example, model can support “proxy management” by subject
– proxy maintains private key, subject control's proxy’s use of subject’s private key by
a client application
– requires high degree of trust in proxy & special liability model
Digital Certificates
Implementation - Netscape

Private Key Management in Netscape 4.x
– Client certificates are maintained in certificate DB on the desktop (cert.db)
– When first issued a certificate, subject assign passphrase to protect key ring
– Owners can assign a variety of security levels to key ring, e.g.:
 prompt for password once a session
 prompt for password every time a certificate requested
– Netscape also supports interface to external key storage, e.g. smart cards through
PKCS #11 interface

Demo
Digital Certificates
Issues - Portability


Private keys are typically installed on PCs, but users want workstation
independence
Two approaches:
– Export key ring to portable media (floppy) and reinstall on other devices as needed,
i.e. “backup to disk”
 PKCS #12 defines similar procedure for key backup
– Install private key to portable device such as smart cards, PCMCIA devices, crypto
rings
 PKCS #11 provides Crypto API for these devices
– Netscape support
 device manufacturers provide interfaces to browsers and mail clients
 2 factor authentication model
– insert device (e.g. smart card)
– respond to password prompt to “unlock” key ring
Digital Certificates
Smart (Chip) Cards

Anticipated to be principal store for client certificates
– Standards are complete
– Microsoft & Intel include smart capability in 1999 PC manufacturers guide as a
“Recommendation” to support smart card readers
 Changes to “Required” status in 2000.
 Adherence to guide necessary for “Windows Compatible” labels
– Windows 2000 (NT 5) supports smart card authentication natively

Two factor authentication
– Smart card is PIN (4-8 digits) protected
 3 unsuccessful tries results in card lockdown requiring card reissue
Digital Certificates
Standards

X.509 Standard
– Created to provide credentials for X.500 directory objects
– V1 published as part of X.500 directory recommendations
 V1 (1988) - V2 (1993)
 V1 & V2 inadequate for PEM (privacy enhanced mail) applications
– V3 (1996) added much flexibility
 added provisions for “extension” fields (“V3 extensions”)
– V3 use pretty much universal for Internet applications
 supports mail, c/s, IPsec
 alternatives limited to special purposes, e.g PGP certificates

PKIX IETF standards and drafts
– Intended to provide Internet with components missing from X.509
 X.509 rewrite according to IETF specs
– Protocols for certificate creation and management
 e.g. certificate requests, revocation lists
 added profile and policy definitions
Digital Certificates
Standards

X.509 defined to support a high degree of inter-operability
– Independent of application, language, platform & vendor
 supports wide range of applications and environments
 e.g. interoperability between Japanese issued certificates stored on a Java ring
with Internet kiosk in a New York library
 e.g. SET (secure electronic transactions) designed to support electronic
commerce worldwide
– Significant issues in coding certificates
 uses ASN.1 (Abstract Syntax Notation) and BER
 requires self describing data
– data which includes the format for interpreting data
 very robust but has significant overhead costs
– very verbose
– parsing issues; must parse string before an awareness of the type of string with deeply nested structures this can be very difficult
Certificate Issuance
&
Management
Module 4
Certificate Management

Certificate Actors and Basic Transactions

Certificate LifeCycle

Role of Directories

Costs and Business Models
Certificate Management
Actors

Principal Actors in the life of certificate
– Subject
 owner of public key
– Certificate Authority (CA)
 Issuer of certificate - signs certificate
– Registration Authority (RA, sometimes ORA or LRA)
 assumes some administrative functions
 typically vouches for binding between public keys and certificate holders
– Relying Parties (Acceptors)
 validate digital signatures
– Repositories that store certificates and revocation lists
 internal to CA
 published network directories
 local certificate dB
– Key Recovery Authority
Certificate Management
Lifecycle

Creation of Key Pair

Certification

Transport

Use

Revocation

Recovery
Certificate Management
Key Generation

RSA keys are generated as a key PAIR
– key pair is computable; but deriving one key from the other is not

Locus of pair generation is important
– by Certificate Subject
 private key never need be communicated
 best understood and model supported by PKCS
 model well supported in browsers
– HTML <keygen> tag triggers key pair generation
– by Certificate Authority
 then must securely communicate private key to subject
 requires high degree of trust between subject and CA
 may be appropriate when corporate ownership of keys
– simplifies key escrow
 model supported by NetWare 5 and some Entrust products
 value probably limited to intranet
Certificate Management
Certification

CA must collect Subject Information and Public Key
– Usually obtained from subject's Certificate Request
 There are standards for request form and format
 HTTP request using <keygen> form element
• appropriate to web browser models but limited
– PKCS#10 - usually for server requests
– CRMF (Certificate Request Message Format”) PKIX standard
• overcomes limitations of keygen, more robust as it includes
subject signing of public key; supports key escrow (.ie. supports
secure communication of private key to escrow authority)

CA must confirm validity of Subject Info and request
– Role of “(local) Registration Agent” or (L)RA
– No real standards for “proof” system
 “point” systems (NACHA), but applicability to healthcare unclear

CA signs certificate to attest to Subject Info - Public Key binding
Certificate Management
Certificate Request w/ Browser
SUBJECT
Certificate Authority
Registration Authority
Request Registration Form
HTML form containing <keygen>
Form may come
from "any source"
RA, CA or other
Complete Form
Generate Key Pair
Subject Info plus Public Key
typically SSL
Request Confirmation
agent's
diligence process
SSL or better
Approve Request
Certificate
Create and SIgn
Certificate
Certificate
Directory or
other
Publication
Certificate Management
Certificate Creation - Netscape

Current Netscape Model
– HTML form element <keygen> submitted over HTTPs
– Certificate approval either by
 Auto verification by comparing subject info against database
 RA logging onto a CA process
 Demo
– Simple certificate request / approval / creation using Netscape server

Netscape futures (Certificate Server 4.0 - March ‘99)
– CRMF with more flexibility for request submission
– Distribution of RA and CA functions
Certificate Management
Certificate Server Products

Software Sales Model
– All functions owned and managed by enterprise
– Leading vendors
 Netscape
 Entrust
 Baltimore (Zergo)
 RSA ( at a toolkit level)

Service & Software Model
– Distribute registration and other functions to enterprise while certificate manufacture
occurs at vendor center
– Leading vendors
 VeriSign
 GTE CyberTrust
Certificate Management
Certificate & Key Transport

Certificates contain only public information
– User certificates are self-proving & may be communicated as cleartext (PKCS #7)
– Source of signer certificates is an issue
 “Bootstrap” problem - discussed in the next module
 At some point, relying party must obtain signer certificate from a “trusted” source

“Portability” of Private Keys
– Required to support multiple workstation use
 Physicians in particular certificate portability for seamless access from home, office(s)
and hospital
– Two approaches
 Export to “media” (floppy) and “import” to another workstations
– PKCS #12 mechanism similarly used for key backup
 Use portable devices such as smart cards, PCMCIA devices, crypto rings
– PKCS #11 provides Crypto API for these devices
– 2 -factor authentication uses password prompt to “unlock” key ring
Certificate Management
Certificate Use

Certificate use protocol driven
– SSL /TLS and s/MIME in particular

Basic authentication model binds current user (message sender) to
certificate
– typically with subject signing of authentication message which includes the digital
certificate
 in s/MIME , signed message includes symmetric key used for bulk encryption
 in SSL/TLS , signed message includes a one time nonce to prevent replay of
authentication by third party
 object signing similar
– in general, certificate supports use of the private key
Certificate Management
Certificate Revocation

Certificates must be “revoked” when the subject - key binding is no longer true
or reliable
– When “exclusive control of private key” provisions are compromised
– When the subject information no longer true
 e.g. change in employment or professional status or address

CA must support publication of revocation
– Certificate Revocation List (CRL)
 CA publishes list of all revoked certificates; “delta” lists provide “changes”. The
Relying party periodically updates its local copy of list. Checks to see if target
certificate is included in list.
– Ambiguity in how often Relying Party should “check revocation”
 alternatives: CRL distribution points; cretificate revocation trees
– Online Certificate Status Protocol (OCSP)
 CA provides server that responds to status request for specific certificates with “good”,
“revoked” or unknown
– Alternatives based on LDAP directories
 “userCertificate” is a standard LDAP person attribute
Certificate Management
Certificate Revocation

Revocation Processes
– No standard “revocation request” message
 Revocation request is subject to similar diligence as for a certificate request
– Revocation in case of compromise generally involves action by subject
 Must inform the RA / CA when private key compromised (say by theft of
computer)
 Governed by terms of user agreement
– Registration agent’s diligence required to revoke certificate when subject information
no longer true
 e.g. subject information contained certificate to which the CA has made an
attestation is no longer true,
 e.g. left employment; lost license; terminated PPO affiliation
– s/MIME certificates problematic
 Certificate profile contains an email address
 New certificate is required with every change of email address
Digital Certificates
Key Recovery

Without private key, encrypted data unavailable
– Particularly problematic in case of clinical data with potential impact on care

Archiving of private key is critical, 2 models:
– Self-escrow  owner maintains secure copy of private key
– Third-party escrow
 rely on “Key Recovery Authority”
 Subject to Third Party Rule
1977 Supreme Court ruling created Third Party Rule - There is no expectation of
privacy for information given to third party. Escrowed keys will be available to
government agency upon “mere request” and can be subpoenaed for civil litigation.
Third party rule overrides any contract between cert owner and authority. Some
financial data is exempt by statute; healthcare data may become exempt with
passage of Pivacy legislation; mere HCFA regulation is not sufficient
Digital Certificates
Key Recovery Technical Approaches

Subject “back up” model
– PKCS #12 protocol support to “backup” end user’s key ring
 “Export” to floppy or other device; exported PKCS12 file protected by pass phrase.
 enterprise requires added processes to recover the key in case of non-availability of
user, eg termination, illness

Enterprise repository
– Server based key recovery
 Requires that private key is securely communicate from subject to repository
 Special challenge to store recoverable copy of private key without compromising
“non-reputiation” of digital signature
– less problematic in enterprise environment
– Generally includes a “split-key” model where archived private key protected by
combination of two keys to guard against administrator misuse
– protocols with appropriate crypto under development
– general solutions will appear in next generation certificate server management
systems, eg Netscape Cert Server 4.0 (March ‘99)
Certificate Management
Directories

Directories may store certificates along with other subject information
– userCertificate is a standard LDAP attribute

Certificate publication required to support broad email use
– Certificates required to send secure mail
– How do correspondents acquire certificates
 Desire to minimize “negotiation” prior to secure use

Required for role based access control
– Generally transient roles are not included on a certificate
– Use directory to bind role and other authorization information to certificate subject
– Support distribution of role assignment to trading partners
 e.g. physician
office administrator
billing clerk
Certificate Management
Cost and Business Models

Three models for Certificate Authorities
– Enterprise
 Issue certificates to subordinate employees and resources
 CA owner controls resources to which certificate will authenticate
– CA and PKI become part of network administration, eg Netware 5
 Enterprise ultimately assumes responsibility for misuse
– Public
 CA is fully independent of the certificate subjects and the protected resources
– Hybrid
 Multiple user classes imply different liability (e.g. employee; trading partner)
 Multiple information resources
– Authenticate staff to resources of trading partner
(eg. secure email or access to eligibility data)
Certificate Management
Cost and Business Models

Costs
– Relatively small software cost
 $800 (MSFT) up to $10K + $/cert
– Registration agent’s due diligence costs
 Minimal in case of Enterprise model where merely attesting to existing knowledge
of employee
 May be significant for public CA to verify the subject information included on
certificate
– Liability costs and insurance
 May be limited (somewhat) by user agreements
 Tradeoffs between liability & due diligence costs
– Operations cost for highly secure certificate servers
– Operations costs for high availability revocation publication
– End user support
– Many hidden costs;
 e.g. loss of data with non-availability of private key
 e.g. reduced ability to audit information flows
Certificate Management
Cost and Business Models

Highly variable total cost estimates
– Annual costs anywhere from $2/ cert to $600/ cert
!!!
– Aberdeen Study
 http://www.versign.com/library/reports/Aberdeen/cost/index.html
– Giga Information Corporation
 http://www.entrust.com/news/1998/gigatco.htm

Critical cost factors
– Special requirements of vertical markets or enterprises
 Increased RA due diligence & liability costs
 Increased integration costs for Relying Parties
– depth of certificate “chains”
– End user support
 Multiplicity and criticality of applications
– Integration with enterprise systems
PKI Trust Models
Module 5
PKI Trust Models

Basic Concepts

Certification Paths
– Types
– Constraints

Trust Models
– Direct
– Hierarchical
– Mesh

Browser / Email Client Support

Significant Issues and Alternatives
– “Straw Dog” Alternative
PKI Trust Models
Why Trust?

Advantages of “trusting” certificates issued by others
– Reach
 Can extend communications to previously unknown parties
– Potential for improved reliability
 In the whole, fewer certificates for end users and relying parties
– Efficiency
 Communities can be served by different CAs
(e.g. healthplan can better certify its employees than a public CA)
– Economy
 Cost sharing

Questions
– What is being trusted?
– What is the basis for trust?
– What are the enforcement mechanisms?
PKI Trust Models
Basic Concepts

Fundamental principle of certificate use and acceptance
– The certificate subject is accountable for any use of the private key
 If non-repudiation is not required, this principle can be

How is the principle supported?
– Issuer (CA) has responsibility to assure appropriateness of subject - key binding
 “Proof” appropriate to certificate scope
 Maintain current status and publish revocation
– Subject has responsibility to guard private key
 Protect private key using tools appropriate to subject’s environment
 Notify CA as required if private key compromised
– Relying Party Responsibilities
 Check certificate validity
– Verify signature and revocation status
 Accept restrictions of scope of certificate
PKI Trust Model
Basic Obligations
< authenticates
protect >
inspect >
Private Key
Relying
Party
Subject
Certificate
< verify signature
Subject
Public Key
<<restrictions>>
policy
validity period
Current
Certificate Status
CRL / OCSP
< validate subject - key info
notify of status change >
publish >
Issuer
PKI Trust Models
Basic Concepts (cont)

How is the fundamental principle enforced?
– Contract
 User agreements set responsibilities and remedies
– Legislation, (e.g. State of Calif. digital signature law)
 By statute, presumptive responsibility for key use place
on certificate owner /subject
– Has limited application & is not applicable to “proxy” environments
– Regulation
 HIPAA & healthcare accreditation audits
 Independent audits for public CA’s (AICPA)
– Technology
 Protect keys for the enterprise in a central registry & control subject key access
– Assumes that certificate subjects can’t be relied upon to protect their keys
 This approach not generally appropriate for a healthcare extranet
– Contrary to business and other relationships
– Cost
PKI Trust Models
Certificate Verification

Certificate verification requires having issuer’s public key
( the CA’s Signer Certificate)
– Implies confidence in accuracy of signer certificate
– How is such confidence established?
 Bootstrap problem

Verification mechanisms for signer (CA) certificates
1 Self signed using signer’s own key
 Appropriate for rootCA
 Requires that truth of CA identity - key binding be independently established
– Browser manufacturer support by “pre-installing” public CA keys
(ATT Certificate Services, GTE CyberTrust Global Root)
– CA provides signer certificate when CA issues key to subject
Appropriate for managing domains and private PKI
PKI Trust Models
Certificate Verification (cont)

Verification mechanisms for Signer (CA) certificates
2 Signed by a CA superior in a hierarchy
 Acceptance of the CA’s certificate is derived from acceptance of rootCA
 Appropriate for corporate structures with hierarchical administration
– The rootCA is typically corporate “global” key where divisions, departments have
subordinate keys
– Used for administrative convenience
3 Signed by CA from an independent domain with cross-certification
 Acceptance of one CA derived from acceptance by another (peer) CA
 Cross-licensing may be reciprocal or one way
 May be appropriate for trading partners and well-defined communities of interest
PKI Trust Models
Certification Paths - Example
CA
certificate
chain
root
alice
CA
CA
1
2
CA
CA
11
CA-root signs CA-1 cert
CA-1 signs CA-11 cert
CA-11 signs c cert
CA-root signs
CA-1 cert
b
22
c
Alice can verify certificates c
and b after verifying a chain of
certificates from the CA-root
(whose public key she knows)
through CA-1 to CA-11 to c
and through CA-2 to b
PKI Trust Models
Certification Paths - Example
principal CA - capable of
"bridging" with other domains.
Typically will have some
governing authority
Hierarchic Domain
Mesh Domain
peer CA - self signs
distributes to its cert
holders - cross-licenses
within domain
PKI Trust Models
Certification Path Constraints


Trust is not unbounded
Certificate authority may want to limit “signing” capability of certificates that
it issues
– To limit depth of a “certificate chain”
 Control complexity of certificate hierarchy under CA
– To limit CA liability
– To distinguish between “end user” and other certificates”
 e.g. may provide IPA with signing capability so that the IPA can issue certs to
affiliated practices under its authority;
 end user” certificates to health plan staff.
– Limitations are supported by digital certificate extensions
– Trust may not be transitive
 use nameConstraints on cross-licensing to prevent the following:
 US
Canada
Cuba ; but US does not trust Cuba
PKI Trust Models
Browser support

Local file with rootCA self signed certificates
– Managed by end user
 further determine when cert will be trusted
– May import certificates and trust as a root CA
– Shipped with some rootCA certificates pre-installed
 implicit “defacto” accreditation by browser manufacture
 Verisign, CyperTrust, Thawte. . .
– Support ordered certificate chains from sender to root stored in local file

Can import certificates from trusted directory

Limitations
– Limited support for finding certification paths
– No direct support for cross-certificate pairs
– No support for policy extensions, name constraints, path constraints
– Limited ability to centrally manage dB of trusted certificates
PKI Trust Models
Basis for Trust

Expectations of trust differ depending on relationships
– Subject and Issuer
 Subject is the issuer
 Subject is subordinate to issuer (employee)
 Subject and issuer have independent business relationship
 Public CA - issuer and subject otherwise independent
– Public CA issues certificates to any qualified subject on a fee basis
– Relying Party and Issuer
 Issuer is the Relying Party
 Issuer is a trading or practice partner of relying party
 Public CA - issuer and relying party otherwise independent
– Issuer may or may not be known by relying party
PKI Trust Models
Types

Direct Trust
– Relying party independently verifies each subject - key binding
 Usually by contract - agreement to terms of certificate use
 Role of CA is limited to coding the certificate
– e.g. Verisign or Entrust limited liability certificates used for authentication
purposes
 Maintenance is an issue, contract must address revocation & other terms

Hierarchical Trust
– Relying party trusts rootCA and consequently the rootCA’s certificates as well as those
issued by a subordinate CA
 Principal CA “owns” domain
 Subordinate CA following guidelines of Principal CA (presumably)
 Basic corporate model
– X.509 supports certPathLength and use restrictions
PKI Trust Models
Types

Peer Trust
– CA self signs and cross-licenses with trading partners
 Extends the reach of PKI available to each in reciprocal fashion
 Requires extensive cooperation
– Examples
 Certificates issued by hospital for its staff are accepted by health plan
 Physician certificates issued by one health plan are accepted by second health
plan
PKI Trust Models
Some Criticisms

Emphasis on the “who” rather than the “what” of trust
– e.g. “Approved CA(s)”, but for what purpose?
– Difficult business models
 may wish to limit applicability of cross-licensed certificate
 assumptions of liability differ with respect to different relying parties

No enforcement mechanism for breach of trust
– Particularly problematic with cross-certificate chains

Lack of domain definition
– Appropriate CA for many subjects with multiple affiliations is confusing
 eg for physician: - healthplan, hospital, MG, IPA, state agency, ...

Trust in hierarchical model may not be asymmetric
– Certificate holders in hierarchy may have limited trust of root
 physicians and health plans

Overly complex
– Limited software support for cross-certification
– Especially problematic for certificate revocation
PKI Trust Models
Proposal for a Policy Authority

Policy Authority issues certificate to any healthcare CA(s)
– Results in a single rootCA for a healthcare PKI binding “subordinate” CA to healthcare
certificate policies it supports
– Policy Authority CA supports publication of the CA’s supported policies
 assumes common semantics, i.e. this workshop

Each registered CA is trusted to faithfully implement CA chosen policies
– Subject to audit according to AICPA standards to assure consistency of certificate
practices and the CA’s stated objectives
– Equivalent to inclusion on the State’s “Approved List of Certificate Authorities”

Policy Authority
– Publishes a profile for each registered CA
– Publishes CRL for CA certificates
 probably more proactive - push notification of certificate revocation to Mediator CA
subscribers as the revocation occurs
PKI Trust Models
Proposal for a Policy Authority

Governance
– Policy Authority can be operated as independent agency
 probably, in conjunction with industry CA (for cost savings)
– management responsible to an industry board
– Business model
– Limited functionality and costs
 only a few certs issued; only signer certificates to CA’s
 publish revocation lists (probably OCSP)
 publish healthcare policy definition
 publish “audit” and CA profiles
– Simple revenue model to cover costs
 CA subscriptions

Precedents
– NACHA financial industry trial
– FED PKI will implement something similar
Certificate Policies
Module 6
Certificate Policies

Role of Certificate Policy

Structure of Certificate Policy Statement

Policy Enforcement

Role of Certificate Practice Statements

Next Steps
Certificate Policies
Defined

From X.509 (v3) specification
“A named set of rules that indicates the applicability of a certificate to a particular
community and / or class of application with common security requirements”


Policies are named with an OID (“object identifier”) that assures global
uniqueness
For a given CA, “appropriate use” questions are answered by referring to
the CA’s certificate Policy, e.g.
– Who is being issued certificates, i.e. userType
– What is the basis for issuing these certificates, ie general “proof” requirements
– Characterization of user agreements
– Any special user requirements
– What is the intended use (what applications owned by whom)
Certificate Policies
Policy Example
1. A healthcare organization is an organization which is either a payer or provider as
defined by HIPAA (pg. #). Healthcare PKI certificates may be issued only by a
healthcare organization or its agent.
2. A healthcare providerPerson certificate may be issued only to a person who either
has a NPI (national provider identifier) or is employed by a person or organization
that has an NPI. Every healthcare providerPerson certificate will include the
qualifying NPI. That NPI will be included in a ‘providerIdentifer’ extension <citing
an OID> .
Note that the last two statements in 2) are really conditions on the certificate profile of a
providerPerson certificate
Certificate Policies
Scope

Certificate policies created by Relying Parties represent requirements for
certificate practices and profiles
– Conditions under which certificates are “acceptable” for Relying Party applications

Policies for a given CA are supported by:
– Certificate Practice Statements
 Details specific activity that CA & RA undergo to issue certificates consistent with
policy statement
– Certificate Profile
 Name space architecture, extensions, etc
 How information supporting policy is displayed on certificate

Policies are implemented on a certificate basis
– A given CA can issue classes of certificates under different policies
Certificate Policies
Composition

A CA can implement several consistent policies simultaneously
– Policies required by a number of organizations
 e.g. health plans, local hospital and lab
– Policies required to support different kinds of applications
 e.g. “read” versus “read / write” privileges
 e.g. differential sensitivity of data
– General and specific policies
 e.g. policy required by any Federal Government Agency;
 e.g. policy to support a HCFA requirement

A given certificate can reflect several independent policies
– Certificate policy extension records the OID of all policies under which the certificate
can be issued
Certificate Policies
Policy Enforcement

Policies represent an implied contract that CA faithfully implements the
policies
– Places a limitation on the strength of any contract having cross-certificates and longer
certification chains
 relying parties may not be party to a contract with issuing CA
 potential for many intermediaries with different contractual obligations
– Uncertain test of “faithful compliance”

Independent audits record CA’s compliance with its policy
– AICPA (Amer. Inst. of CPA) standards for audits
 same standards applicable to any “service” contract
 basis for acceptance by State of California (per digital signature law)

Potential for state and federal licensing ( Utah )
– In principle, judgements should be made relative to policy, otherwise licensing will not
be sensitive to vertical market requirements
Certificate Policies
Practice Statements

Describe specific activities that CA/RA will undertake to support certificate
– Issuance -- i.e. diligence process to confirm subject-key binding and subject info
– Revocation -- e.g. frequency of updates

Measure practice statements relative to policy
– Constitutes clearer obligation of CA than does policy statement
– Want close fit between practice and policy
– Some potential to hold CA accountable for implementing practices under E&O insurance

Example of a practice statement
Prior to issuing a physicianProviderPerson certificate, the applicant will sign and return to
the CA a user agreement that was sent to applicant at the address of record maintained by
the State Medical Board.
Certificate Policies
Next Steps

Participant response
– PKI Readiness Survey
– Authentication Requirements Survey

Straw Dog Presentation
– Policy Criteria
– Healthcare Policy Framework
– Specific Healthcare CA Policies

Tunitas Internet Site
– FAQ