WDIFF

draft-ietf-pkix-opp-ftp-http-02.txt --> draft-ietf-pkix-opp-ftp-http-03.txt


PKIX Working Group R. Housley
Internet Draft SPYRUS
expires	in six months                                     November 1997 April 1998


 Internet X.509	Public Key Infrastructure

 Operational Protocols:	FTP and	HTTP

                 <draft-ietf-pkix-opp-ftp-http-02.txt>

 <draft-ietf-pkix-opp-ftp-http-03.txt>


Status of this Memo

 This document is an Internet-Draft. Internet-Drafts are working
 documents of the Internet Engineering Task Force (IETF), its areas,
 and its working groups. Note that other groups	may also distribute
 working documents as Internet-Drafts.

 Internet-Drafts are draft documents valid for a maximum of six	months
 and may be updated, replaced, or obsoleted by other documents at any
 time. It is inappropriate to use Internet- Drafts as reference
 material or to	cite them other	than as	"work in progress."

 To learn view the current status entire list of any Internet-Draft, current Internet-Drafts, please check
 the "1id-abstracts.txt" listing contained in the Internet- Drafts Internet-Drafts
 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
 (Pacific Rim), ds.internic.net ftp.ietf.org (US East Coast), or ftp.isi.edu
 (US West Coast).


Abstract

 The protocol conventions described in this document satisfy some of
 the operational requirements of the Internet Public Key
 Infrastructure	(PKI). This document specifies the conventions for
 using the File	Transfer Protocol (FTP)	and the	Hypertext Transfer
 Protocol (HTTP) to obtain certificates	and certificate	revocation
 lists (CRLs) from PKI repositories. Additional	mechanisms addressing
 PKIX operational requirements are specified in	separate documents.

 Please	send comments on this document to the ietf-pkix@tandem.com
 mail list.








Housley	[Page 1]





INTERNET DRAFT                                             November 1997 April 1998


1 Introduction

 This specification is part of a multi-part standard for the Internet
 Public	Key Infrastructure (PKI) using X.509 certificates and
 certificate revocation	lists (CRLs). This document specifies the
 conventions for using the File	Transfer Protocol (FTP)	and the
 Hypertext Transfer Protocol (HTTP) to obtain certificates and CRLs
 from PKI repositories.	Additional mechanisms addressing PKI
 repository access are specified in separate documents.

1.1 Model

 Following is a	simplified view	of the architectural model assumed by
 the Internet PKI specifications.

 +---+
 | C | +------------+
 | e | <-------------------->| End entity |
 | r | Operational +------------+
 | t | transactions ^
 | | and management | Management
 | / | transactions | transactions
 | | | PKI users
 | C |    PKI users v
 | R |             -------+-------+--------+------ -------------------+--+-----------+-----------------
  | L |   PKI management	^ ^
 | |      entities | | PKI management
 | | v | entities
 | R | +------+	|
 | e | <-------------- | <---------------------| RA | <-----+ <---+ |
 | p | Publish certificate   |      | +------+ | |
 | o |       publish   +------+ | |
 | s | | |
 | I | v v
 | t | +------------+
 | o | <--------------------------| <------------------------------|	CA |
 | r | Publish certificate publish +------------+
 | y | Publish CRL publish ^
 | | |
 +---+                                   | Management |
 transactions |
 v
 +------+
 | CA |
 +------+

 Figure	1 - Internet PKI Entities




Housley	[Page 2]





INTERNET DRAFT                                             November 1997 April 1998


 The components	in this	model are:

 End Entity: user of PKI certificates and/or end user system that
 is the	subject	of a certificate;

 CA: certification authority;

 RA: registration authority, i.e., an optional system to
 which a CA delegates certain management functions;

 Repository: a system or collection of distributed systems that
 store certificates and	CRLs and serves	as a means of
 distributing these certificates and CRLs to end
 entities.

1.2 Certificate	and CRL	Repository

 Some CAs mandate the use of on-line validation	services, while	others
 distribute CRLs to allow certificate users to perform certificate
 validation themselves.	In general, CAs	make CRLs available to
 certificate users by publishing them in the Directory.	The Directory
 is also the normal distribution mechanism for certificates. However,
 Directory Services are	not available in many parts of the Internet
 today.	The File Transfer Protocol (FTP) defined in RFC	959 and	the
 Hypertext Transfer Protocol (HTTP) defined in RFC 2068	offer
 alternate methods for certificate and CRL distribution.

 End entities and CAs may retrieve certificates	and CRLs from the
 repository using FTP or HTTP. End entities may	publish	their own
 certificate in	the repository using FTP or HTTP, and RAs and CAs may
 publish certificates and CRLs in the repository using FTP or HTTP.

2 FTP Conventions

 Within	certificate extensions and CRL extensions, the URI form	of
 GeneralName is	used to	specify	the location where issuer certificates
 and CRLs may be obtained. For instance, a URI identifying the
 subject of a certificate may be carried in subjectAltName certificate
  extension. An	IA5String describes the	use of anonymous FTP to	fetch
 certificate or	CRL information. For example:

 ftp://ftp.netcom.com/sp/spyrus/housley.cer
 ftp://ftp.your.org/pki/id48.cer
 ftp://ftp.your.org/pki/id48.no42.crl

 Internet users	may publish the	URI reference to a file	that contains
 their certificate on their business card. This	practice is useful
 when there is no Directory entry for that user. FTP is	widely



Housley	[Page 3]





INTERNET DRAFT                                             November 1997 April 1998


 deployed, and anonymous FTP are accommodated by many firewalls.
 Thus, FTP is an attractive alternative	to Directory access protocols
 for certificate and CRL distribution. While this service satisfies
 the requirement to retrieve information related to a certificate
 which is already identified by	a URI, it is not intended to satisfy
 the more general problem of finding a certificate for a user about
 whom some other information, such as their electronic mail address or
 corporate affiliation,	is known.

 For convenience, the names of files that contain certificates should
 have a	suffix of ".cer". Each ".cer" file contains exactly one
 certificate, encoded in DER format. Likewise, the names of files
 that contain CRLs should have a suffix	of ".crl". Each	".crl" file
 contains exactly one CRL, encoded in DER format.

3 HTTP Conventions

 Within	certificate extensions and CRL extensions, the URI form	of
 GeneralName is	used to	specify	the location where issuer certificates
 and CRLs may be obtained. For instance, a URI identifying the
 subject of a certificate may be carried in subjectAltName certificate
 extension. An IA5String describes the use of HTTP to fetch
 certificate or	CRL information. For example:

 http://www.netcom.com/sp/spyrus/housley.cer
 http://www.your.org/pki/id48.cer
 http://www.your.org/pki/id48.no42.crl

 Internet users	may publish the	URI reference to a file	that contains
 their certificate on their business card. This	practice is useful
 when there is no Directory entry for that user. HTTP is widely
 deployed, and HTTP is accommodated by many firewalls. Thus, HTTP is
 an attractive alternative to Directory	access protocols for
 certificate and CRL distribution. While this service satisfies	the
 requirement to	retrieve information related to	a certificate which is
 already identified by a URI, it is not	intended to satisfy the	more
 general problem of finding a certificate for a	user about whom	some
 other information, such as their electronic mail address or corporate
 affiliation, is known.

 For convenience, the names of files that contain certificates should
 have a	suffix of ".cer". Each ".cer" file contains exactly one
 certificate, encoded in DER format. Likewise, the names of files
 that contain CRLs should have a suffix	of ".crl". Each	".crl" file
 contains exactly one CRL, encoded in DER format.






Housley	[Page 4]





INTERNET DRAFT                                             November 1997 April 1998


 Two MIME types	are defined to support the tranfer transfer of certificates
 and CRLs. They	are:

 application/pkix-cert[; version=1]
 application/pkix-crl[;	version=1]

References

 [RFC 959] J. Postel and J. Reynolds, "File Transfer Protocol (FTP),"
 RFC 959, October 1985.

 [RFC 1738] T. Berners-Lee, L. Masinter, and M.	McCahill, "Uniform
 Resource Locators (URL)," December 1994.

 [RFC 2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and
 T. Berners-Lee; "Hypertext Transfer Protocol -- HTTP/1.1,"
 RFC 2068, January 1997.

Security Considerations

 Since certificates and	CRLs are digitally signed, no additional
 integrity service is necessary. Neither certificates nor CRLs need
 be kept secret, and anonymous access to certificates and CRLs is
 generally acceptable. So, no privacy service is necessary.

 Operators of FTP sites	and World Wide Web servers should authenticate
 end entities who publish certificates as well as CAs and RAs who
 publish certificates and CRLs.	However, authentication	is not
 necessary to retrieve certificates and	CRLs.

Author Address

 Russell Housley
 SPYRUS
   PO Box 1198
 381 Elden Street
 Suite 1120
 Herndon, VA 20172 20170
 USA
 housley@spyrus.com












Housley	[Page 5]

----