Validity Models

Question 1

Certification service provider

Answer 1

• Serves as trust anchor in hierarchical PKIs
• Responsible for correct operation of the PKI
• Trusted third party
• “Home” of the issuer
• Provides entities with PKI services
• Usually composted of various components (authorities)

Question 2

CSP components (authorities)

Answer 2

• Registration authority
• Certification Authority
• Directory Services

Question 3

Registration authority

Answer 3

• Contact point for (prospective) PKI entities
• Register prospective entities
• Establish “customer relationship”
• Accept requests from entities
• Usually online

Question 4

RA: Registration

Answer 4

• Establish identity, contact information, client preferences, billing data, public keys and proof-of-possession (optional)
• Secure “Out-of-Band” communication channel
• Checking the prospective participant’s authorization
• Storing of the registration dataset
• Creation of a unique digital name (for the certificate)

Question 5

Proof of Possession: Certificate request message format

Answer 5

• Defines a PoP field to include PoP information into certificate request messages
• Content of PoP field depend on key type:
  -> Signature keys: signature on a piece of data containing the requestor’s identity
  -> Encryption keys: providing private key to CA/RA, direct method, indirect method
• Key agreement keys: establishing ephemeral key + employing one of the methods defined for encryption keys or providing a MAC over certificate request computed with the ephemeral key

Question 6

PoP: Encryption keys

Answer 6

• Direct: Encrypt a value and have the entity decrypt it
• Indirect: Encrypt the certificate and have the entity decrypt it

Question 7

PoP: Key agreement keys

Answer 7

Establishment of a shared secret key between CSP and entity

Question 8

Secure “Out-of-Band” channel

Answer 8

• Independent of the PKI:
  -> Face-to-Face communication (i.e. local presence)
  -> Previously established shared secrets (e.g. passwords)
  -> Third-party services

Question 9

RA models

Answer 9

• Centralized: One RA for all participants
• Decentralized (Local RA): Different RAs for different participant groups
• Hybrid models: E.g. distributed collection of data, but centralized data management

Question 10

Reasons for decentralization

Answer 10

• Topology (e.g. lots of company branches)
• Separation of responsibilities
• On-site registration
  -> better identification (known requester)
  -> distribution of the cost (registration is time consuming)
  -> less work for the end-entity (e.g. registration at the workplace)
  -> use of established workflows
• Fail-safeness

Question 11

Security requirements for registration

Answer 11

• Correctness of the registration data set
  -> checking during ascertainment
  -> obsolete data refresh
• Enforce the Certificate Policy
  -> Completeness of the registration data set
  -> Authorization
• Data protection
  -> Access control for registration data sets
• Integrity protection of the data
  -> CRC, MAC, digital signature, …
• Availability of the data
  -> Backup
• Verifiability of the processes (auditing acceptability)
  -> Logging

Question 12

Certificate classes

Answer 12

• Not part of X.509 specification
• Classification depends on vendor
• Verisign (not existing anymore) - to differentiate certificate purposes:
  -> Class 1 for individuals, intended for email
  -> Class 2 for organizations, for which proof of identity is required
  -> Class 3 for servers and software signing
• GlobalSign, Secorio - to different strength of identity validation for personal certificates
  -> Class 1 only include the validation of the email address
  -> Class 2 includes more thorough validation (e.g. company existence, passport and/or address validation)
• No universal meaning, mainly marketing purposes

Question 13

Classification for TLS certificates

Answer 13

• Also not part of X.509 standard but commonly agreed
• Describes the strength of performed identity validation
• Indicated via OID in the X.509 Certificate Policies extension
• 3 types:
  -> domain validation (DV), existence & control over domain verified
  -> organization validation (OV), some additional checks regarding the requesting organization
  -> extended validation (EV), thorough validation of the requesting organization

Question 14

EV certificates: Scope

Answer 14

Are intended for use in establishing web-based data communication conduits via TLS/SSL protocols

Question 15

EV certificates: Primary purposes

Answer 15

• Identify the legal entity that controls a website
• Provide reasonable assurance that the website is controlled by a specific legal entity identified by:
  -> name
  -> address of place of business
  -> jurisdiction of incorporation
  -> and registration number
• Enable the encrypted communication of information

Question 16

EV certificates: Secondary purposes

Answer 16

• Establish legitimacy of a business by confirming its legal and physical existence
• Assist in addressing problems related to phishing and other forms of online identity fraud
  -> Make it more difficult to mount phishing and other online identity fraud attacks
  -> Assist companies by providing a tool to better identify themselves and their legitimate websites
  -> Assist law enforcement in investigations including contacting, investigating, or taking legal action against the subject

Question 17

EV certificates: What is verified

Answer 17

• Applicant’s legal existence and identity
• Applicant’s physical existence
• Applicant’s operational existence
• Applicant’s domain name
• Name, title, and authority of contract signer

Question 18

Certification authority

Answer 18

• Conduct issuing tasks
• Use issuer private key(s)
• Handle entity key pairs
• Generate PSEs
• Often offline and physically shielded

Question 19

Directory services

Answer 19

• Publish PKI information
• Deliver PSEs
• Manage certificate lifecycle
• Usually online

Question 20

Chain model - problems

Answer 20

• Signature key compromise
  -> Signatures and time information in certificates are unreliable
  -> Usage of time stamping?
  –> doubling of overhead: issuance and verification
  –> does not fit to business model, infrastructure and processes

Question 21

Certification request construction

Answer 21

1. Requesting entity generates CertificationRequestInfo (DN, Pk, set of attributes)
2. CertificationRequestInfo value signed with the subject entity’s private key
3. CertificationRequestInfo + a signature algorithm identifier + signature value = CertificationRequest

Question 22

Key/certificate life cycle and CA

Answer 22

• Initialization
  -> Registration
  -> Certificate Creation and Key/Certificate Distribution
  -> Certificate Dissemination
  -> Key Backup (if appropriate)
• Issued
  -> Certificate Retrieval
  -> Certificate Validation
  -> Key Recovery
  -> Key Update
• Cancellation
  -> Certificate Expiration
  -> Key History
  -> Key Archive