📄 pkix-overview.htm
字号:
<HTML><HEAD><TITLE>Overview of the PKIX approach</TITLE><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.55"><LINKREL="HOME"TITLE="The Open–source PKI Book"HREF="ospki-book.htm"><LINKREL="UP"TITLE="Internet X.509 Public Key Infrastructure (PKIX)"HREF="pkix.htm"><LINKREL="PREVIOUS"TITLE="Concepts"HREF="pkix-concepts.htm"><LINKREL="NEXT"TITLE="Open-Source Implementations"HREF="implementations.htm"></HEAD><BODYCLASS="SECT1"BGCOLOR="#FFFFFF"TEXT="#000000"LINK="#0000FF"VLINK="#840084"ALINK="#0000FF"><DIVCLASS="NAVHEADER"><TABLEWIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">The Open–source PKI Book: A guide to PKIs and Open–source Implementations</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="pkix-concepts.htm">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom">Chapter 6. Internet X.509 Public Key Infrastructure (PKIX)</TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="implementations.htm">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><DIVCLASS="SECT1"><H1CLASS="SECT1"><ANAME="PKIX-OVERVIEW">Overview of the PKIX approach</A></H1><P> <SPANCLASS="ACRONYM">PKIX</SPAN>, in order to describe public–key infrastructures, uses the terms <SPANCLASS="ACRONYM">PKI</SPAN> and <SPANCLASS="ACRONYM">PMI</SPAN>. One can find similarities between the two. The main difference is that the PKI handles the Public Key Certificates while the PMI handles the Attribute Certificates. A good metaphor to distinguish between the two is to associate the former with the passport of a person and the latter with the visa. The one provides identity and the other permission. </P><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="PKIX-PARTS">PKIX standardisation areas</A></H2><P> PKIX is working on the following five areas. <P></P><OLTYPE="1"><LI><P> Profiles of X.509 v3 Public Key Certificates and X.509 v2 Certificate Revocation Lists (CRLs). </P><P> It describes the basic certificate fields and the extensions to be supported for the Certificates and the Certificate Revocation Lists. Then, it talks about the basic and extended Certificate Path Validation. Finally, it covers the supported cryptographic algorithms. </P></LI><LI><P> Management protocols. </P><P> First, it discusses the assumptions and restrictions of the protocols. Then, it provides the data structures used for the PKI management messages and defines the functions that conforming implementations must carry out. Finally, it describes a simple protocol for transporting PKI messages. </P></LI><LI><P> Operational protocols. </P><P> Currently they describe how LDAPv2, FTP and HTTP can be used as operational protocols. </P></LI><LI><P> Certificate policies and Certificate Practice Statements. </P><P> The purpose of this document is to establish a clear relationship between certificate policies and CPSs, and to present a framework to assist the writers of certificate policies or CPSs with their tasks. In particular, the framework identifies the elements that may need to be considered in formulating a certificate policy or a CPS. The purpose is not to define particular certificate policies or CPSs, per se. </P></LI><LI><P> Time–stamping and data–certification/validation services. </P><P> There are no RFCs on these services yet, as the documents are still classified as Internet Drafts. </P><P> The time–stamping services define a trusted third–party that creates time stamp tokens in order to indicate that a datum existed at a particular point in time. The data certification and validation services provide certification of possesion of data and claim of possesion of data, and validation of digitally signed documents and certificates. </P></LI></OL> </P><P> The relevant Request For Comments (<SPANCLASS="ACRONYM">RFC</SPAN>) documents are depicted in the following table <DIVCLASS="TABLE"><P><B>Table 6-2. Table of RFCs for PKIX documents</B></P><TABLEBORDER="1"CLASS="CALSTABLE"><THEAD><TR><THALIGN="LEFT"VALIGN="TOP">Subject</TH><THALIGN="LEFT"VALIGN="TOP">RFC</TH></TR></THEAD><TBODY><TR><TDALIGN="LEFT"VALIGN="TOP">Profiles of X.509 v3 Public Key Certificates and X.509 v2 Certificate Revocation Lists (CRLs)</TD><TDALIGN="LEFT"VALIGN="TOP">RFC 2459</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">PKIX Certificate Management Protocols</TD><TDALIGN="LEFT"VALIGN="TOP">RFC 2510</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Operational protocols</TD><TDALIGN="LEFT"VALIGN="TOP">RFC 2559, RFC 2585, RFC 2560</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Certificate Policy and Certification Practices Framework </TD><TDALIGN="LEFT"VALIGN="TOP">RFC 2527</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Time–stamping and data–certification services </TD><TDALIGN="LEFT"VALIGN="TOP">No RFCs yet, only internet drafts available</TD></TR></TBODY></TABLE></DIV> </P><P> The specification of the X.509 Certificates is very general and extensible. To ensure interoperability between different Internet-centric implementations, the PKIX Working Group defined a <ICLASS="EMPHASIS">profile</I>, which is a description of the format and semantics of certificates and certificate revocation lists for the Internet PKI. </P><P> The operational protocols are the protocols that are required to deliver certificates and CRLs (or status information) to certificate–using client systems. There is an emphasis to have a variety of distribution mechanisms for the certificates and the CRLs, using for example, LDAP, HTTP and FTP. For example, the retrieval of the CRL by a merchant to check whether a certificate is valid, constitutes an operational protocol. </P><P> Management protocols are the protocols that are required to support on–line interactions between PKI user and management entities. The possible set of functions that can be supported by management protocols is <P></P><UL><LI><P> registration of entity, that takes place prior to issuing the certificate </P></LI><LI><P> initialisation, for example generation of key–pair </P></LI><LI><P> certification, the issuance of the certificate </P></LI><LI><P> key–pair recovery, the ability to recover lost keys </P></LI><LI><P> key–pair update, when the certificate expires and a new key–pair and certificate have to be generated </P></LI><LI><P> revocation request, when an authorised person advices the CA to include a specific certificate into the revocation list </P></LI><LI><P> cross-certification, when two CAs exchange information in order to generate a cross–certificate </P></LI></UL> </P><P> The Certificate Policies and the Certificate Practice Statements are recommendations of documents that will describe the obligations and other rules with regard the usage of the Certificate. </P></DIV><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="PKIX-FUNCTIONALITY">Public–key infrastructure functionality</A></H2><P> This is a functionality or operations of a Public Key Infrastructure. <DIVCLASS="TABLE"><P><B>Table 6-3. PKI functionality</B></P><TABLEBORDER="1"CLASS="CALSTABLE"><THEAD><TR><THALIGN="LEFT"VALIGN="TOP">Functionality</TH></TR></THEAD><TBODY><TR><TDALIGN="LEFT"VALIGN="TOP">Registration</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Initialisation</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Certification</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Key–pair recovery</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Key generation</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Key update</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Key expiry</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Key compromise</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Cross certification</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Revocation</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Certificate and Revocation Notice Distribution and Publication</TD></TR></TBODY></TABLE></DIV> </P></DIV><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="PKIX-PKI">Public–Key Infrastructure (PKI)</A></H2><P> A PKI is a set of hardware, software, people, policies and procedures needed to create, manage, store, distribute and revoke PKCs based on public–key cryptography. </P><P> A PKI consists of five types of componets. </P><DIVCLASS="TABLE"><P><B>Table 6-4. PKI components</B></P><TABLEBORDER="1"CLASS="CALSTABLE"><THEAD><TR><THALIGN="LEFT"VALIGN="TOP">Type of component</TH><THALIGN="LEFT"VALIGN="TOP">Description</TH></TR></THEAD><TBODY><TR><TDALIGN="LEFT"VALIGN="TOP">Certification Authorities (CAs)</TD><TDALIGN="LEFT"VALIGN="TOP">to issue and revoke PKCs</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Organisational Registration Authorities (ORAs)</TD><TDALIGN="LEFT"VALIGN="TOP">to vouch for the binding between public keys and certificate holder identities and other attributes</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Certificate holders</TD><TDALIGN="LEFT"VALIGN="TOP">to sign and encrypt digital documents</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Clients</TD><TDALIGN="LEFT"VALIGN="TOP">to validate digital signatures and their certification path from a known public key of a trusted CA</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Repositories</TD><TDALIGN="LEFT"VALIGN="TOP">to store and make available certificates and Certificate Revocation Lists (CRLs)</TD></TR></TBODY></TABLE></DIV><P> In <AHREF="pkix-overview.htm#PKIENTITIES">Figure 6-1</A> there is a simplified view of the architectural model assumed by the PKIX Working Group. <DIVCLASS="FIGURE"><ANAME="PKIENTITIES"></A><P><B>Figure 6-1. PKI Entities</B></P><P><IMGSRC="figures/PKIEntities.gif"></P></DIV> The End–entity, using management transactions, sends its certificate request to the Registration Authority for approval. If it is actually approved, it is forwarded to the Certification Authority for signing. The Certification Authority verifies the certificate request and if it passes the verification, it is signed and the Certificate is produced. To public the Certificate, the CA sends it to Certificate Repository for collection from the End–entity. </P><P> The diagram shows that the End–entity can communicate directly with the CA. According to the PKIX recommendations, it is possible to implement the functionality within the CA. Although it is a bit confusing, the diagram shows all possible communications, regardless of the implementation decisions. </P><P> Additionally, both the CA and RA are shown to deliver Certificates to the repository. Depending on the implementation, one of the two is chosen. </P><P> For the issue of the revocation of the certificates, a similar course with the generation of the Certificates is taken. The End–entity asks the RA to have its Certificate revoked, the RA decides and possibly forwards it to the CA, the CA updates the revocation list and publishes it on the CRL repository. </P><P> Finally, the End–entities can check the validity of a specific Certificate using an operational protocol. </P></DIV><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="PKIX-PMI">Privilege Management Infrastructure (PMI)</A></H2><P> PMI is the set of hardware, software, people, policies and procedures needed to create, manage, store, distribute and revoke Attribute Certificates. </P><P> A PMI consists of five types of componets. </P><DIVCLASS="TABLE"><P><B>Table 6-5. PMI components</B></P><TABLEBORDER="1"CLASS="CALSTABLE"><THEAD><TR><THALIGN="LEFT"VALIGN="TOP">Type of component</TH><THALIGN="LEFT"VALIGN="TOP">Description</TH></TR></THEAD><TBODY><TR><TDALIGN="LEFT"VALIGN="TOP">Attribute Authorities (AAs)</TD><TDALIGN="LEFT"VALIGN="TOP">to issue and revoke ACs (also called Attribute Certificate Issuer)</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Attribute Certificate Users</TD><TDALIGN="LEFT"VALIGN="TOP">to parse or process an AC</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Attribute Certificate Verifier</TD><TDALIGN="LEFT"VALIGN="TOP">to check the validity of an AC and then make use of the result</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Clients</TD><TDALIGN="LEFT"VALIGN="TOP">to request an action for which authorisation checks are to be made</TD></TR><TR><TDALIGN="LEFT"VALIGN="TOP">Repositories</TD><TDALIGN="LEFT"VALIGN="TOP">to store and make available certificates and Certificate Revocation Lists (CRLs)</TD></TR></TBODY></TABLE></DIV><P> In <AHREF="pkix-overview.htm#ACEXCHANGES">Figure 6-2</A> there is a view of the exchanges that may involve Attribute Certificates <DIVCLASS="FIGURE"><ANAME="ACEXCHANGES"></A><P><B>Figure 6-2. Attribute Certificate Exchanges</B></P><P><IMGSRC="figures/ACExchanges.gif"></P></DIV> There are two types of attribute certificate distribution as show in the diagram, <ICLASS="EMPHASIS">push</I> and <ICLASS="EMPHASIS">pull</I>. </P><P> In some environments it is suitable for a client to <ICLASS="EMPHASIS">push</I> an AC to a server. This means that no new connections between the client and server are required. It also means that no search burden is imposed on servers, which improves performance. </P><P> In other cases, it is more suitable for a client simply to authenticate to the server and for the server to request or <ICLASS="EMPHASIS">pull</I> the client's AC from an AC issuer or a repository. A major benefit of the <ICLASS="EMPHASIS">pull</I> model is that it can be implemented without changes to the client or to the client–server protocol. It is also more suitable for some inter–domain cases where the client's rights should be assigned within the server's domain, rather than within the client's domain. </P></DIV></DIV><DIVCLASS="NAVFOOTER"><HRALIGN="LEFT"WIDTH="100%"><TABLEWIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top"><AHREF="pkix-concepts.htm">Prev</A></TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="ospki-book.htm">Home</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top"><AHREF="implementations.htm">Next</A></TD></TR><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top">Concepts</TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="pkix.htm">Up</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top">Open-Source Implementations</TD></TR></TABLE></DIV></BODY></HTML>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -