PKI CA RA KMC

 

RA-注册中心负责审核证书申请者的真实身份，在审核通过后，负责将用户信息通过网络上传到认证中心，由认证中心负责最后的制证处理。证书的吊销、更新也需要由注册机构来提交给认证中心做处理。总的来说，认证中心是面向各注册中心的，而注册中心是面向最终用户的，注册机构是用户与认证中心的中间渠道。

 

 

The framework of a PKI consists of security and operational policies, security
services, and interoperability protocols supporting the use of public-key
cryptography for the management of keys and certificates. The generation,
distribution, and management of public keys and associated certificates normally
occur through the use of Certification Authorities (CAs), Registration Authorities
(RAs), and directory services, which can be used to establish a hierarchy or chain o
trust. CA, RA, and directory services allow for the implementation of digital
certificates that can be used to identify different entities. The purpose of a PKI
framework is to enable and support the secured exchange of data, credentials, and
value (such as monetary instruments) in various environments that are typically
insecure, such as the Internet.

 

In short, a CA functions as follows. Entities that are unknown to one another, each
individually establish a trust relationship with a CA. The CA performs some level of
entity authentication, according to its established rules as noted in its Certificate
Practices Statement or CPS, and then issues each individual a digital certificate. That
certificate is signed by the CA and thus vouches for the identity of the individuals.
Unknown individuals can now use their certificates to establish trust between them
because they trust the CA to have performed an appropriate entity authentication,
and the CA's signing of the certificates attests to this fact. A major benefit of a PKI
is the establishment of a trust hierarchy because this scales well in heterogeneous
network environments.

 

Trust Models

 

The implementation of a PKI requires an analysis of business objectives and the trust
relationships that exist in their environment. The awareness of these trust
relationships leads to the establishment of an overall trust model that the PKI
enforces. The following three common examples of trust models are presented for
comparison purposes.
Hierarchical

A hierarchical trust model represents the most typical implementation of a PKI. In
its most simple instantiation, this trust model allows end entities’ certificates to be
signed by a single CA. In this trust model, the hierarchy consists of a series of CAs
that are arranged based on a predetermined set of rules and conventions.
For example, in the financial services world, rather than have a single authority sign
all end entities’ certificates, there may be one CA at a national level that signs the
certificates of particular financial institutions. Then each institution would itself be a
CA that signs the certificates of their individual account holders. Within a
hierarchical trust model there is a trust point for each certificate issued. In this case,
the trust point for the financial institution's certificate is the national or root CA. The
trust point for an individual account holder is their institution's CA. This approach
allows for an extensible, efficient, and scalable PKI.

 

Distributed (Web of Trust)
A distributed Web of trust is one that does not incorporate a CA. No trusted third
party actually vouches for the identity or integrity of any end entity. Pretty Good
Privacy (PGP) uses this type of trust model in email environments. This trust model
does not scale well into the Internet-based e-commerce world because each end
entity is left to its own devices to determine the level of trust that it will accept from
other entities.

 

Cross Certification

    Cross certification enables entities in one public key infrastructure (PKI) to trust entities in another PKI. This mutual trust relationship is typically supported by a cross-certification agreement between the certification authorities (CAs) in each PKI. The agreement establishes the responsibilities and liability of each party.

    A mutual trust relationship between two CAs requires that each CA issue a certificate to the other to establish the relationship in both directions. The path of trust is not hierarchal (neither of the governing CAs is subordinate to the other) although the separate PKIs may be certificate hierarchies. After two CAs have established and specified the terms of trust and issued certificates to each other, entities within the separate PKIs can interact subject to the policies specified in the certificates.

 

 a CA’s primary purpose is to support the generation,
management, storage, deployment, and revocation of public key certificates.

 

A CA works within the context of an overall business policy known as a Certificate
Policy (CP) and functions operationally according to a Certificate Practices
Statement (CPS).

 

Certificate Policy
A primary tenet of e-commerce security is the CP statement. The CP statement
provides the overall guiding principles that an organization endorses regarding who
may do what and how to systems and data. A CP also specifies how controls are
managed. In addition, a CP names a set of rules that indicates the applicability of a
public key certificate to a particular community or class of applications with
common security requirements. For example, a particular CP might indicate
applicability of a type of public key certificate to the authentication of electronic data
interchange transactions for the trading of goods for monetary value.
Each PKI implementation should reflect the following in a CP statement:
n Purpose of the PKI
n Specific business requirements the PKI addresses through:
n Security architecture
n Associated trust model and threat profile
n Specific security services the PKI supports

 

Certificate Practices Statement
The details of a policy statement should be published in a Certificate Practices
Statement or CPS. The CPS is a statement of the practices that a CA employs in
issuing public key certificates. The CPS document enumerates the procedural and
operational practices of a PKI. The CPS should detail all processes within the life
cycle of a public key certificate including its generation, issuance, management,
storage, deployment, and revocation. The CPS should also specify the original entity
authentication process that an end entity must be validated through before
participating in a PKI. The objective of the CPS is to instill trust in the PKI such that
the user community at large will have sufficient confidence to participate in it.

 

An Example of a PKI in Action
The following provides an example of public key cryptography in use for both
confidentiality and integrity. The purpose of this example is to illustrate how public
key cryptography mechanisms can be used in a PKI. In this example, both parties,
Alice and Bob, share a common trust point; that is, they both use the same CA to
have their certificates signed. For this reason, they do not have to evaluate a chain of
trust to determine the credibility of any other CA. The example is not necessarily
appropriate for every business proposition.

 

Precursor Steps
1. Alice and Bob each generate a public/private key pair.
2. Alice and Bob each provide their public keys, name, and descriptive information
to an RA.
3. The RA validates their credentials and forwards the certificate requests to the CA.
4. The CA generates a certificate for Alice and Bob's public keys by formatting their
public keys and other information, and then signs the certificate with the CA's
private keys.
5. The results of this operation are that Alice and Bob each have a public/private
key pair and a public key certificate.
6. Alice and Bob each generate a secret symmetric key.

 

 

then

Certificate Revocation
    Although public key certificates are issued for a fixed period of time before they
become void, situations can arise where they are no longer trustworthy and thus
must be prematurely expired. This is known as certificate revocation. There are
many reasons that a certificate should be revoked. The private keys could be
compromised, a user is no longer a customer, or there is a change in the information
incorporated within a certificate that is used to determine its validity.
     Certificate revocation must be initiated by the CA or their delegate such as an RA,
which originated the end entity's certificate. The predominant vehicle for certificate
revocation is known as a Certificate Revocation List or CRL. A CRL is a list
generated by the CA that contains unique information about the revoked certificates
which enables relying entities to determine if a certificate is valid or not. A CRL
entry should be serialized, time-stamped, and signed by the CA. It is normally the
relying entity’s responsibility to retrieve the CRL.
     A CRL must be published in a publicly available repository or directory. LDAP is the
industry’s current directory of choice and has been developed as an X.500 compliant
protocol for the Internet. LDAP defines the directory query, data storage, and
management protocols.

 

There are other types of CRLs such as, segmented-CRLs, delta-CRLs, and CRL-like
mechanisms—for example, the Online Certificate Status Protocol (OCSP). OCSP is
the most interesting because it can address the latency issue associated with
standard CRL publication. OCSP is a mechanism that actually requests, in real time,
a status check for a particular certificate from the originating CA. This has the
benefit of not only being timely but in fact, reduces or eliminates the necessity for a
CA to publish a CRL. The CRL simply waits for status check requests and responds
to them as necessary.

 

The structure of an X.509 v3 digital certificate is as follows:

• Certificate
  • Version
  • Serial Number
  • Algorithm ID
  • Issuer
  • Validity
    • Not Before
    • Not After
  • Subject
  • Subject Public Key Info
    • Public Key Algorithm
    • Subject Public Key
  • Issuer Unique Identifier (optional)
  • Subject Unique Identifier (optional)
  • Extensions (optional)
    • ...
• Certificate Signature Algorithm
• Certificate Signature

 

 

    This is an example of a decoded X.509 certificate for www.freesoft.org, generated with OpenSSL—the actual certificate is about 1 kB in size. It was issued by Thawte (since acquired by VeriSign), as stated in the Issuer field. Its subject contains many personal details, but the most important part is usually the common name (CN), as this is the part that must match the host being authenticated. Also included is an RSA public key (modulus and public exponent), followed by the signature, computed by taking a MD5 hash of the first part of the certificate and signing it (applying the encryption operation) using Thawte's RSA private key.

 

Certificate:   Data:       Version: 1 (0x0)       Serial Number: 7829 (0x1e95)       Signature Algorithm: md5WithRSAEncryption       Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,               OU=Certification Services Division,               CN=Thawte Server CA/emailAddress=[e-mail]       Validity              Not Before: Jul  9 16:04:02 1998 GMT           Not After : Jul  9 16:04:02 1999 GMT       Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,                OU=FreeSoft, CN=www.freesoft.org/emailAddress=[e-mail]       Subject Public Key Info:           Public Key Algorithm: rsaEncryption           RSA Public Key: (1024 bit)               Modulus (1024 bit):                   00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:                   33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:                   66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:                   70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:                   16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:                   c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:                   8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:                   d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:                   e8:35:1c:9e:27:52:7e:41:8f               Exponent: 65537 (0x10001)   Signature Algorithm: md5WithRSAEncryption       93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:       92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:       ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:       d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:       0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:       5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:       8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:       68:9f


   To validate this certificate, one needs a second certificate that matches the Issuer (Thawte Server CA) of the first certificate. First, one verifies that the second certificate is of a CA kind; that is, that it can be used to issue other certificates. This is done by inspecting a value of the CA attribute in the X509v3 extension section. Then the RSA public key from the CA certificate is used to decode the signature on the first certificate to obtain a MD5 hash, which must match an actual MD5 hash computed over the rest of the certificate. An example CA certificate follows:


Certificate:   Data:       Version: 3 (0x2)       Serial Number: 1 (0x1)       Signature Algorithm: md5WithRSAEncryption       Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,               OU=Certification Services Division,               CN=Thawte Server CA/emailAddress=[e-mail]       Validity           Not Before: Aug  1 00:00:00 1996 GMT           Not After : Dec 31 23:59:59 2020 GMT       Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,                OU=Certification Services Division,                CN=Thawte Server CA/emailAddress=[e-mail]       Subject Public Key Info:           Public Key Algorithm: rsaEncryption           RSA Public Key: (1024 bit)               Modulus (1024 bit):                   00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c:                   68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da:                   85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06:                   6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2:                   6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b:                   29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90:                   6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f:                   5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36:                   3a:c2:b5:66:22:12:d6:87:0d               Exponent: 65537 (0x10001)       X509v3 extensions:           X509v3 Basic Constraints: critical               CA:TRUE   Signature Algorithm: md5WithRSAEncryption       07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9:       a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48:       3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88:       4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9:       8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5:       e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9:       b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e:       70:47

This is an example of a self-signed certificate, as the issuer and subject are the same. There's no way to verify this certificate except by checking it against itself; instead, these top-level certificates are manually stored by web browsers.