home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-pkix-ipki2opp3-00.txt < prev    next >
Text File  |  1997-09-24  |  11KB  |  299 lines
  1.  
  2. PKIX Working Group                                           R. Housley
  3. Internet Draft                                                   SPYRUS
  4. expires in six months                                    September 1997
  5.  
  6.  
  7.                    Internet Public Key Infrastructure
  8.  
  9.                   Operational Protocols:  FTP and HTTP
  10.  
  11.                    <draft-ietf-pkix-ipki2opp3-00.txt>
  12.  
  13.  
  14. Status of this Memo
  15.  
  16.    This document is an Internet-Draft.  Internet-Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF), its areas,
  18.    and its working groups.  Note that other groups may also distribute
  19.    working documents as Internet-Drafts.
  20.  
  21.    Internet-Drafts are draft documents valid for a maximum of six months
  22.    and may be updated, replaced, or obsoleted by other documents at any
  23.    time.  It is inappropriate to use Internet- Drafts as reference
  24.    material or to cite them other than as "work in progress."
  25.  
  26.    To learn the current status of any Internet-Draft, please check the
  27.    "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
  28.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  29.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  30.    ftp.isi.edu (US West Coast).
  31.  
  32.  
  33. Abstract
  34.  
  35.    The protocol conventions described in this document satisfy some of
  36.    the operational requirements of the Internet Public Key
  37.    Infrastructure (PKI).  This document specifies the conventions for
  38.    using the File Transfer Protocol (FTP) and the Hypertext Transfer
  39.    Protocol (HTTP) to obtain certificates and certificate revocation
  40.    lists (CRLs) from PKI repositories.  Additional mechanisms addressing
  41.    PKIX operational requirements are specified in separate documents.
  42.  
  43.    Please send comments on this document to the ietf-pkix@tandem.com
  44.    mail list.
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Housley                                                         [Page 1]
  54.  
  55.  
  56.  
  57.  
  58.  
  59. INTERNET DRAFT                                            September 1997
  60.  
  61.  
  62. 1  Introduction
  63.  
  64.    This specification is part of a multi-part standard for the Internet
  65.    Public Key Infrastructure (PKI) using X.509 certificates and
  66.    certificate revocation lists (CRLs).  This document specifies the
  67.    conventions for using the File Transfer Protocol (FTP) and the
  68.    Hypertext Transfer Protocol (HTTP) to obtain certificates and CRLs
  69.    from PKI repositories.  Additional mechanisms addressing PKI
  70.    repository access are specified in separate documents.
  71.  
  72. 1.1  Model
  73.  
  74.    Following is a simplified view of the architectural model assumed by
  75.    the Internet PKI specifications.
  76.  
  77.       +---+
  78.       | C |                       +------------+
  79.       | e | <-------------------->| End entity |
  80.       | r |       Operational     +------------+
  81.       | t |       transactions         ^
  82.       |   |      and management        |  Management
  83.       | / |       transactions         |  transactions
  84.       |   |                            |
  85.       | C |    PKI users               v
  86.       | R |             -------+-------+--------+------
  87.       | L |   PKI management   ^                ^
  88.       |   |      entities      |                |
  89.       |   |                    v                |
  90.       | R |                 +------+            |
  91.       | e | <-------------- | RA   | <-----+    |
  92.       | p |   certificate   |      |       |    |
  93.       | o |       publish   +------+       |    |
  94.       | s |                                |    |
  95.       | I |                                v    v
  96.       | t |                            +------------+
  97.       | o | <--------------------------|     CA     |
  98.       | r |   certificate publish      +------------+
  99.       | y |           CRL publish             ^
  100.       |   |                                   |
  101.       +---+                                   |    Management
  102.                                               |    transactions
  103.                                               v
  104.                                           +------+
  105.                                           |  CA  |
  106.                                           +------+
  107.  
  108.                      Figure 1 - Internet PKI Entities
  109.  
  110.  
  111.  
  112.  
  113. Housley                                                         [Page 2]
  114.  
  115.  
  116.  
  117.  
  118.  
  119. INTERNET DRAFT                                            September 1997
  120.  
  121.  
  122.    The components in this model are:
  123.  
  124.    End Entity:  user of PKI certificates and/or end user system that
  125.                 is the subject of a certificate;
  126.  
  127.    CA:          certification authority;
  128.  
  129.    RA:          registration authority, i.e., an optional system to
  130.                 which a CA delegates certain management functions;
  131.  
  132.    Repository:  a system or collection of distributed systems that
  133.                 store certificates and CRLs and serves as a means of
  134.                 distributing these certificates and CRLs to end
  135.                 entities.
  136.  
  137. 1.2  Certificate and CRL Repository
  138.  
  139.    Some CAs mandate the use of on-line validation services, while others
  140.    distribute CRLs to allow certificate users to perform certificate
  141.    validation themselves.  In general, CAs make CRLs available to
  142.    certificate users by publishing them in the Directory.  The Directory
  143.    is also the normal distribution mechanism for certificates.  However,
  144.    Directory Services are not available in many parts of the Internet
  145.    today. The File Transfer Protocol (FTP) defined in RFC 959 and the
  146.    Hypertext Transfer Protocol (HTTP) defined in RFC 2068 offer
  147.    alternate methods for certificate and CRL distribution.
  148.  
  149.    End entities and CAs may retrieve certificates and CRLs from the
  150.    repository using FTP or HTTP.  Likewise, end entities, RAs, and CAs
  151.    may publish certificates and CRLs in the repository using FTP or
  152.    HTTP.
  153.  
  154. 2  FTP Conventions
  155.  
  156.    Within certificate extensions and CRL extensions, the URI form of
  157.    GeneralName is used to specify the location where issuer certificates
  158.    and CRLs may be obtained.  For instance, a URI identifying the
  159.    subject of a certificate may be carried in subjectAltName certificate
  160.    extension. An IA5String describes the use of anonymous FTP to fetch
  161.    certificate or CRL information.  For example:
  162.  
  163.       ftp://ftp.netcom.com/sp/spyrus/housley.cer
  164.       ftp://ftp.your.org/pki/id48.cer
  165.       ftp://ftp.your.org/pki/id48.no42.crl
  166.  
  167.    Internet users may publish the URI reference to a file that contains
  168.    their certificate on their business card.  This practice is useful
  169.    when there is no Directory entry for that user.  FTP is widely
  170.  
  171.  
  172.  
  173. Housley                                                         [Page 3]
  174.  
  175.  
  176.  
  177.  
  178.  
  179. INTERNET DRAFT                                            September 1997
  180.  
  181.  
  182.    deployed, and anonymous FTP are accommodated by many firewalls.
  183.    Thus, FTP is an attractive alternatives to Directory access protocols
  184.    for certificate and CRL distribution.  While this service satisfies
  185.    the requirement to retrieve information related to a certificate
  186.    which is already identified by a URI, it is not intended to satisfy
  187.    the more general problem of finding a certificate for a user about
  188.    whom some other information, such as their electronic mail address or
  189.    corporate affiliation, is known.
  190.  
  191.    For convenience, the names of files that contain certificates should
  192.    have a suffix of ".cer".  Each ".cer" file contains exactly one
  193.    certificate, encoded in DER format.  Likewise, the names of files
  194.    that contain CRLs should have a suffix of ".crl".  Each ".crl" file
  195.    contains exactly one CRL, encoded in DER format.
  196.  
  197. 3  HTTP Conventions
  198.  
  199.    Within certificate extensions and CRL extensions, the URI form of
  200.    GeneralName is used to specify the location where issuer certificates
  201.    and CRLs may be obtained.  For instance, a URI identifying the
  202.    subject of a certificate may be carried in subjectAltName certificate
  203.    extension. An IA5String describes the use of HTTP to fetch
  204.    certificate or CRL information.  For example:
  205.  
  206.       http://www.netcom.com/sp/spyrus/housley.cer
  207.       http://www.your.org/pki/id48.cer
  208.       http://www.your.org/pki/id48.no42.crl
  209.  
  210.    Internet users may publish the URI reference to a file that contains
  211.    their certificate on their business card.  This practice is useful
  212.    when there is no Directory entry for that user.  HTTP is widely
  213.    deployed, and HTTP is accommodated by many firewalls.  Thus, HTTP is
  214.    an attractive alternatives to Directory access protocols for
  215.    certificate and CRL distribution.  While this service satisfies the
  216.    requirement to retrieve information related to a certificate which is
  217.    already identified by a URI, it is not intended to satisfy the more
  218.    general problem of finding a certificate for a user about whom some
  219.    other information, such as their electronic mail address or corporate
  220.    affiliation, is known.
  221.  
  222.    For convenience, the names of files that contain certificates should
  223.    have a suffix of ".cer".  Each ".cer" file contains exactly one
  224.    certificate, encoded in DER format.  Likewise, the names of files
  225.    that contain CRLs should have a suffix of ".crl".  Each ".crl" file
  226.    contains exactly one CRL, encoded in DER format.
  227.  
  228.    **(Note - still outstanding is the definition of specific content
  229.    type label (mime type) with content in specific syntax.)
  230.  
  231.  
  232.  
  233. Housley                                                         [Page 4]
  234.  
  235.  
  236.  
  237.  
  238.  
  239. INTERNET DRAFT                                            September 1997
  240.  
  241.  
  242. References
  243.  
  244.    [RFC 959]   J. Postel and J. Reynolds, "File Transfer Protocol (FTP),"
  245.                RFC 959, October 1985.
  246.  
  247.    [RFC 1738]  T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform
  248.                Resource Locators (URL)," December 1994.
  249.  
  250.    [RFC 2068]  R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and
  251.                T. Berners-Lee; "Hypertext Transfer Protocol -- HTTP/1.1,"
  252.                RFC 2068, January 1997.
  253.  
  254. Security Considerations
  255.  
  256.    Since certificates and CRLs digitally signed, no additional integrity
  257.    service is necessary.  Neither certificates nor CRLs need be kept
  258.    secret, and anonymous access to certificates and CRLs is generally
  259.    acceptable.  So, no privacy service is necessary.
  260.  
  261.    Operators of FTP sites and World Wide Web servers should authenticate
  262.    end entities, CAs, and RAs who publish certificates and CRLs.
  263.    However, authentication is not necessary to retrieve certificates and
  264.    CRLs.
  265.  
  266. Author Address
  267.  
  268.    Russell Housley
  269.    SPYRUS
  270.    PO Box 1198
  271.    Herndon, VA 20172
  272.    USA
  273.    housley@spyrus.com
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293. Housley                                                         [Page 5]
  294.  
  295.  
  296.  
  297. --=====================_875063157==_--
  298.  
  299.