RFC 4386

RFC 4386: Internet X.509 Public Key Infrastructure Repository Locator Service 🎀

Okay bestie, so this one is an Experimental protocol doc (not a full standard, just a "hey, try this out and tell us what you think" vibe 🧪). It's from February 2006 and it's written by Sharon Boeyen (Entrust Inc.) and Phillip M. Hallam-Baker (VeriSign Inc.). The title block doesn't list any Obsoletes or Updates, so it isn't replacing or changing anything else. 💅

Status of This Memo ✨

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested, and distribution of this memo is unlimited. 🦋

Copyright Notice 💜

Copyright (C) The Internet Society (2006).

Abstract 🌸

So this document defines a PKI repository locator service, which is a fancy way of saying it helps certificate-using systems find PKI repositories. It runs on DNS SRV records, which are defined in RFC 2782. Basically it's how certificate systems go "wait, where do I even find this stuff?" and get an answer. 🧚

Table of Contents 🍓

1. Overview ........................................................2
   1.1. Conventions Used in This Document ..........................2
2. SRV RR Definition ...............................................2
   2.1. Assignment of New Protocol Prefixes ........................3
   2.2. Use of Multiple Repositories ...............................3
   2.3. SRV RR Example .............................................3
3. Security Considerations .........................................4
4. IANA Considerations .............................................4
5. Informative References ..........................................4

1. Overview 🔥

Okay so a bunch of RFCs (including [RFC2559], [RFC2560], and [RFC2585]) already wrote protocols for grabbing PKI stuff like public-key certificates and revocation info from PKI repositories. The catch is that those RFCs just assume your certificate-using system already knows how to find the repository and connect to it with the right protocol. Some tools exist for this, like knowledge references in directory systems, but they're locked to one protocol and don't share a common way of publishing anything. Lowkey messy. 😭

So this doc fixes that problem by using Service Record (SRV) Resource Records (RRs) in DNS. It's expected to be especially useful when a domain name is the only thing you've got. If you already have a certificate that contains the info you need, you don't need that DNS lookup at all. ✨

[RFC2782] is the one that defines SRV records for locating services. This document uses them to create a PKI repository locator service, so PKI clients can get everything they need to connect to a domain's PKI repository. That includes info about every protocol that domain supports for accessing its repository. The doc gives the SRV RR format for this service and shows an example of how it could work in an email environment. 📧💖

1.1. Conventions Used in This Document 🧠

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].

In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. 🫶

2. SRV RR Definition 🎀

The SRV RR has DNS type code 33, and it looks like this:

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

For the PKI repository locator service, this document uses the symbolic name "PKIXREP". Heads up: when it's used in an SRV RR, this name MUST be prepended with an "_" character. Don't skip it, periodt! 🙈

The protocols that can be included in PKIXREP SRV RRs are:

Protocol     SRV Prefix

LDAP         _LDAP
HTTP         _HTTP
OCSP         _OCSP

2.1. Assignment of New Protocol Prefixes 🌈

Protocol prefix assignments for new PKIX repository protocols SHOULD be defined in the document that specifies the protocol. 👑

2.2. Use of Multiple Repositories 🦋

The existence of multiple repositories MAY be determined by making separate DNS queries for each of the protocols supported by the client.

If this approach turns out to be unacceptably inefficient because a bunch of repository protocols show up in the future, the service discovery protocol could be extended so the repository can advertise which protocols it supports. 🔮

2.3. SRV RR Example 💅

This example uses the fictional domain "example.com" to help show how a certificate-using system uses SRV records. It's giving textbook vibes, bestie. 📚

Say Alice is an email client who needs a certificate for a recipient. Alice's client supports LDAP for certificate retrieval. The recipient is Bob, whose email address is bob@example.com. The example also says that example.test keeps a "border directory" PKI repository, and Bob's certificate can be grabbed from that directory, "border.example.com", over LDAP. 💌

Alice's client gets the SRV record for _PKIXREP._LDAP.example.com through DNS:

• The QNAME of the DNS query is _PKIXREP._LDAP.example.com.
• The QCLASS of the DNS query is IN.
• The QTYPE of the DNS query is SRV.

The result SHOULD include the host address for example.com's border directory system. ✨

Now, if example.com ran this service on a bunch of hosts, more than one SRV RR would come back. In that case, RFC 2782 spells out how to decide which one to try first. Main character ordering energy 👑

3. Security Considerations 💀

Security issues with the PKI repositories themselves are outside the scope of this document. For LDAP repositories, for example, the specific security considerations are covered in RFC 2559.

Security issues with SRV records in general are covered in RFC 2782, and those issues apply to using SRV records for the PKIXREP service defined here. Treat this section seriously, bestie. It's a whole thing. 🔐

4. IANA Considerations 🧚

This document reserves the "_PKIXREP" service label. This relates to a service that may pass messages over a number of different message transports, so each message has to be associated with a specific transport. 🚚

To make sure the link between "_PKIXREP" and its underlying services is deterministic, IANA has created a new registry called PKIX SRV Protocol Labels. Each entry in this registry consists of a label name and a pointer to a specification describing how the protocol named in the label uses SRV. Specifications should conform to the requirements listed in [RFC2434] for "specification required". 📋

5. Informative References 📖

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[RFC2559] Boeyen, S., Howes, T., and P. Richard, "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2", RFC 2559, April 1999.

[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.

[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.

Authors' Addresses 🦋

Sharon Boeyen
Entrust
1000 Innovation Drive
Ottawa, Ontario
Canada K2K 3E7

EMail: sharon.boeyen@entrust.com


Phillip M. Hallam-Baker
VeriSign Inc.
401 Edgewater Place, Suite 280
Wakefield MA 01880

EMail: pbaker@VeriSign.com

---

Full Copyright Statement 💖

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property 🔮

The IETF takes no position on whether any Intellectual Property Rights or other rights that someone might claim cover the technology in this document are valid or in scope. It also doesn't say whether any license under those rights is or isn't available, and it hasn't made any independent effort to find such rights. Info about how RFC documents handle rights lives in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission for implementers or users to use these proprietary rights can all be found through the IETF online IPR repository at http://www.ietf.org/ipr.

The IETF also invites any interested party to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 📬

Acknowledgement 🌸

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 💜