idnits 2.17.1 draft-vb-openpgp-uri-attribute-01.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 draft header indicates that this document updates RFC4880, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4880, updated by this document, for RFC5378 checks: 1999-12-21) -- 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.) -- The document date (May 5, 2015) is 3250 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) == Missing Reference: 'TBD' is mentioned on line 88, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force V. Breitmoser 3 Internet-Draft 4 Updates: 4880 (if approved) May 5, 2015 5 Intended status: Standards Track 6 Expires: November 6, 2015 8 URI Attributes for OpenPGP 9 draft-vb-openpgp-uri-attribute-01 11 Abstract 13 This specification extends OpenPGP with the URI Attribute as a new 14 type of User Attribute. 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 November 6, 2015. 33 Copyright Notice 35 Copyright (c) 2015 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 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.2. Conventions Used in This Document . . . . . . . . . . . . 2 53 2. URI User Attribute subpacket . . . . . . . . . . . . . . . . 2 54 3. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 57 6. Normative References . . . . . . . . . . . . . . . . . . . . 3 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1. Introduction 62 The OpenPGP specification [RFC4880] allows primary keys to associate 63 themselves with identities in the form of User ID and User Attribute 64 packets. The only defined type of User Attribute is JPEG. This 65 document introduces the URI subpacket as an additional type of User 66 Attribute subpacket. 68 1.1. Scope 70 Similar to RFC 4880, the scope of this document is limited to a 71 technical description of the format, and does not include specifics 72 on how URI Attributes may be used by implementations. 74 1.2. Conventions Used in This Document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. Any 79 implementation that adheres to the format and methods specified in 80 this document is called a compliant application. Compliant 81 applications are a subset of the broader set of OpenPGP applications 82 described in [RFC4880]. Any [RFC2119] keyword within this document 83 applies to compliant applications only. 85 2. URI User Attribute subpacket 87 The URI subpacket is added as an additional User Attribute subpacket 88 with type id [TBD] to expand Section 5.12 of the OpenPGP 89 specification [RFC4880], "User Attribute Packet (Tag 17)". The body 90 of this subpacket consists of a single UTF-8 encoded URI string. A 91 URI Attribute is a User Attribute packet with a single URI subpacket. 93 The purpose of this packet type is to provide a mechanism for 94 associating the key with an identity encoded in a URI. The 95 particular semantics of a URI depend on its scheme, there are no 96 restrictions on the URIs which may appear in URI Attributes. 98 An implementation SHOULD NOT issue certificates for URI Attributes 99 with unknown URI schemes. It MAY treat such packets as opaque, or 100 display their contents in a generic way. 102 3. Compatibility 104 An implementation SHOULD NOT use a URI Attribute to fulfill the 105 minimum requirement of one User ID packet in a transferable key. 106 This is to ensure that at least one non-opaque type of user id is 107 part of every key. 109 4. IANA Considerations 111 IANA is requested to assign a number to the URI User Attribute 112 subpacket, updating the User Attribute Type namespace established in 113 [RFC4880]. See Section 2. 115 +------+---------------------+-----------+ 116 | ID | User Attribute Type | Reference | 117 +------+---------------------+-----------+ 118 | TBD1 | URI | This doc | 119 +------+---------------------+-----------+ 121 [Notes to RFC-Editor: Please remove the table above on publication. 122 There are no non-standardized types used in current implementations 123 known to the author. As of now 2 is the next free number.] 125 5. Security Considerations 127 The security considerations of the URI Attribute are the same as for 128 other identity packets, leaving the considerations from [RFC4880] 129 unchanged. 131 6. Normative References 133 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 134 Requirement Levels", BCP 14, RFC 2119, March 1997. 136 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 137 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 139 Author's Address 141 Vincent Breitmoser 142 Braunschweig 143 DE 145 Email: v.breitmoser@my.amazin.horse