idnits 2.17.1 draft-seantek-certfrag-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 8, 2014) is 3517 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Leonard 3 Internet-Draft Penango, Inc. 4 Intended status: Standards Track September 8, 2014 5 Expires: March 12, 2015 7 URI Fragment Identifiers for the application/pkix-cert Media Type 8 draft-seantek-certfrag-00 10 Abstract 12 This memo describes Uniform Resource Identifier (URI) fragment 13 identifiers for PKIX certificates, which are identified with the 14 Internet media type application/pkix-cert. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 12, 2015. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 1. Fragment 50 A digital certificate [RFC5280] is comprised of parts that are of 51 interest to particular users and applications. For example, a user 52 agent may wish to draw attention to the "notAfter" time for an 53 expired certificate. Uniform Resource Indicators (URIs) can include 54 fragment identifiers to identify such sub-parts of a resource; see 55 Section 3.5 of [RFC3986]. However, the semantics of fragment 56 identifiers depend upon the Internet media type [RFC2046], not the 57 URI scheme. Therefore, the fragment identifiers in this memo apply 58 to the application/pkix-cert Internet media type [RFC2585]. The 59 following fragments are hereby defined: 61 +------------+------------------------------------------------------+ 62 | Identifier | Certificate Part (ASN.1 identifier) | 63 +------------+------------------------------------------------------+ 64 | v | tbsCertificate.version | 65 | sn | tbsCertificate.serialNumber | 66 | sig | tbsCertificate.signature; also signatureAlgorithm | 67 | issuer | tbsCertificate.issuer | 68 | nb | tbsCertificate.validity.notBefore | 69 | na | tbsCertificate.validity.notAfter | 70 | subject | tbsCertificate.subject | 71 | spki | tbsCertificate.subjectPublicKeyInfo | 72 | ext | tbsCertificate.extensions | 73 | ext: | tbsCertificate.extensions | 74 | | {Extension matching extoid == extnID}* | 75 | sigval | signatureValue | 76 +------------+------------------------------------------------------+ 78 * The particular extension in the Extensions "SEQUENCE" is identified 79 by OID only; there are no textual identifiers. The syntax of the 80 matches the "numericoid" production of [RFC4512]. 82 Table 1: Certificate Parts and Fragments 84 The fragments defined in the table above are case-insensitive. 85 However, a generator that complies with this memo MUST produce the 86 fragment identifiers with the exact casing as provided above. The 87 table is not exhaustive: should additional identifiers be required, a 88 future document may specify additional identifiers. 90 The key word "MUST" in this document is to be interpreted as 91 described in RFC 2119 [RFC2119]. 93 2. IANA Considerations 95 IANA needs to add a reference to this specification in the 96 application/pkix-cert media type registration. 98 Additionally, the registration template needs to be updated to add 99 the following section: 101 Fragment identifier considerations: Fragment identification is 102 supported by using fragment identifiers as specified by this memo. 104 3. Security Considerations 106 Digital certificates are important building blocks for 107 authentication, integrity, authorization, and (occasionally) 108 confidentiality services. Accordingly, identifying digital 109 certificates incorrectly can have significant security ramifications. 111 A URI that identifies a certificate will likely be used by an 112 application or user for some security-related service, such as to 113 retrieve the certificate as part of a validation procedure. When a 114 fragment identifies a part of a certificate, the application will 115 define the behavioral semantics. A certificate displaying 116 application might zoom in on that aspect of the certificate, while a 117 public key-processing application might use a fragment identifier 118 like "#spki" to extract the "SubjectPublicKeyInfo" structure for 119 further processing. Interpreting these identifiers incorrectly may 120 cause denial-of-service attacks. 122 4. Normative References 124 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 125 Extensions (MIME) Part Two: Media Types", RFC 2046, 126 November 1996. 128 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 129 Requirement Levels", BCP 14, RFC 2119, March 1997. 131 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 132 Infrastructure Operational Protocols: FTP and HTTP", RFC 133 2585, May 1999. 135 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 136 Resource Identifier (URI): Generic Syntax", STD 66, RFC 137 3986, January 2005. 139 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 140 (LDAP): Directory Information Models", RFC 4512, June 141 2006. 143 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 144 Housley, R., and W. Polk, "Internet X.509 Public Key 145 Infrastructure Certificate and Certificate Revocation List 146 (CRL) Profile", RFC 5280, May 2008. 148 Author's Address 150 Sean Leonard 151 Penango, Inc. 152 5900 Wilshire Boulevard 153 21st Floor 154 Los Angeles, CA 90036 155 USA 157 Email: dev+ietf@seantek.com 158 URI: http://www.penango.com/