Public Key Infrastructure
Kryptrografia s verejnými kľúčmi a jej aplikácie
DRAFT podkladov
106754086
1
Obsah
1 Lecture No. 1 – PKI Overview.............................................................................................. 4
2 Lecture No. 2 – Certification Authority components, architecture and key management
life-cycle ........................................................................................................................................ 5
2.1
CA components............................................................................................................ 5
2.2
CA Environmental controls ......................................................................................... 9
2.3
Key management life-cycle ....................................................................................... 10
2.3.1 CA Key generation ................................................................................................ 10
2.3.2 Key storage, backup and recovery......................................................................... 10
2.3.3 CA Public Key Distribution .................................................................................. 10
2.3.4 CA Key escrow ..................................................................................................... 11
2.3.5 CA Key usage ........................................................................................................ 11
2.3.6 CA Key Destruction .............................................................................................. 11
2.3.7 CA Key Archival ................................................................................................... 11
2.3.8 CA Cryptographic Hardware Life Cycle Management ......................................... 12
2.4
Certificate life-cycle .................................................................................................. 12
2.4.1 Subscriber Registration ......................................................................................... 12
2.4.2 Certificate Renewal ............................................................................................... 13
2.4.3 Certificate Rekey ................................................................................................... 13
2.4.4 Certificate Issuance ............................................................................................... 13
2.4.5 Certificate Distribution .......................................................................................... 13
2.4.6 Certificate Revocation ........................................................................................... 13
2.4.7 Certificate Suspension ........................................................................................... 14
2.4.8 Certificate Status Information Processing ............................................................. 14
2.4.9 SCDev Life-cycle Management ............................................................................ 14
3 Lecture No.3 - Certification models and trust models ........................................................ 14
3.1
CA model ................................................................................................................... 15
3.2
PGP ............................................................................................................................ 17
4 Prednáška číslo 4 – Aplikácie PKI ...................................................................................... 18
4.1
Electronic signature formats ...................................................................................... 18
4.1.1 Cryptographic Message Syntax (CMS) ................................................................. 19
4.1.2 XML Signature ...................................................................................................... 20
4.1.3 CAdES ................................................................................................................... 20
4.1.4 XAdES................................................................................................................... 20
5 FDHJG ................................................................................. Error! Bookmark not defined.
6 Lecture No. 5 – Certificates, their formats, profiles ............................................................ 21
6.1
Certificate creation process ........................................................................................ 21
6.2
Certificate format ....................................................................................................... 22
6.3
Certificate profiles .................................................................................................... 23
6.4
CRL format ................................................................................................................ 24
7 Aplikácie v PKI ................................................................................................................... 24
7.1
CA softvér .................................................................................................................. 24
106754086
2
7.2
Softvér pre elektronický podpis ................................................................................. 25
7.3
Elektronická podatelňa .............................................................................................. 25
7.4
e-Voting aplikácie ...................................................................................................... 25
7.5
e-Commerce aplikácie ............................................................................................... 25
8 Prednáška číslo X – Overovanie statusu certifikátu ............................................................ 25
9 Prednáška číslo 7 – Používané kryptografické algoritmy ................................................... 25
10
Prednáška číslo 8 – Používané kryptografické algoritmy .............................................. 26
11
Prednáška číslo 9 – Overovanie platnosti certifikátu ..................................................... 26
12
Legislatíva v EU a SR .................................................................................................... 26
12.1
Direktíva 1999/93/EC ................................................................................................ 26
12.2
Legislatíva SR ............................................................................................................ 27
13
Prednáška číslo 10 – Audit systémov PKI ..................................................................... 30
13.1
Úvod ........................................................................... Error! Bookmark not defined.
13.2
Auditné programy pre CA ......................................................................................... 30
13.3
Metodika KPMG použitá pri výkone auditu CA ....................................................... 31
13.3.1
Fáza I – Plánovanie auditu ................................................................................ 31
13.3.2
Fáza II – Výkon auditu...................................................................................... 32
13.3.3
Fáza III – Tvorba výstupov ............................................................................... 35
13.4
Zhrnutie....................................................................... Error! Bookmark not defined.
13.5
Literatúra..................................................................... Error! Bookmark not defined.
13.6
CA Environmental controls ........................................ Error! Bookmark not defined.
13.7
Key management life-cycle ........................................ Error! Bookmark not defined.
14
Prednáška číslo 11 – TSA ............................................... Error! Bookmark not defined.
15
Prednáška číslo 12 – Legislatíva v SR a EÚ ................... Error! Bookmark not defined.
16
Referencie ....................................................................... Error! Bookmark not defined.
106754086
3
1
Lecture No. 1 – PKI Overview
Definovanie pojmov – CA, certifikát, CRL
Biggest challenge: Ensuring authenticity of public keys. This challenge is mitigated using
certificates.
PKI je nasadzované, aby riešilo:

Confidentiality – ensuring that information is accessible only to those authorized to have
access

Integrity – protection of data and possibility to detect unauthorized changes

Authenticity – the author of the message can be identified

Non-repudiation – the author of the message can not deny
 dôvernosti – šifrovanie so kryptografickými algoritmaqmi s verejnými kľúčmi,
 integrity - elektronický podpis digitálneho odtlačku
 authenticity – digitálny podpis
Objectives for use of PKI:

Ease of cryptographic keys exchange

Possibility to ensure confidentiality, autenticity or integrity.
História

First idea of public key cryptosystems shortly after WW2 - was not realized due to
insufficient computing capacity

First practical system – GCHQ in 1973 invented Clifford Cocks invented “RSA”, though it
remained kept secret

First public „public key cryptosystem“ – Diffie and Hellman key exchange algorithm in
1976

First encryption/signature public key cryptosystem – RSA 1978
106754086
4

Practical implementations – recent years
Princípy kryptografie s verejnými kľúčmi

Symmetric cryptosystems
o

A single key shared between communicating parties
Public key (asymmetric) cryptosystems
o
Each subject owns key pair – private and public key
o
Based on computationaly hard mathematical trap function. Private key is a clue how
to solve it.
o
Public key is distributed to communicating parties in an open form.
o
Private key is kept secret.
o
Private and public key are functionally complimentary.
Porovnanie vlastností kryptosystémov s tajnými a verejnýi kľúčmi:
Symmetric cryptosystems
Public key cryptosystems
Each secured communication channel is
encrypted using different key
To confidentially communicate with A, each
party needs to know only A’s public key
Fast and small keys (>= 128 bits)
Large keys (>= 256 bits) and hence slower
systems
Key agreed over trusted channel
Public keys obtained freely over unsecured
channels
2
2.1
Lecture No. 2 – Certification Authority components, architecture and key
management life-cycle
CA components
CA’s are a mixture of:

People
106754086
5


-
Policy Management Authority
-
Operations personnel
Processes
-
Key Management life-cycle
-
Certificate Management life-cycle
Technology
-
Hardware
-
Software
-
Environment
Vzťahy medzi jednotlivými komponentami v PKI
•
“Back End” Key Operations and Management
106754086
–
Generation of CA/RA Key pairs
–
Secure management of CA private keys
6
•
–
Signing and issuance of approved certificate applications
–
Publication of certificates in a repository
–
Publication of CRLs or OCSP
“Front End” Key Management Functions
–
Entity that reviews, rejects, and/or approves the end users (subscribers)
requests.
–
Authenticates applicant identity
–
Certificate Revocation
–
Renewal and Rekey requests
Obrázok: Logická architektúra CSP (podľa CEN CWA 14167-1:2003)
106754086
7
RA

Entity that reviews, rejects, and/or approves the end users request.

Authenticates subscribers identity

Requests reports and searches for account information,

Downloads Certificate Revocation Lists (CRLs).
Subscribers (End Entities – EE):

Apply for a certificate

Track the status of their application for a certificate

Retrieve their certificate after it is issued

Locate another subscriber’s certificate

Verify a certificate

Renew their certificate

Revoke their certificate
Security requirements




CA (sub CAs)
-
Needs to be VERY secure. Private key must be protected
-
If it’s a root CA it only needs to be available when issuing certificates for subs and
signing of CRLs
-
Does not need to be accessible to EEs
-
Special hardware available to store private key (HSM)
RA (LRAs)
-
Need to be secure. Only RA operators must be able to perform registration activities
-
Availability high. End entities need to be able to register
Directory
-
Needs to be secure
-
High availability requirements. Must network traffic will go to the directory.
-
Performance needs to be very good. If EEs want to verify certificates or do transactions,
bad performance of the directory will effectively disable the PKI.
End Entities
106754086
8
-
Private keys must be protected/secured
-
Connectivity to the directory must be there in order to be able to verify certificates or
retrieve other EE’s certificates.
Certificate policy (CP) - 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. For
example, a particular CP might indicate applicability of a type of certificate to the authentication
of parties engaging in business-to-business transactions for the trading of goods or services
within a given price range.

Sets forth general requirements that must be met to operate PKI

Describes appropriate uses for certificate

Identifies who can participate within the PKI
Certification Practice Statement (CPS) - A statement of the practices that a certification
authority employs in issuing, managing, revoking, and renewing or re-keying certificates.


Outlines the CA’s practices with regard to:
-
certificate issuance and user registration
-
certificate lifetimes and revocation
-
trust model and vetting process
-
certificate publishing practices
Designed for a few purposes:
-
Awareness of customers
-
Limiting liability
-
Outlining procedures for personnel
http://www.ietf.org/rfc/rfc3647.txt RFC 3647 Internet X.509 Public Key
Infrastructure Certificate Policy and Certification Practices
Framework
2.2
CA Environmental controls
Lecture: deliver after Key Management Life Cycle
CPS/CP Management


106754086
Policies and procedures for PKI documentation management
Risk assessment methodology
9


Risk assessment results
Minutes from PMA meetings
Key management life-cycle
2.3
Lecture: deliver as the first part of CA
Source: PKI Controls Matrix, section 3: Key Management Life Cycle Controls
2.3.1
CA Key generation
Control objective: The Certification Authority maintains controls to provide reasonable
assurance that CA key pairs are generated in accordance with industry standards.
Topics:

Usually formalized key generation ceremony is followed to generate the key.

According to security requirements FIPS 140-2 or FIPS 140-1 validated devices are used
2.3.2
Key storage, backup and recovery
Control objective: The Certification Authority maintains controls to provide reasonable
assurance that CA private keys remain confidential and maintain their integrity.
Topics:

CA key management policies and procedures

Backup and recovery policies and procedures

Business continuity plans and/or disaster recovery plans

Offsite storage physical security policies and procedures
2.3.3
CA Public Key Distribution
Control objective: The Certification Authority maintains controls to provide reasonable
assurance that the integrity and authenticity of the CA public key and any associated parameters
are maintained during initial and subsequent distribution.
Topics:

Documentation of the process for the initial distribution of the Root CA public key

Documentation of the process for the subsequent distribution of the Root CA public key

Documentation of the process for having the CA's public key signed by another well-known
CA
106754086
10

Documentation of the process for the periodic rekeying of the CA

PKI vendor product documentation
2.3.4
CA Key escrow
Control objective: The Certification Authority maintains controls to provide reasonable
assurance that escrowed CA private signing keys remain confidential.
2.3.5
CA Key usage
Control objective: The Certification Authority maintains controls to provide reasonable
assurance that CA keys are used only for their intended functions in their intended locations.
Topics:

CA key management policies and procedures

CA key usage policies and procedures
2.3.6
CA Key Destruction
Control objective: The Certification Authority maintains controls to provide reasonable
assurance that CA keys are completely destroyed at the end of the key pair life cycle.
Topics:

CA key management policies and procedures

CA key destruction policies and procedures (actual or proposed)

Cryptographic hardware product documentation
2.3.7
CA Key Archival
Control objective: The Certification Authority maintains controls to provide reasonable
assurance that archived CA keys remain confidential and are never put back into production.
Topics:

CA key management policies and procedures

CA key archival policies and procedures

Procedures for recovery of archived CA keys

CA key destruction policies and procedures.
106754086
11
2.3.8
CA Cryptographic Hardware Life Cycle Management
Control objective: The Certification Authority maintains controls to provide reasonable
assurance that:

access to CA cryptographic hardware is limited to properly authorized individuals and

CA cryptographic hardware is functioning correctly.
Topics:
 device shipment

device receipt

pre-use storage

device installation

device de-installation

device usage
Certificate life-cycle
2.4
The WebTrust for CA
2.4.1
Subscriber Registration
The Certification Authority maintains controls to provide reasonable assurance that:

subscribers are properly identified and authenticated and

subscriber certificate requests are accurate, authorized and complete.
Documents describing this phase:
 Subscriber registration policies and procedures
 Policies and procedures for enrolling external RAs
 Quality control procedures
 Policies and procedures for the processing of incomplete or unvalidated certificate
applications
 Certificate application and validation procedures for issuance of certificates to
Subordinate CAs
The following things should be taken into consideration:
 Required level of identification and set of documents needed for issuance of certificate of
specific legal binding of identity. TBD: defined in some UK material

Nationality of registered person – persons from abroad may be identified based on so called
apostille.
106754086
12

Multiple registration of a group of persons.
2.4.2
Certificate Renewal
The Certification Authority maintains controls to provide reasonable assurance that certificate
renewal requests are accurate, authorized and complete.
2.4.3
Certificate Rekey
The Certification Authority maintains controls to provide reasonable assurance that:

certificate rekey requests and are accurate, authorized and complete and

certificate rekey requests following certificate revocation or expiration are accurate,
authorized and complete.
Documents describing this phase:
 Certificate rekey process documentation

Certificate rekey policies and procedures

Subscriber instructions for certificate rekey
2.4.4
Certificate Issuance
The Certification Authority maintains controls to provide reasonable assurance that new,
renewed and re-keyed certificates are generated and issued in accordance with the CA’s
disclosed business practices.
Documents describing this phase:
 Certificate issuance policies and procedures
2.4.5
Certificate Distribution
The Certification Authority maintains controls to provide reasonable assurance that, upon
issuance, complete and accurate certificates are available to subscribers and relying parties.
2.4.6
Certificate Revocation
The Certification Authority maintains controls to provide reasonable assurance that certificates
are revoked based on authorized and validated certificate revocation requests.
Documents describing this phase:
 Certificate revocation policies and procedures

PKI vendor product documentation
106754086
13
2.4.7
Certificate Suspension
The Certification Authority maintains controls to provide reasonable assurance that certificates
are suspended based on authorized and validated certificate suspension requests.
2.4.8
Certificate Status Information Processing
The Certification Authority maintains controls to provide reasonable assurance that timely,
complete and accurate certificate status information (including Certificate Revocation Lists and
other certificate status mechanisms) is made available to subscribers and relying parties.
Documents describing this phase:

CRL management policies and procedures

Procedures for the archival of CRLs

Online certificate status mechanism policies and procedures

PKI vendor product documentation
Practices of certificate life-cycle management are usually disclosed in Certificate Policy
More information can be obtained in IETF RFC 3647 Internet X.509 Public Key Infrastructure
Certificate Policy and Certification Practices Framework, http://www.ietf.org/rfc/rfc3647.txt.
2.4.9
SCDev Life-cycle Management
The Certification Authority maintains controls to provide reasonable assurance that:

ICC preparation is securely controlled by the CA (or RA);

ICC Application Data File (ADF) preparation is securely controlled by the CA (or RA);

ICC usage is enabled by the CA (or RA) prior to ICC issuance;

ICCs are securely stored and distributed by the CA (or RA);

ICC deactivation and reactivation are securely controlled by the CA (or RA); and

the use of ICCs is securely terminated for ICCs returned to the CA (or RA).
3
Certification models and trust models
Basic issue to be solved on Internet is distinguishing identity and proving that one is the claimed
identity. The basic question is: Is that key really from sender?
Verifying validity of key can be done:

Getting the key face-to-face
106754086
14

Checking key fingerprint by authenticated channel

To Trust that a third party has gone through process of validating it.
The ways how trust can be established:
1. Strict hierarchical
2. networked PKI
3. web browser model
4. user-centric model (web of trust)
CA model
3.1
Acceptance of certificate is upon the user.
Hierarchical
Root
C
A
R
A
C
A
CA
R
A
R
A
R
A
R
A

Root CA top of the hierarchy

Different Cas and sub-Cas beneath the Root

Root CA is the basis of all Trust

Pros Easier management of the Trustnetwork

Cons In case of key compromise chain of trust is gone
Distributed trust architecture
106754086
15
C
A
R
A
C
A
R
A
C
A
R
A
R
A
R
A

There is no Root CA

Trust is divided between different CAs

Through Cross-certification the Cas can build a trust relationship

Pros no Root CA is necessary to provide trust in each other certificates (in case of key
compromise the chain of trust is not lost)

Cons difficult governance model
Web trust
CA
CA
x
y
R
A
R
A
R
A
R
A

There is no Root CA

CA certificates are installed in Web browsers and are trusted

Set of trusted CAs can be changed by the end-user.

Pros flexibility and interoperability
Disadvantages:

Initial decision of trust removed from user. The application accepts or rejects certificates.

Transitive trust in CAs in certificate chains.

Certificates expire in domino effect from issuing CA to subscribers

Cons difficult to assess if CA is reliable (end-users responsibility)
106754086
16
3.2
PGP
Author Philip Zimmerman
Trust is done again by creating signature on public key. There may be more signatures from
different users. Acceptance of the certificate is upon user.
Trust is established by web-of-trust rules, but not transitive trust rules.
Disadvantages:

Impossible to guarantee that one will not use a compromised key.
TBD: Bruce Schneier – obrázok dôvery
Pretty Good Privacy (PGP) is a freeware electronic-mail security program, originally designed
by Philip Zimmermann. It uses IDEA for data encryption, RSA (with keys up to 2047 bits) for
key management and digital signatures, and MD5 as a one-way hash function. PGP’s random
public keys use a probabilistic primality tester, and get their initial seeds from measuring the
user’s keyboard latency while typing. PGP generates random IDEA keys using the method
delineated in ANSI X9.17, Appendix C, with IDEA as the symmetric algorithm instead of DES.
PGP also encrypts the user’s private key using a hashed pass phrase instead of a password.
PGP-encrypted messages have layered security. The only thing a cryptanalyst can learn about an
encrypted message is who the recipient is, assuming he knows the recipient’s key ID. Only after
the recipient decrypts the message does he learn who signed the message, if it is signed.
Contrast this approach with PEM, which leaves quite a bit of information about the sender,
recipient, and message in the unencrypted header. The most interesting aspect of PGP is its
distributed approach to key management (see Section 8.12). There are no key certification
authorities; PGP instead supports a “web of trust.” Every user generates and distributes his own
public key. Users sign each other’s public keys, creating an interconnected community of PGP
users. For example, Alice might physically give her public key to Bob. Bob knows Alice, so he
signs her public key. He then gives the signed key back to her and keeps a copy for himself.
When Alice wants to communicate with Carol, Alice sends Carol a copy of the key Bob signed.
Carol, who already has Bob’s public key (she got it at some other time) and trusts Bob to certify
other people’s keys, verifies his signature on Alice’s key and accepts it as valid. Bob has
introduced Alice to Carol. PGP does not specify a policy for establishing trust; users are free to
decide who they trust and who they do not. PGP provides mechanisms for associating trust with
public keys and for using trust. Each user keeps a collection of signed public keys in a file
called a public-key ring. Each key in the ring has a key legitimacy field that indicates the
degree to which the particular user trusts the validity of the key. The higher the trust level, the
more the user believes the key is legitimate. A signature trust field measures how far the user
trusts the signer to certify the public keys of other users. And finally, an owner trust field I
dicates the degree to which the particular user trusts the key’s owner to sign ot er public keys;
this field is set manually by the user. PGP continuously updates these fields as users supply new
information. Figure 24.7 shows how this model might look for a particular user, Alice. Alice’s
key is at the top, and the owner trust value is ultimate trust. Alice has signed Bob’s, Carol’s,
Dave’s, Ellen’s, and Frank’s keys. She trusts Bob and Carol to sign other people’s public keys,
106754086
17
and she partially trusts Dave and Ellen to sign other people’s public keys. And she trusts Gail to
sign other people’s public keys, even though she has not signed Gail’s key herself. Two
partially trusted signatures may be sufficient to certify a key. Alice believes that Kurt’s key is
legitimate because both Dave and Ellen have signed it. This is not automatic in PGP; Alice can
set her own paranoia level. Just because Alice believes a key to be valid, she does not have to
trust it to sign other people’s keys. She does not trust Frank to sign other people’s public keys,
even though she signed his key herself. And she does not trust Ivan’s signature on Martin’s key,
or Kurt’s signature on Nancy’s key. Owen’s key doesn’t fit into the web anywhere; perhaps
Alice got it from a key server. PGP does not assume that the key is valid; Alice must either
declare the key valid or decide to trust one of the key’s signers. Of course, nothing prevents
Alice from using keys she does not trust. PGP’s job is to alert Alice that the key is not trusted,
not to prevent communications. The weakest link of this whole system is key revocation: It is
impossible to guarantee that no one will use a compromised key. If Alice’s private key is stolen
she can send out something called a key revocation certificate, but since key distribution is ad
hoc and largely word of mouth there is no guarantee that it will reach everyone who has her
public key on his key ring. And as Alice has to sign the key revocation certificate with her
private key; if she loses the key altogether she cannot revoke it.
Existujú porty PGP na rôzne OS – Unix, Windows XP, MS DOS. Sú free (GPG – GNU PG),
alebo komerčné (www.pgp.com ).
TBD: Stinson – Cryptography: theory and Practice
Owner trust field (OTF) – dôvera v predstavovateľov kľúčov nastavená používateľom –
hodnoty – implicitly trusted (podpísané userom), completely trusted, partially trusted, untrusted
Key legitimacy field (KLF) – vypočítaná hodnota, či je kľúč platný alebo neplatný
4
Prednáška číslo 4 – Aplikácie PKI
Security objectives:

Confidentiality

Integrity

Authenticity
e-Podpis, e-Voting,
4.1
Electronic signature formats
Noted down in ASN.1 (Abstract Syntax Notation One, X.208). DER – Distinguished Encoding
Rules for ASN.1, as defined in X.509, Section 8.7
106754086
18
4.1.1
Cryptographic Message Syntax (CMS)
TBD: stručná história
Cryptographic Message Syntax (CMS) – popísané v RFC 3852
Pôvodne RSA PKCS#7 Cryptographic Message Syntax
TBD: stručný popis dátových typov a spôsobu vytvárania správ
Formálna štruktúra správy je:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content
[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
The fields of type ContentInfo have the following meanings:

contentType indicates the type of content. It is an object identifier, which means it is a
unique string of integers assigned by the authority that defines the content type. This
standard defines six content types (see Section 14): data, signedData,
envelopedData, signedAndEnvelopedData, digestedData, and
encryptedData.

content is the content. The field is optional, and if the field is not present, its intended value
must be supplied by other means. Its type is defined along with the object identifier for
contentType.
Popisuje 6 typov obsahu:
DataContent type
The data content type is just an octet string. It shall have ASN.1 type Data:
Data ::= OCTET STRING
The data content type is intended to refer to arbitrary octet strings, such as ASCII text files; the
interpretation is left to the application. Such strings need not have any internal structure
(although they may; they could even be DER encodings).
SignedData type
The signed-data content type shall have ASN.1 type SignedData:
SignedData ::= SEQUENCE {
version Version,
digestAlgorithms DigestAlgorithmIdentifiers,
contentInfo ContentInfo,
106754086
19
certificates
[0] IMPLICIT ExtendedCertificatesAndCertificates
OPTIONAL,
crls
[1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::=
SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
The fields of type SignedData have the following meanings:

version is the syntax version number..
TBD doplniť…
Enveloped-data content type
TBD … ďalšie typy – high-level popis
4.1.2
XML Signature
ETSI TS 101 733
4.1.3
CAdES
CMS Advanced Electronic Signature
ETSI TS 101 733
TBD: len uviesť, že existuje
4.1.4
XAdES
XML Advanced Electronic Signature
ETSI TS 101 903
Základné typy XAdES sú BES, BES-EPES, ….
Basic electronic signature (XAdES-BES)
Strana 13 ETSI TS 101 933
<ds:Signature ID?>
<ds:SignedInfo>
<ds:CanonicalizationMethod/>
<ds:SignatureMethod/>
106754086
20
(<ds:Reference URI? >
(<ds:Transforms>)?
<ds:DigestMethod>
<ds:DigestValue>
</ds:Reference>)
</ds:SignedInfo>
<ds:SignatureValue>
(<ds:KeyInfo>)?
<ds:Object>
<QualifyingProperties>
<SignedProperties>
<SignedSignatureProperties>
(SigningTime)?
(SigningCertificate)?
(SignatureProductionPlace)?
(SignerRole)?
</SignedSignatureProperties>
<SignedDataObjectProperties>
(DataObjectFormat)*
(CommitmentTypeIndication)*
(AllDataObjectsTimeStamp)*
(IndividualDataObjectsTimeStamp)*
</SignedDataObjectProperties>
</SignedProperties>
<UnsignedProperties>
<UnsignedSignatureProperties>
(CounterSignature)*
</UnsignedSignatureProperties>
</UnsignedProperties>
</QualifyingProperties>
</ds:Object>
</ds:Signature>
5
5.1
Lecture No. 5 – Certificates, their formats, profiles
Certificate creation process
Creation of a certificate can be briefly written down in the following way:
1. Alice’s identity is verified using conventional method at Registration Authority
106754086
21
2. Private (sig_A) and public (ver_A) keys are created
3. CA creates its signature
s = Sig(ID(Alice) || ver_A) on Alice’s identity key
Certificate is cert_A = ID(Alice) || ver_A || s
5.2
Certificate format
The certificate is a structured sequence of bytes containing at least above mentioned data. There
are several possible ways of structuring certificates.
IETF RFC 3280 Internet X.509 Public Key Infrastructure Certificate and CRL Profile provides
definition of X.509 version 3 certificates.
X.509 v3 Certificate
Version
Version 0, 1, 2
Serial Number
Maximally 20 byte number
Signature algorithm ID
Issuer name
Operational period
notBefore, notAfter
Subject name (with enhanced naming
OU=)
Subject public key information
Issuer unique identifier
Subject unique identifier
Standard Extensions
“Qualified” Certificate Policy
106754086
22
Certificate Practice Statement URL
Practices reference
Notice ID
Other extensions
Application-defined extensions
VeriSign-defined controls
X.509 extensions
Example
C = SK, OU = ZEPE, O = KPMG, Serial Number = 1111111, CN= Július Šiška
Other alternatives of certificate formats are Simple public key infrastructure (SPKI) and PGP.
Both of them use local names for distinguishing entity identity.
5.3
Certificate profiles
The profiles define how the fields and certificate extensions (with syntax given by certificate
formats) are filled by CA. They can be specific for a group of user.
There are two definitions of qualified certificate – IETF RFC 3739 and European ETSI TS
101 852.
Qualified certificates are defined by either:

Information defined by certificate policy in the certificate policy extension

a statement included in the Qualified Certificates Statements extension.
In ETSI TS 101862 issuer name in issuer field must contain country code stored in
countryName attribute.
106754086
23
Note: In Slovak legislation another compulsory certificate policies extensions with defined
value qualifySK in is required.
5.4
CRL format
IETF RFC 3280
TBD: Popísať základnú štruktúru a spôsoby vydávania (úplné CRL, delta CRL)
6
Aplikácie v PKI
PKI je nasadzované, aby riešilo:
 dôvernosti – šifrovanie so kryptografickými algoritmaqmi s verejnými kľúčmi,
 integrity - elektronický podpis digitálneho odtlačku
 authenticity – digitálny podpis
PKI je možné nájsť v:

Pop-up questions on certificates in HTTPS connections and downloaded signed code
(ActiveX and Java applets) in browsers

Digital identity cards

Authentication into OS and applications

Signed and encrypted email message (PGP, S/MIME)

Electronic commerce (homebanking, internet banking)
6.1
CA softvér
CyberTrust Unicert, RSA Keon, Entrust, Open CA, Microsoft Certificate Server
Posudzovanie bezpečnosti softvéru sa robí voči zvoleným kritériám, napr. :

CEN CWA 14167-1:2003 Security Requirements for Trustworthy Systems Managing
Certificates for Electronic Signatures - Part 1: System Security Requirements
106754086
24

Cryptographic module for CSP signing operations with backup - Protection profile -
CMCSOB PP

Požiadavky na politiku pre vydávanie kvalifikovaných certifikátov:

ETSI TS 101 456 v1.2.1 (2002-04) Policy requirements for certification authorities issuing
qualified certificates
Softvér pre elektronický podpis
6.2
CEN CWA 14170:2004 – bezpečnostné požiadavky pre SCA
CEN CWA 14171:2004 – bezpečnostné odporúčania pre SVA
6.3
Elektronická podatelňa
6.4
e-Voting aplikácie
TBD: popísať účel a stručný popis
e-Commerce aplikácie
6.5
Príklady – nákup tovaru, elektronické bankovníctvo
Aké sú štandardy na bezpečnosť eCommerce aplikácií – štandard pre bankové systémy
7
Overovanie statusu certifikátu
CRL, OCSP, overenie certifikačnej cesty
Podľa RFC 3280
8
Používané kryptografické algoritmy
Základný algoritmus RSA - použitie na šifrovanie aj elektronický podpis
ElGamal podpsisová schema
DSA
106754086
25
9
Prednáška číslo 8 – Používané kryptografické algoritmy
Eliptické krivky a ECDSA
Gong Harn, XTR kryptosystémy
10 Prednáška číslo 9 – Overovanie platnosti certifikátu
Overenie podľa algoritmu z RFC 3280.
Certification path processing verifies the binding between the subject distinguished name
and/or subject alternative name and subject public key.
11 Legislatíva v EU a SR
Legislatívny rámec elektronického podpisu v Európskej únii je daný Directive 1999/93/EC.
Táto kapitola bude preberať:

Direktívu 1999/93/EC

Zákon o elektronickom podpise č. 215/2002 Z.z.

Čiastočne legislatívy ostatných krajín EÚ
11.1 Direktíva 1999/93/EC
European Directive for a Community Framework for Electronic Signatures

Directive entered into force: 19 January 2000

Deadline implementation by Member States: 19 July 2001
Principles:

Certification Service Provider: responsibility / operations

Electronic signatures may not be denied legal effect

“Technology neutral” legislation

“To the Public”: rules not meant for closed user groups
106754086
26
Definícia zaručeného elektronického podpisu v rámci EÚ:
Advanced electronic signature: an electronic signature which meets the following
requirements:
a) it is uniquely linked to the signatory;
b) it is capable of identifying the signatory;
c) it is created using means that the signatory can maintain under his sole control; and
d) it is linked to the data to which it relates in such a manner that any subsequent change of the
data is
detectable [Dir.1999/93/EC].
11.2 Legislatíva SR
Dané:

Zákon 215/2002

Vyhláška 537/2002 – o formáte a spôsobe vyhotovenia zaručeného elektronického podpisu,
spôsobe zverejňovania verejného kľúča úradu, postupe pri overovaní a podmienkach
overovania zaručeného elektronického podpisu, formáte časovej pečiatky a spôsobe jej
vyhotovenia, požiadavkách na zdroj časových údajov a požiadavkách na vedenie
dokumentácie časových pečiatok (o vyhotovení a overovaní elektronického podpisu a
časovej pečiatky)

Vyhláška 538/2002 - o formáte a obsahu kvalifikovaného certifikátu, o správe
kvalifikovaných certifikátov a o formáte, periodicite a spôsobe vydávania zoznamu
zrušených kvalifikovaných certifikátov (o kvalifikovaných certifikátoch)

Vyhláška 539/2002 - ktorou sa ustanovujú podrobnosti o požiadavkách na bezpečné
zariadenia na vyhotovovanie časovej pečiatky a požiadavky na produkty pre elektronický
podpis (o produktoch elektronického podpisu)

Vyhláška 540/2002 - o podmienkach na poskytovanie akreditovaných certifikačných
služieb a o požiadavkách na audit, rozsah auditu a kvalifikáciu audítorov

Vyhláška 541/2002 – o obsahu a rozsahu prevádzkovej dokumentácie vedenej
certifikačnou autoritou a o bezpečnostných pravidlách a pravidlách na výkon certifikačných
činností

Vyhláška 542/2002 - o spôsobe a postupe používania elektronického podpisu v obchodnom
a administratívnom styku
Možné subjekty komunikujúce pri elektronickom podpise sú na nasledujúcom obrázku:
106754086
27
Zákon bol odvtedy novelizovaný a bol viackrát doplnený z iných zákonov:

275/2006 o IS verejnej správy

25/2006 o verejnom obstarávaní
TBD: doplniť podľa JST úplného znenia zákona
TBD: dať študentom preštudovať Zákonč. 215/2002 o elektronickom podpise
§ 3 Elektronický podpis
(1) Elektronický podpis je informácia pripojená alebo inak logicky spojená s
elektronickým dokumentom, ktorá musí spĺňať tieto požiadavky:
a. nemožno ju efektívne vyhotoviť bez znalosti súkromného kľúča a
elektronického dokumentu,
b. na základe znalosti tejto informácie a verejného kľúča patriaceho k súkromnému
kľúču použitému pri jej vyhotovení možno overiť, že elektronický dokument, ku
ktorému je pripojená alebo s ním inak logicky spojená, je zhodný s
elektronickým dokumentom použitým na jej vyhotovenie.
106754086
28
(2) Podpisovateľ vyhotoví elektronický podpis elektronického dokumentu tak, že na
základe svojho súkromného kľúča a elektronického dokumentu vyhotoví nový údaj,
ktorý spĺňa podmienky podľa odseku 1.
§ 4 Zaručený elektronický podpis
(1) Zaručený elektronický podpis je elektronický podpis, ktorý musí spĺňať
podmienky podľa § 3:
a. je vyhotovený pomocou súkromného kľúča, ktorý je určený na vyhotovenie
zaručeného elektronického podpisu,
b. možno ho vyhotoviť len s použitím bezpečného zariadenia na vyhotovovanie
elektronického podpisu podľa § 2 písm. h),
c. spôsob jeho vyhotovovania umožňuje spoľahlivo určiť, ktorá fyzická osoba
zaručený elektronický podpis vyhotovila,
d. na verejný kľúč patriaci k súkromnému kľúču použitému na vyhotovenie
zaručeného elektronického podpisu je vydaný kvalifikovaný certifikát.
(2) Zaručený elektronický podpis je platný, ak
a. existuje kvalifikovaný certifikát verejného kľúča patriaceho k súkromnému
kľúču použitému pri vyhotovení daného elektronického podpisu,
b. je preukázateľné, že kvalifikovaný certifikát podľa písmena a) bol platný v čase
vyhotovenia daného elektronického podpisu,
c. elektronický dokument, ku ktorému je zaručený elektronický podpis pripojený
alebo s ním inak logicky spojený, je zhodný s dokumentom použitým na jeho
vyhotovenie, čo sa overilo použitím verejného kľúča uvedeného v
kvalifikovanom certifikáte podľa písmena a).
(3) Podpisovateľ vyhotoví zaručený elektronický podpis elektronického dokumentu
tak, že na základe svojho súkromného kľúča a daného elektronického dokumentu
vyhotoví pomocou bezpečného zariadenia na vyhotovenie elektronického podpisu nový
údaj, ktorý spĺňa podmienky podľa odseku 1.
(6) Zaručený elektronický podpis úradu je platný, ak elektronický dokument, ku
ktorému je zaručený elektronický podpis pripojený alebo s ním inak logicky spojený, je
zhodný s dokumentom použitým na jeho vyhotovenie, čo sa overilo použitím verejného
kľúča úradu zverejneného spôsobom podľa odseku 5.
106754086
29
12 Audit systémov PKI
The main objective of audit is providing support in establishing trustedness of CA.
Auditovanie je špecifické pre:

CA,

SCA,

SVA,

SCDev
12.1 Audit CA(resp. CSP)
Pre akreditované CA musí spĺňať požiadavky Zákona č. 215/2002 Z.z. o elektronickom
podpise a Vyhlášky NBÚ č. 540/2002 Z.z. o podmienkach na poskytovanie kreditovaných
certifikačných služieb a o požiadavkách na audit, rozsah auditu a kvalifikáciu audítorov.
12.1.1 Auditné programy pre CA
Existuje viacero auditných programov, podľa ktorých je možné viesť audit. Základné
kritériá kladené na audit sú:
 Nezávislosť a nestrannosť posudzovateľa

Opakovateľnosť postupu a jednoznačnosť procesu posúdenia

Široká akceptácia procesu posúdenia
Auditné programy zabezpečujú jednoznačnosť procesu posúdenia a od nich a odvíja aj
akceptácia procesu posúdenia. Nasledujúci zoznam uvádza najznámejšie auditné programy:
 Verejné štandardy

-
ETSI TS 101456
-
ANSI X9.79
-
WebTrust for CA – tieto požiadavky sú členené rovnako ako činnosti uvedené v
Kapitole 2
Komerčné štandardy
106754086
30
-
VeriSign
-
Entrust.net
-
Identrus
-
Global Trust Authority
-
MasterCard
-
VISA
-
Microsoft program for CA Qualification
12.1.2 Príklad metodiky použitej pri výkone auditu CA
Náš prístup k výkonu auditu je založený na medzinárodne akceptovanej metodike
X9.79/WebTrust for CA pre výkon auditu. Program WebTrust for CA používa ANSI X9.79 ako
ukážkové kritériá pre zabezpečenie výkonu činnosti CA z pohľadu existujúcich rizík. ANSI
X9.79 štandard je v súčasnosti taktiež spracúvaný v rámci ISO TC68 komisie ako podklad pre
ISO normu. Samotný prístup založený na týchto štandardoch je možné zosumarizovať do
nasledujúcich fáz:



Fáza I: Plánovanie auditu
-
Úvodné stretnutie s relevantnými predstaviteľmi CA
-
Prediskutovanie auditného programu, ktorý sa má použiť a vzájomné potvrdenie
rovnakého chápania uvedeného programu.
Fáza II: Výkon auditu
-
Základné bezpečnostné mechanizmy CA a overenie súladu s požadovanými štandardami
-
Zhodnotenie mechanizmov správy životného cyklu kľúčového aparátu
-
Zhodnotenie mechanizmov správy životného cyklu certifikátov
Fáza III: Tvorba výstupov
-
Výrok nezávislého audítora
-
Popis zistení o nedostatkoch
-
Odporúčanie pre vedenie na odstránenie zistených nedostatkov.
Nasleduje presnejší popis výkonu aktivít a podkladov v jednotlivých fázach.
12.1.3 Fáza I – Plánovanie auditu
Plánovacia fáza umožňuje objasniť celkový auditný plán zástupcom CA a získať
uistenie o zhodnom chápaní auditného prístupu. Na základe tohto porozumenie sa môžu
106754086
31
pracovníci CA náležite pripraviť na výkon auditu. Naše skúsenosti ukazujú, že plánovacia fáza
je kritická pre správne nazeranie na ciele a zámery auditu.
Vstupy

Stratégia CA a iné dokumenty popisujúce obchodný model CA.

Certification Practice Statement (CPS) – Pravidlá pre výkon certifikačných činností,

Certificate Policy (CP) - Certifikačný poriadok
Aktivity

Potvrdenie nášho porozumenia plánovaného obchodného modelu CA a požadovaných
úrovní dôvery. Obvykle získavame toto porozumenie diskusiami so zodpovednými
pracovníkmi CA, preštudovaním strategických dokumentov a preštudovaním Certificate
Policy,

Oboznámenie pracovníkov CA s auditným programom za účelom potvrdenia zhodného
chápania úloh, ktoré sa majú vykonať,

Výkon základnej analýzy rizík za účelom zhodnotenia aktuálneho stavu CA.
Úlohy CA

Zhromaždenie požadovaných dokumentov

Mapovanie podpornej klientskej dokumentácie na aplikovateľné bezpečnostné požiadavky.
Výstupy

Mapovanie podpornej klientskej dokumentácie na aplikovateľné bezpečnostné požiadavky.
12.1.4 Fáza II – Výkon auditu
Zhodnotenie základných bezpečnostných mechanizmov CA
Základné bezpečnostné mechanizmy CA pozostávajú z tých politík, praktík a procedúr,
ktoré tvoria a zabezpečujú dôveryhodné prostredie CA. Patria sem najmä:

Bezpečnostná politika

Bezpečnostný zámer

Bezpečnostný projekt

Bezpečnostná organizácia

Klasifikácia aktív a mechanizmov

Personálna bezpečnosť
106754086
32

Fyzická bezpečnosť a bezpečnosť prostredia

Riadenie prevádzky

Správa siete a systémov

Bezpečnosť dát a riadenie logického prístupu

Údržba systémov

Plánovanie kontinuity funkcií

Monitorovanie

Auditné záznamy
Vstupy

Bezpečnostná politika, bezpečnostný zámer, bezpečnostný projekt

Certification Practice Statement (CPS)

Certificate Policy (CP)

Detailné politiky a procedúry CA

Mapovanie klientskej dokumentácie na bezpečnostné požiadavky
Aktivity

Výkon auditného plánu vrátane:
-
Preštudovanie požiadaviek vedenia s ohľadom na súlad s akceptovanými požiadavkami
na základné bezpečnostné mechanizmy CA
-
Preštudovanie podpornej dokumentácie
-
Preštudovanie dôkazov o implementovaní bezpečnostných mechanizmov
-
Rozhovory s relevantnými pracovníkmi
Výstupy

Komunikácia priebežných zistení
Zhodnotenie mechanizmov správy životného cyklu kľúčového aparátu CA
Mechanizmy správy životného cyklu kľúčového aparátu vychádzajú z primárnych
bezpečnostných mechanizmov CA a preto sú auditované až následne. Mechanizmy správy
životného cyklu kľúčového aparátu zahŕňajú:

Generovanie kľúčov

Úschova, zálohovanie a obnova kľúčov
106754086
33

Distribúcia kľúčov

Archivácia a deštrukcia kľúčov

Správa kryptografických zariadení
Vstupy

Detailné politiky a procedúry mechanizmov správy životného cyklu kľúčového aparátu
-
Mapovanie klientskej dokumentácie na bezpečnostné požiadavky
Aktivity

Výkon auditného plánu vrátane:
-
Preštudovanie požiadaviek vedenia s ohľadom na súlad s akceptovanými požiadavkami
na základné bezpečnostné mechanizmy CA
-
Preštudovanie po podpornej dokumentácie
-
Preštudovanie dôkazov o implementovaní bezpečnostných mechanizmov
-
Rozhovory s relevantnými pracovníkmi
Výstupy

Komunikácia priebežných zistení
Zhodnotenie mechanizmov správy životného cyklu certifikátov
Mechanizmy správy životného cyklu kľúčového aparátu predstavujú kľúčovú úlohu CA.
Mechanizmy správy životného cyklu certifikátov zahŕňajú:

Registráciu, vystavenie a distribúciu certifikátov

Obnova certifikátov

Zneplatňovanie certifikátov a publikovanie informácií o zneplatnených certifikátoch

Spracovanie informácií o stave certifikátov (napr. spracovanie CRL)
Vstupy

Detailné politiky a procedúry mechanizmov správy životného cyklu certifikátov

Mapovanie klientskej dokumentácie na bezpečnostné požiadavky Certificate Policy (CP)
Aktivity

Výkon auditného plánu vrátane:
106754086
34
-
Preštudovanie požiadaviek vedenia s ohľadom na súlad s akceptovanými požiadavkami
na mechanizmy správy životného cyklu certifikátov
-
Preštudovanie po Preštudovanie podpornej dokumentácie
-
Preštudovanie dôkazov o implementovaní bezpečnostných mechanizmov
-
Rozhovory s relevantnými pracovníkmi
Výstupy

Komunikácia priebežných zistení
12.1.5 Fáza III – Tvorba výstupov
Finálnou fázou výkonu auditu je tvorba záverečných výstupov. V zmysle Vyhlášky
č.540/2002 Z.z. pozostáva záverečná správa častí:

Výrok nezávislého audítora a zhodnotenie celkového stavu bezpečnosti certifikačnej
autority v čase výkonu bezpečnostného auditu

Popis zistení o nedostatkoch bezpečnostného charakteru

Odporúčanie na odstránenie zistených nedostatkov
Výrok nezávislého audítora je adresovaný vedeniu spoločnosti a vyjadrí zhodnotenie
celkového stavu bezpečnosti certifikačnej autority v čase výkonu bezpečnostného auditu
v súlade s požiadavkami NBÚ a súvisiacou legislatívou vychádzajúc z popísaného auditného
programu. Podľa Vyhlášky č. 540/2002 Z.z. certifikačná autorita predkladá závrečnú správu
NBÚ, pričom správa je jedeným z podkladov, na základe ktorých je CA akreditovaná. Po
udelení akreditácie je certifikačná autorita v ročných intervaloch povinná podrobovať sa
pravidelným auditom a záverečnú správu predkladať NBÚ ako súčasť dohľadu NBÚ na výkon
certifikačných činností vykonávaných akreditovanou certifikačnou autoritou.
12.2 Audit SCA, SVA
Vykonávaný podľa
CEN CWA 14170:2004 – bezpečnostné požiadavky pre SCA
CEN CWA 14171:2004 – bezpečnostné odporúčania pre SVA
A legislatívnych požiadaviek
12.3 Audit SCDev
Nevykonáva sa, certifikáty sú udeľované NBÚ na základe interných posudzovacích kritérií.
Proces certifikácie a potrebné podklady na certifikáciu sú zverejnené.
106754086
35
13 Štandardy relevantné pre PKI
Tučným fontom sú zvýraznené najdôležitejšie štandardy.
13.1 PKI & certificates

IETF RFC 3280 Internet X.509 Public Key Infrastructure Certificate and CRL
Profile, obsoletes RFC 2459

ETSI TS 102 280 (2004-03) X.509 V.3 Certificate Profile for Certificates TS 102 280

IETF RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and CRL Profile

ETSI TS 101 862 v1.3.3 (2006-01) Qualified Certificate Profile

ETSI TR 102 153 (2003-02) Pre study on Certificate Profiles TR 102 153

IETF RFC 3739 Internet X.509 Public Key Infrastructure: Qualified Certificates Profile,
obsoletes RFC 3039

IETF RFC 3779 X.509 Extensions for IP Addresses and AS Identifiers
13.2 Certificate status validation

IETF RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol – OCSP, http://www.ietf.org/rfc/rfc2560.txt
See also IETF RFC 3280.
13.3 Certificate policies and Certificate Practice Statements

IETF RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework, http://www.ietf.org/rfc/rfc3647.txt, obsoletes RFC
2527.
13.4 Attribute certificates

ETSI TR 102 044 (2002:12) Identification of requirements for attribute certification TR
102 044

IETF RFC 3281 An Internet Attribute Certificate Profile,
http://www.ietf.org/rfc/rfc3281.txt.
See also ETSI TS 102 158.
106754086
36
13.5 Electronic signature
13.5.1 Electronic signature format

ETSI TS 101 733 v1.5.1 (2003-12) Electronic Signature Formats, RFC 3126 is equal to
TS 101 733 v1.2.2

PKCS
#7
Version
1.5:
Cryptographic
Message
Syntax
Standard
http://www.rsasecurity.com/rsalabs/node.asp?id=2129

IETF RFC 3369 Cryptographic Message Syntax (CMS), obsoletes: RFC 2630, RFC
3211



ETSI TR 102 047 (2004-02) International Harmonization of Electronic Signature Formats
ETSI TS 101 903 v1.2.2 (2004-04) XML Advanced Electronic Signatures (XAdES)
ETSI SR 002 176 (2003-03) Algorithms and Parameters for Secure Electronic Signatures
SR 002 176
13.5.2 Signature policies

ETSI TR 102 272 (2003-12) ASN.1 format for signature policies

ETSI TR 102 038 (2002-04) XML format for signature policies


ETSI TR 102 045 (2004-03) Signature policy for extended business model TR 102 045
ETSI TR 102 041 v1.1.1 (2002-02) Signature Policies Report TR 102 041
13.6 CSP standards and accreditation

ETSI TR 102 030 (2002-04) Provision of harmonized Trust Service Provider status
information

CEN CWA 14167-1:2003 Security Requirements for Trustworthy Systems Managing
Certificates for Electronic Signatures - Part 1: System Security Requirements

CEN CWA 14167-2:2004 Cryptographic module for CSP signing operations with backup Protection profile - CMCSOB PP
13.6.1 CSP policy requirements

ETSI TS 101 456 v1.2.1 (2002-04) Policy requirements for certification authorities issuing
qualified certificates

ETSI TS 102 042 (2002-04) Policy requirements for certification authorities issuing public
key certificates TS 102 042
106754086
37

ETSI TS 102 158 (2003-10) Policy requirements for CSPs issuing attribute certificates TS
102 158

ETSI TR 102 040 v1.2.1 (2004-02) International Harmonization of Policy Requirements for
CAs issuing Certificates TR 102 040 v1.2.1
ETSI TS 102 231 (2003-10) Harmonized TSP status information

13.6.2 Accreditation and certification frameworks

ANSI X9.79-1:2001 (2001) Public Key Infrastructure – Practices and Policy Framework

TTP. nl (http://www.ecp.nl) – holandská akreditačná schéma

tScheme (http://www.tscheme.org) – UK akreditačná schéma

OCES (http://www.itst.dk) – dánska akreditačná schéma
See also ETSI TS 101 456.
13.7 Timestamping

Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) – RFC 3161

ETSI TS 102 023 (2003-01) v1.2.1 Policy requirements for time-stamping authorities TS
102 023
ETSI TS 101 861 v1.2.1 (2002-03) Time stamping profile
IETF RFC 3161 Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP)
IETF RFC 3628 Policy Requirements for Time-Stamping Authorities



13.8 Ďalšie referencie

ETSI (http://www.etsi.org)

CEN/ISSS Workshop Electronic Signatures/Latest drafts
(http://www.cenorm.be/cenorm/businessdomains/businessdomains/informationsocietys
tandardizationsystem/published+cwas/index.asp)

Webtrust (http://www.cpawebtrust.org/CertAuth_fin.htm)

ANSI (http://webstore.ansi.org/ansidocstore/)

e-Envoy (http://www.e-envoy.gov.uk )

IAF (www.european-accreditation.org )
106754086
38
Odporúčaná literatúra pre predmet

IETF RFC 3280

IETF RFC 3161

RSA PKCS#7

Zákon č. 215/2002 o elektronickom podpise

Menezes, Okamoto, Vanstone: Handbook of Applied Cryptography (voľne stiahnuteľné na
nete)
106754086
39