-----Original Message----- From: Franck Martin [mailto:franck@sopac.org] Sent: Wednesday, 23 October 2002 10:31 To: wg-pki@lists.isoc.org Subject: Global PKI standard? Hi all, I have promised to send something about my views on how to establish a global PKI. Here it is. The document started from a simple question on the IETF list, on why not use DNS to help establishing a global PKI. I kind of tried to write it as an RFC, but I'm not yet good at it... I think this document gives some good bases of discussion and implementation, but please only positive criticism. If something is wrong, propose a way to fix it... There is one part yet I haven't figured out is, how to place a constraint in a certificate so that it can sign only certificate which are lower in the X400 naming scheme... Certificate dc=org,dc=isoc can sign dc=org,dc=isoc,dc=lists but not dc=org,dc=sopac Cheers franck@sopac.org PS:The original file I'm working with is the Lyx file. PPS: Check the SSL-Certificates HOWTO on www.tldp.org
Attachment:
RFCgPKI.lyx
Description: application/lyx
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [ <!entity header system "header.sgml"> ]> <book lang="en"><!-- DocBook file was created by LyX 1.2 See http://www.lyx.org/ for more information --> <bookinfo><title>Global PKI</title><date>22 October 2002 </date><author><firstname>Franck</firstname><surname>Martin</surname></author><abstract><para>This document proposes a standardisation of the method used with a DNS as an helper to locate Secure Certificates. It also explains how to generate coordinated certificates following the Domain Name tree. This document provides a method to add tracability to Internet exchange throught a common usage of certificates.</para><para>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].</para></abstract></bookinfo> <chapter><title>Introduction</title><para>All the tools are in place for providing a global Public Key Infrastructure (gPKI) but so far gPKI has lacked implementation through coordination. Certificates have a LDAP (X400) naming style scheme but few LDAP servers are linked together in a coordinated fashion. At the moment the only system which is structured, unique and reliable is the Domain Name Server Architecture. A coordinated usage of the DNS would allow to locate certificates and public keys prior to any transaction on the Internet. This could be usefull for IPSec, but mainly to S/Mime. At the moment, the usage of certificates is limited to a few websites. Certification in e-mail is lacking a wide use due to the lack of coordination in implementing Public Key Infrastructures.</para><para>This document proposes a method to implement a gPKI where individual PKI would be located through the DNS system. Each PKI legal role would be limited to a role of tracability. At the level of a PKI the reposibility of such PKI would be able to legally identify the entities for who the certificates have been issued (tracability). The role of the gPKI is not to offer security, nor to ensure the security asoociated with the issuance of certificates but to be able to provide information so that any Internet transaction secured with such certificate can be traced to a legal entity.</para></chapter> <chapter><title>DNS structure and Certificates</title><para>The DNS Infrastructure is composed of a root (.) which points to sub domains usually divided into 2 groups, the country code Top Level Domains (ccTLD) and global Top Level Domains (gTLD). Each TLD is then subsdivided in sub-domains and so on. This architecture forms a tree. An entity can be responsible of one to many domains with parent links or not. Each domain is served by 2 to many hosts acting in master/slave role or cooperatively in a distributed fashion.</para><para>The main importance of the DNS Infrastructure is that there is only one root domain, which is widely accepted and recognised by all hosts on the internet.</para><para>The Public Key Infrastructure follows the X400 naming scheme which also provide the possibility of organising each zone in a tree structure. This scheme is usually supported by LDAP which is the tool designed to provide information following an X400 naming scheme. Unfortunately very few LDAP servers are set up cooperatively.</para><para>However there has been several attempts to map DNS tree to LDAP tree, one of this scheme is to associate the domain name with dc fields. For instance the domain name “company.com.ki” could be mapped to “dc=company,dc=com,dc=ki”.</para><para>So if each certificate contains in its subject this string, then it is easy to query the right entry in the DNS infrastructure. In reverse each DNS must be able to point to a PKI repositery. This is done via the CERT record type [RFC2538].</para></chapter> <chapter><title>Considerations and Limitations</title><para>Currently the DNS protocol operates mainly using UDP, but can fall back to TCP when the length of the records are too big for UDP to be reliable. However lengthy records creates a huge burden on very active DNS such as the root DNS and TLD DNS.</para><para>Applications requiring the usage of certificate or encryption of transactions needs to contact the recipient to obtain its public key. Most applications are connected continuosly to the Internet but it is not always true. A lot of applications are behind firewalls, therefore the protocols to be used must be well known and widely implemented (DNS, HTTP, LDAP, SMTP). The application MUST trust the root certificate and MAY be able to trace any certificate up to the root certificate depending on the network conditions.</para></chapter> <chapter><title>gPKI Structure.</title><para>Each certificate MUST contain in its subject the relation to the DNS that contains the CERT record(s) to point to the online PKI repository.</para><para>Each certificate MUST be signed (or issued) by a PKI that follows the same above rule.</para><para>Each certificate issued MUST be authorised to sign other certificates. An x509v3 constraint MUST be set to unauthorise the signing of certificates lower in the hierarchy: x509v3 Basic Constraint CA:TRUE.</para><para>Each certificate MUST have the following x509v3 field set:</para><orderedlist><listitem><para>nsBaseURL: The location of the online PKI issuing the certificate</para></listitem><listitem><para>issuerAltName: The online location of the certifcate which signed this certificate</para></listitem><listitem><para>CRLDistributionsPoints: The online location of the list of revoked certificate</para></listitem></orderedlist><para>You MAY use also the OSCP to distribute revocation certificates.</para><para>The nsNaseURL gives the location of the PKI, the PKI MAY be queried to locate certificates by:</para><itemizedlist><listitem><para>Their serial ID: query.html?SID=</para></listitem><listitem><para>Their Common Name (CN): query.html?CN=</para></listitem></itemizedlist><para>For instance if the nsBaseURL is http://www.company.com.ki/pki/, to get the certificate of serial ID 4, the application MAY issue the query http://www.company.com.ki/pki/query.html?SID=4. The result of the query is the certificate in its PEM encoded form.</para><para>The nsBaseURL MAY also be used to query for revoked certificates by their Serial ID:</para><itemizedlist><listitem><para>Revoked certificates: query.html?revoked=</para></listitem></itemizedlist><para>The answer to the query is a CRL containing only the query certificate if it has been effectively revoked.</para><para>As each certificate contains in the Subject a pair of dc pointing to a domain name, a DNS query on this domain name with the type CERT MUST answer at least one CERT record of type 253 (cf [RFC2538]). The URI is equivalent to the nsBaseURL.</para><para>Therefore the system is fully self referenced, from certificate to PKI, from DNS to PKI and from certificate to DNS.</para></chapter> <chapter><title>Offline use, validy period and caching</title><para>Many applications are not directly online and sometime the verification of CRL may take quite a while and be a detriment to the responsiveness of clients. Imagine checking a CRL each time you open an e-mail.</para><para>These are a set of recommendations on the life expectancy of each element in the gPKI.</para><para>The root certificate for the DNS root authorithy should have a life of 18 years. The certificate should be highly protected and the private keys should never be loaded on any computer connected to the Internet or any network.</para><para>This certificate would issue 6 years lasting certificates for any TLDs. Same caution should be applied to ensure the security of the private keys.</para><para>TLD would issue 1 or 2 years certificates to end entities.</para><para>If the TLD is subdivided in sub domains then these subdomains should be issued 6 years certificates and be as most as possible be synchronised with the TLD.</para><para>Caching of information for end application may be as long as one week.</para></chapter> <chapter><title>Security issues</title><para>FIXME: because I'm no security expert...</para><para>High level of security and protection of private keys must be ensured. However the highest task for each certificate authorithy is to be able to trace certificates issued to legal entities, so that the responsibility of the certificate authorithy can be delegated to lower levels. A simple scheme would be to tie up the issuance of domain names and their certificate to a credit card. A credit card number provides a responsible legal entity that can be pursued in a court of law.</para><para>By the nature of the DNS, where information at a domain level is shared/distributed amongst several server/registries, it is essential that the tools neceessary to sign certificates be shared and distributed. Therefore a protocol must be established to transmit private keys amongst registry in a secure manners. This protocol may be to physically transmit private keys amongst registries rather than transmit them via Internet.</para><para>The issueance of a certificate can only be done after the domain name has been attributed. If the domain name is transmitted from one legal entity to another, then the current certificate must be revoked and a new one issued if needed. Each registry and en-user must disclose to each other any modification which would affect the certificate integrity and security.</para></chapter> </book>
Global PKI 22 October 2002 Abstract This document proposes a standardisation of the method used with a DNS as an helper to locate Secure Certificates. It also explains how to generate coordinated certificates following the Domain Name tree. This document provides a method to add tracability to Internet exchange throught a common usage of certificates. Abstract The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Introduction All the tools are in place for providing a global Public Key Infrastructure (gPKI) but so far gPKI has lacked implementation through coordination. Certificates have a LDAP (X400) naming style scheme but few LDAP servers are linked together in a coordinated fashion. At the moment the only system which is structured, unique and reliable is the Domain Name Server Architecture. A coordinated usage of the DNS would allow to locate certificates and public keys prior to any transaction on the Internet. This could be usefull for IPSec, but mainly to S/Mime. At the moment, the usage of certificates is limited to a few websites. Certification in e-mail is lacking a wide use due to the lack of coordination in implementing Public Key Infrastructures. This document proposes a method to implement a gPKI where individual PKI would be located through the DNS system. Each PKI legal role would be limited to a role of tracability. At the level of a PKI the reposibility of such PKI would be able to legally identify the entities for who the certificates have been issued (tracability). The role of the gPKI is not to offer security, nor to ensure the security asoociated with the issuance of certificates but to be able to provide information so that any Internet transaction secured with such certificate can be traced to a legal entity. DNS structure and Certificates The DNS Infrastructure is composed of a root (.) which points to sub domains usually divided into 2 groups, the country code Top Level Domains (ccTLD) and global Top Level Domains (gTLD). Each TLD is then subsdivided in sub-domains and so on. This architecture forms a tree. An entity can be responsible of one to many domains with parent links or not. Each domain is served by 2 to many hosts acting in master/slave role or cooperatively in a distributed fashion. The main importance of the DNS Infrastructure is that there is only one root domain, which is widely accepted and recognised by all hosts on the internet. The Public Key Infrastructure follows the X400 naming scheme which also provide the possibility of organising each zone in a tree structure. This scheme is usually supported by LDAP which is the tool designed to provide information following an X400 naming scheme. Unfortunately very few LDAP servers are set up cooperatively. However there has been several attempts to map DNS tree to LDAP tree, one of this scheme is to associate the domain name with dc fields. For instance the domain name "company.com.ki" could be mapped to "dc=company,dc=com,dc=ki". So if each certificate contains in its subject this string, then it is easy to query the right entry in the DNS infrastructure. In reverse each DNS must be able to point to a PKI repositery. This is done via the CERT record type [RFC2538]. Considerations and Limitations Currently the DNS protocol operates mainly using UDP, but can fall back to TCP when the length of the records are too big for UDP to be reliable. However lengthy records creates a huge burden on very active DNS such as the root DNS and TLD DNS. Applications requiring the usage of certificate or encryption of transactions needs to contact the recipient to obtain its public key. Most applications are connected continuosly to the Internet but it is not always true. A lot of applications are behind firewalls, therefore the protocols to be used must be well known and widely implemented (DNS, HTTP, LDAP, SMTP). The application MUST trust the root certificate and MAY be able to trace any certificate up to the root certificate depending on the network conditions. gPKI Structure. Each certificate MUST contain in its subject the relation to the DNS that contains the CERT record(s) to point to the online PKI repository. Each certificate MUST be signed (or issued) by a PKI that follows the same above rule. Each certificate issued MUST be authorised to sign other certificates. An x509v3 constraint MUST be set to unauthorise the signing of certificates lower in the hierarchy: x509v3 Basic Constraint CA:TRUE. Each certificate MUST have the following x509v3 field set: 1. nsBaseURL: The location of the online PKI issuing the certificate 2. issuerAltName: The online location of the certifcate which signed this certificate 3. CRLDistributionsPoints: The online location of the list of revoked certificate You MAY use also the OSCP to distribute revocation certificates. The nsNaseURL gives the location of the PKI, the PKI MAY be queried to locate certificates by: * Their serial ID: query.html?SID= * Their Common Name (CN): query.html?CN= For instance if the nsBaseURL is http://www.company.com.ki/pki/, to get the certificate of serial ID 4, the application MAY issue the query http://www.company.com.ki/pki/query.html?SID=4. The result of the query is the certificate in its PEM encoded form. The nsBaseURL MAY also be used to query for revoked certificates by their Serial ID: * Revoked certificates: query.html?revoked= The answer to the query is a CRL containing only the query certificate if it has been effectively revoked. As each certificate contains in the Subject a pair of dc pointing to a domain name, a DNS query on this domain name with the type CERT MUST answer at least one CERT record of type 253 (cf [RFC2538]). The URI is equivalent to the nsBaseURL. Therefore the system is fully self referenced, from certificate to PKI, from DNS to PKI and from certificate to DNS. Offline use, validy period and caching Many applications are not directly online and sometime the verification of CRL may take quite a while and be a detriment to the responsiveness of clients. Imagine checking a CRL each time you open an e-mail. These are a set of recommendations on the life expectancy of each element in the gPKI. The root certificate for the DNS root authorithy should have a life of 18 years. The certificate should be highly protected and the private keys should never be loaded on any computer connected to the Internet or any network. This certificate would issue 6 years lasting certificates for any TLDs. Same caution should be applied to ensure the security of the private keys. TLD would issue 1 or 2 years certificates to end entities. If the TLD is subdivided in sub domains then these subdomains should be issued 6 years certificates and be as most as possible be synchronised with the TLD. Caching of information for end application may be as long as one week. Security issues FIXME: because I'm no security expert... High level of security and protection of private keys must be ensured. However the highest task for each certificate authorithy is to be able to trace certificates issued to legal entities, so that the responsibility of the certificate authorithy can be delegated to lower levels. A simple scheme would be to tie up the issuance of domain names and their certificate to a credit card. A credit card number provides a responsible legal entity that can be pursued in a court of law. By the nature of the DNS, where information at a domain level is shared/distributed amongst several server/registries, it is essential that the tools neceessary to sign certificates be shared and distributed. Therefore a protocol must be established to transmit private keys amongst registry in a secure manners. This protocol may be to physically transmit private keys amongst registries rather than transmit them via Internet. The issueance of a certificate can only be done after the domain name has been attributed. If the domain name is transmitted from one legal entity to another, then the current certificate must be revoked and a new one issued if needed. Each registry and en-user must disclose to each other any modification which would affect the certificate integrity and security.
Attachment:
smime.p7s
Description: application/pkcs7-signature