idnits 2.17.00 (12 Aug 2021) /tmp/idnits2302/draft-ietf-pkix-pkixrep-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 1) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 86: '...when used in an SRV RR, this name MUST...' RFC 2119 keyword, line 95: '... MUST be prepended by a "_" characte...' RFC 2119 keyword, line 99: '...m administrators SHOULD create at leas...' RFC 2119 keyword, line 125: '... The result SHOULD include the host ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2119' on line 50 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft S. Boeyen 2 PKIX Working Group Entrust Technologies 3 July 2000 P. Hallam-Baker 4 Expires in January 2001 VeriSign Inc. 6 Internet X.509 Public Key Infrastructure 7 Repository Locator Service 8 10 1 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire in January 2001. Comments should 32 be sent to the PKIX mail list at: ietf-pkix@imc.org. 34 1.1 Copyright Notice 36 Copyright (C) The Internet Society (2000). All Rights Reserved. 38 2 Abstract 40 This document defines a PKI repository locator service. The service 41 makes use of DNS SRV records defined in accordance with RFC 2782. The 42 service enables certificate using systems to locate PKI repositories 43 based on a domain name, identify the protocols that can be used to 44 access the repository, and obtain addresses for the servers that host 45 the repository service. 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 48 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 49 as shown) are to be interpreted as described in [RFC2119]. 51 3 Overview 53 Operational protocols have been specified for retrieval of PKI data, 54 including public-key certificates and revocation information, from 55 PKI repositories in a number of RFCs including RFC 2559, RFC 2560 57 and RFC 2585. These RFCs assume that a certificate using system has 58 the knowledge information necessary to identify, locate and connect 59 to the PKI repository with a specific protocol. Although there are 60 some tools available in protocol-specific environments for this 61 purpose, such as knowledge references in directory systems, these 62 are restricted to use with a single protocol and do not share a 63 common means of publication. This draft provides a solution to 64 this problem through the use of SRV RRs in DNS. This solution is 65 expected to be particularly useful in environments where only a 66 domain name is available. In other situations (e.g. where a 67 certificate is available that contains the required information), 68 such a DNS lookup is not needed. 70 RFC 2782 defines a DNS RR for specifying the location of services 71 (SRV). This Internet-draft defines SRV records for a PKI 72 repository locator service to enable PKI clients to obtain the 73 necessary information to connect to a domain's PKI repository, 74 including information about each protocol that is supported by 75 that domain for access to its repository. This Internet-draft 76 includes the defininition of a SRV RR format for this service 77 and an example of its potential use in an email environment. 79 4 SRV RR definition 81 The format of the SRV RR, whose DNS type code is 33, is: 83 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 85 For the PKI repository locator service, this draft uses the symbolic 86 name "PKIXREP". Note that when used in an SRV RR, this name MUST 87 be prepended with a "_" character. 89 The protocols that can be included in PKIXREP SRV RRs are: 90 LDAP 91 HTTP 92 OCSP 94 Note that when these protocol names appear in SRV records, they 95 MUST be prepended by a "_" character. 97 Other protocols could be added in future. 99 System administrators SHOULD create at least one PKIXREP SRV RR for 100 each protocol that can be used to access their service. If the 101 service is operated on a number of hosts, additional records can 102 be created, as described in RFC 2782. 104 4.1 SRV RR example 106 This example uses fictional domain "example.test" as an aid in 107 understanding the use of SRV records by a certificate using system. 109 Let an email client that needs a certificate for a recipient be 110 Alice and assume that Alice's client system supports LDAP for 111 certificate retrieval. Let the message recipient be Bob and let 112 Bob's email address be bob@example.test. Assume that example.test 113 maintains a "border directory" PKI repository and that Bob's 115 certificate is available from that directory "border.example.test" 116 via LDAP. 118 Alice's client system retrieves, via DNS, the SRV record for 119 _PKIXREP._LDAP.example.test. 121 - the QNAME of the DNS query is _PKIXREP._LDAP.example.test 122 - the QCLASS of the DNS query is IN 123 - the QTYPE of the DNS query is SRV 125 The result SHOULD include the host address for example.test's 126 border directory system. 128 Note that if example.test operated their service on a number of 129 hosts, more than one SRV RR would be returned. In this case, 130 RFC 2782 defines the procedure to be followed in determining which 131 of these should be accessed first. 133 5 Security considerations 135 Security issues regarding PKI repositories themselves are outside 136 the scope of this specification. For LDAP repositories, for example, 137 specific security considerations are addressed in RFC 2559. 139 Security issues with respect to the use of SRV records in general 140 are addressed in RFC 2782 and these issues apply to the use of SRV 141 records in the context of the PKIXREP service defined here. 143 6 References 145 RFC 2119: Keywords for use in RFCs to indicate requirement levels. 147 RFC 2782: A DNS RR for specifying the location of services (DNS SRV) 149 RFC 2559: Internet X.509 Public Key Infrastructure 150 Operational Protocols - LDAPv2 152 RFC 2560: Internet X.509 Public Key Infrastructure 153 Online Certificate Status Protocol - OCSP 155 RFC 2585: Internet X.509 Public Key Infrastructure 156 Operational Protocols: FTP and HTTP 158 7 Authors' Addresses 160 Sharon Boeyen 161 Entrust Technologies 162 750 Heron Road, Suite 0800 163 Ottawa, Ontario 164 Canada K1V 1A7 165 email: sharon.boeyen@entrust.com 167 Phillip M. Hallam-Baker 168 VeriSign Inc. 169 401 Edgewater Place, Suite 280 170 Wakefield MA 01880 171 email: pbaker@VeriSign.com