RFC 2585

Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP

📅 published May 1999, from ietf

Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP 🎀

RFC 2585 🌸 (part 1 of 2) — this one is a Standards Track protocol doc from the Network Working Group, dated May 1999. It was written by R. Housley (SPYRUS) and P. Hoffman (IMC). The header doesn't list any RFC that it obsoletes or updates, so it's standing on its own, bestie 💅

Status of this Memo ✨

okay so this is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 If you want to know where this protocol actually stands, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 💖

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 🦋

the protocol conventions in this doc help meet some of the operational needs of the Internet Public Key Infrastructure (PKI) 🔥 It explains how to use the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to grab certificates and certificate revocation lists (CRLs) from PKI repositories. Other mechanisms for PKIX operational needs live in separate documents 📚

1. Introduction 🧚

this spec is one piece of a multi-part standard for the Internet PKI, which uses X.509 certificates and CRLs 💅 The main point here is spelling out how to use FTP and HTTP to get certificates and CRLs out of PKI repositories. More ways to access repositories are covered in other documents, so don't panic if something's missing here 🙈

1.1. Model 🌈

this is a simplified picture of the architecture the Internet PKI specs assume 👑

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

here are the players in this model 🎀

  • End Entity: a user of PKI certificates and/or an end user system that is the subject of a certificate 🫶
  • CA: certification authority 👑
  • RA: registration authority, which is an optional system that a CA hands certain management functions off to 🦋
  • Repository: a system, or a collection of distributed systems, that stores certificates and CRLs and acts as the way those certificates and CRLs get handed out to end entities 📚

1.2. Certificate and CRL Repository 🍓

some CAs insist on online validation services, while others publish CRLs so certificate users can validate certificates themselves 💅 Generally, CAs make CRLs available to certificate users by publishing them in the Directory. The Directory is also the usual way certificates get distributed 🌸 The catch is that Directory Services aren't available in many parts of the Internet today 🙈 That's where the File Transfer Protocol (FTP) defined in RFC 959 and the Hypertext Transfer Protocol (HTTP) defined in RFC 2068 come in as alternate ways to distribute certificates and CRLs ✨

End entities and CAs can pull certificates and CRLs from the repository using FTP or HTTP. End entities can also publish their own certificate in the repository with FTP or HTTP, and RAs and CAs can publish certificates and CRLs there too 💖

2. FTP Conventions 🦋

okay this part is the FTP rulebook 📚 Inside certificate extensions and CRL extensions, the URI form of GeneralName is what tells you where to find issuer certificates and CRLs 🔥 For example, a URI that identifies the subject of a certificate can ride along in the subjectAltName certificate extension. An IA5String describes using anonymous FTP to fetch certificate or CRL info, like these:

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

people can put the URI of the file holding their certificate on their business card 💅 That's especially handy when there's no Directory entry for that person. FTP is everywhere, and anonymous FTP is accommodated by lots of firewalls, so FTP is a super attractive option next to Directory access protocols for certificate and CRL distribution 🌈 This works when you already have the URI for the certificate and want to retrieve info about it. It's not meant for finding a certificate for someone when all you know is other stuff, like their email address or company affiliation 🙈

for convenience, files that hold certificates should have a ".cer" suffix. Each ".cer" file holds exactly one certificate, encoded in DER format 💜 Same deal for CRLs: files should end in ".crl", and each ".crl" file holds exactly one CRL, encoded in DER format ✨

3. HTTP Conventions 🌸

this section is basically the same vibe, but for HTTP 🫶 Inside certificate extensions and CRL extensions, the URI form of GeneralName tells you where to get issuer certificates and CRLs. A URI that identifies the subject of a certificate can be carried in the subjectAltName certificate extension. An IA5String describes using HTTP to fetch certificate or CRL info, like these:

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

again, people can share the URI of their certificate file on their business card, which is useful when there's no Directory entry for them 🎀 HTTP is widely deployed, and it's accommodated by many firewalls too, so HTTP is an attractive alternative to Directory access protocols for certificate and CRL distribution 🦋 Same catch as FTP: this works when you already have the certificate's URI, but it isn't meant for finding a certificate from other info like an email address or corporate affiliation 🙈

same naming rules as before: certificate files should have a ".cer" suffix with exactly one DER-encoded certificate each, and CRL files should have a ".crl" suffix with exactly one DER-encoded CRL each 💖

4. MIME registrations 💅

two MIME types get defined to support transferring certificates and CRLs ✨

application/pkix-cert
application/pkix-crl

4.1. application/pkix-cert 🔥

here's the registration template for the certificate type, the way it was sent to ietf-types@iana.org 💌

To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkix-cert

MIME media type name: application

MIME subtype name: pkix-cert

Required parameters: None

Optional parameters: version (default value is "1")

Encoding considerations: will be none for 8-bit transports and most
likely Base64 for SMTP or other 7-bit transports

Security considerations: Carries a cryptographic certificate

Interoperability considerations: None

Published specification: draft-ietf-pkix-ipki-part1

Applications which use this media type: Any MIME-complaint transport

Additional information:
  Magic number(s): None
  File extension(s): .CER
  Macintosh File Type Code(s): none

Person & email address to contact for further information:
Russ Housley <housley@spyrus.com>

Intended usage: COMMON

Author/Change controller:
Russ Housley <housley@spyrus.com>

4.2. application/pkix-crl 🌈

and here's the same kind of template for the CRL type 👑

To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkix-crl

MIME media type name: application

MIME subtype name: pkix-crl

Required parameters: None
Optional parameters: version (default value is "1")

Encoding considerations: will be none for 8-bit transports and most
likely Base64 for SMTP or other 7-bit transports

Security considerations: Carries a cryptographic certificate
revocation list

Interoperability considerations: None

Published specification: draft-ietf-pkix-ipki-part1

Applications which use this media type: Any MIME-complaint transport

Additional information:
  Magic number(s): None
  File extension(s): .CRL
  Macintosh File Type Code(s): none

Person & email address to contact for further information:
Russ Housley <housley@spyrus.com>

Intended usage: COMMON

Author/Change controller:
Russ Housley <housley@spyrus.com>

Authors' Addresses ✨

Here's where the authors can be found, bestie 🫶

Russell Housley 👑 SPYRUS 381 Elden Street, Suite 1120 Herndon, VA 20170 USA

EMail: housley@spyrus.com

Paul Hoffman 🦋 Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA

EMail: phoffman@imc.org

Copyright (C) The Internet Society (1999). All Rights Reserved. 🌸

Okay so, this document and translations of it can be copied and handed out to others. Derivative works that comment on it, explain it, or help with implementing it can also be made, copied, published, and distributed, in whole or in part, with no real restrictions 💅. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work 📜.

What you can't do is modify this document itself in any way. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations 🙅‍♀️. The exceptions are when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's being translated into a language other than English 🌈.

The limited permissions above are perpetual, and they will not be revoked by the Internet Society or its successors or assigns. That's a promise, bestie 💜.

This document and the information in it are provided on an "AS IS" basis. THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Not me, but the lawyers 💀.

Acknowledgement 🧚

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, ISOC, for keeping the lights on ✨🎀

📦 where this page comes from