idnits 2.17.1 draft-atkins-openpgp-device-certificates-03.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 directly say this. It does mention RFC4880 though, so this could be OK. 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 (June 09, 2015) is 3243 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: 'Binding-Signature-Revocation' is mentioned on line 124, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Atkins 3 Internet-Draft SecureRF Corporation 4 Updates: 4880 (if approved) June 09, 2015 5 Intended status: Standards Track 6 Expires: December 11, 2015 8 OpenPGP Extensions for Device Certificates 9 draft-atkins-openpgp-device-certificates-03 11 Abstract 13 The OpenPGP Message Formats defined in RFC 4880 specify packet 14 formats and methods for combining those packets to form messages and 15 certificates. However RFC 4880 made an architectural decision that 16 keys are owned by users and must be self-certified. New use cases 17 have emerged where that is not the case. There is a desire to have 18 certificates that are not tied to a user (e.g. device certificates) 19 which may only have encryption keys so may not be self certifiable. 20 Moreover, devices might be space constrained so reducing size is 21 important. This draft specifies extensions to (and updates) RFC 4880 22 that loosen the definitions of certificates in order to enable 23 userless certificates without self-certifications and specifies a set 24 of notations to enable compact device certifications. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 11, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Device Certificate Format . . . . . . . . . . . . . . . . . . 3 63 3. User ID Attribute Subpacket . . . . . . . . . . . . . . . . . 4 64 4. Device Certification Notations . . . . . . . . . . . . . . . 4 65 4.1. The 'manu' Notation . . . . . . . . . . . . . . . . . . . 4 66 4.2. The 'make' Notation . . . . . . . . . . . . . . . . . . . 5 67 4.3. The 'model' Notation . . . . . . . . . . . . . . . . . . 5 68 4.4. The 'prodid' Notation . . . . . . . . . . . . . . . . . . 5 69 4.5. The 'pvers' Notation . . . . . . . . . . . . . . . . . . 5 70 4.6. The 'lot' Notation . . . . . . . . . . . . . . . . . . . 5 71 4.7. The 'qty' Notation . . . . . . . . . . . . . . . . . . . 5 72 4.8. The 'loc' and 'dest' Notations . . . . . . . . . . . . . 5 73 4.9. The 'hash' Notation . . . . . . . . . . . . . . . . . . . 6 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 6.1. PGP User Attribute Types . . . . . . . . . . . . . . . . 6 77 6.2. Signature Notation Data Subpacket Types . . . . . . . . . 7 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 8.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 OpenPGP [RFC4880] defines a standard, compact format for, among other 87 things, sharing keys and signature certificates. Unfortunately the 88 specification is user-focused, assuming that there are people sitting 89 at the ends and creating and managing those keys. New use cases have 90 come up where that is not the case and the endpoint for these keys 91 are devices, not users. Yet we still want to be able to certify 92 these device keys. 94 Since the publication of RFC 4880, new use cases have emerged that 95 don't fit into the existing standard models. For example, the 96 Internet of Things have introduced devices that need to certify 97 device-level encryption keys but cannot self-certify and have no user 98 associated. This draft suggests extensions to RFC 4880 that enable 99 those use cases and make it easier to have device certificates using 100 OpenPGP. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. Device Certificate Format 110 RFC 4880 section 12.1 defines a v4 Public Key Format as a sequence of 111 packets starting with a Primary Key and then a sequence of packets 112 and subpackets that add Revocations, User IDs, and Signatures. 114 The description in RFC 4880 requires a User ID. Implementors of this 115 specification can loosen that requirement such that an augmented V4 116 device certificate looks like the following sequence (no longer 117 requiring a User ID packet): 119 Primary-Key 120 [Revocation Self Signature] 121 [Direct Key Signature...] 122 [User ID [Signature ...] ...] 123 [User Attribute [Signature ...] ...] 124 [[Subkey [Binding-Signature-Revocation] 125 Primary-Key-Binding-Signature] ...] 127 Note that RFC 4880 section 11.1 defines this same sequence in text 128 for transferable public keys. Implementors of this specification can 129 change that definition from "One or more User ID packets" to "Zero or 130 more User ID packets". 132 Moreover, one more relaxation from section 12.1. RFC 4880 states 133 that "In a V4 key, the primary key MUST be a key capable of 134 certification." Implementors of this specification can loosen that 135 restriction as well, such that in V4 augmented key, the primary key 136 MAY be a key capable of certification. 138 A primary key capable of making signatures SHOULD be accompanied by 139 either a certification signature (on a User ID or User Attribute) or 140 a signature directly on the key. 142 Implementations MUST accept encryption-only primary keys without a 143 signature. It also MUST allow importing any key accompanied either 144 by a certification signature or a signature on itself. It MAY accept 145 signature-capable primary keys without an accompanying signature. 147 3. User ID Attribute Subpacket 149 Section 5.12 of RFC 4880 defines the User Attribute Packet which can 150 be used in lieu of a User ID Packet. Whereas the User ID Packet only 151 allows a single UTF-8 string content, the User Attribute Packet 152 allows the addition of multiple attributes in subtype packets. 153 Unfortunately RFC 4880 only defined a single Attribute Subpacket, the 154 Image Attribute. This means that you need two signatures if you want 155 to have an ID and an image. 157 To solve that problem for device certificates we define a new User 158 Attribute Subpacket, the User ID Attribute Subpacket, type #[IANA -- 159 assignment TBD1]. A User ID Attribute subpacket, just like a User ID 160 packet, consists of UTF-8 text that is intended to represent the name 161 and email address of the key holder. By convention, it includes an 162 RFC 2822 [RFC2822] mail name-addr, but there are no restrictions on 163 its content. For devices, it may be the device identifier. The 164 packet length in the header specifies the length of the User ID. 166 Note that RFC 4880 already allows a User Attribute packet anywhere a 167 User ID packet can be used. See RFC 4880 section 5.2.3.19 (Primary 168 User ID) for more information on self-signatures over these kinds of 169 packets. Any signature on a User Attribute packet covers all 170 subpackets. Implementations MAY decide to trust the User ID 171 Subpacket. 173 4. Device Certification Notations 175 OpenPGP defines a signature notation data packet that allows 176 implementors and users to add extra data to signatures. RFC 4880 177 defined a registry for a global namespace and requires using 178 name@dom.ain domain-name notations otherwise. Many of the devices 179 targeted by this specification have limited storage capability, so it 180 behooves an implementor to limit the extraneous storage. 182 These notations can be important when you have a third-party device 183 certification. That third party might want to add extra data about 184 the device to its signature certification. In order to keep the 185 certificate smaller we define a set of notations that MAY be used 186 when signing a device certificate. 188 4.1. The 'manu' Notation 189 The "manu" notation is a string that declares the device 190 manufacturer's name. The certifier key is asserting this string 191 (which may or may not be related to the User ID of the certifier's 192 key). 194 4.2. The 'make' Notation 196 This notation defines the product make. It is a free form string. 198 4.3. The 'model' Notation 200 This notation defines the product model name/number. It is a free 201 form string. 203 4.4. The 'prodid' Notation 205 This notation contains the product identifier. It is a free form 206 string. 208 4.5. The 'pvers' Notation 210 This notation defines the product version number (which could be a 211 release number, year, or some other identifier to differentiate 212 different versions of the same make/model). It is a free form 213 string. 215 4.6. The 'lot' Notation 217 This notation defines the product lot number (which is an indicator 218 of the batch of product). It is a free form string. 220 4.7. The 'qty' Notation 222 This notation defines the quantity of items in this package. It is a 223 decimal integer representation with no punctuation, e.g. "10", 224 "1000", "10000", etc. 226 4.8. The 'loc' and 'dest' Notations 228 The "loc" and 'dest' notations declare a GeoLocation as defined by 229 RFC 5870 [RFC5870] but without the leading "geo:" header. For 230 example, if you had a GeoLocation URI of "geo:13.4125,103.8667" you 231 would encode that in these notations as "13.4125,103.8667". 233 The 'loc' notation is meant to encode the geo location where the 234 signature was made. The 'dest' notation is meant to encode the geo 235 location where the device is "destined" (i.e., a "destination" for 236 the device). 238 4.9. The 'hash' Notation 240 A 'hash' notation is a means to include external data in the contents 241 of a signature without including the data itself. This is done by 242 hashing the external data separately and then including the data's 243 name and hash in the signature via this notation. This is useful, 244 for example, to have an external "manifest," "image," or other data 245 that might not be vital to the signature itself but still needs to be 246 protected and authenticated without requiring a second signature. 248 The 'hash' notation has the following structure: 250 o A single byte specifying the length of the name of the hashed data 252 o A UTF-8 string of the name of the hashed data 254 o A single byte specifying the hash algorithm (see RFC 4880 section 255 9.4) 257 o The binary hash output of the hashed data using the specified 258 algorithm. (The length of this data is implicit based on the 259 algorithm specified). 261 Due to its nature a 'hash' notation is not human readable and MUST 262 NOT be marked as such when used. 264 5. Acknowledgements 266 A big thank you to Werner Koch, David Shaw, Jon Callas, Daniel Nagy, 267 and David Leon Gil for their input on the concepts and text of this 268 document. 270 6. IANA Considerations 272 This document requests IANA to register several items within the 273 OpenPGP parameters (or the "name space" in the terminology of 274 [RFC5226]) created by [RFC4880]. 276 6.1. PGP User Attribute Types 278 This specification asks IANA to register a PGP User Attribute Type: 280 +-------+-----------+--------------------+ 281 | Value | Attribute | Reference | 282 +-------+-----------+--------------------+ 283 | TBD1 | User ID | This Doc Section 3 | 284 +-------+-----------+--------------------+ 286 Table 1: User Attribute Types 288 6.2. Signature Notation Data Subpacket Types 290 This specification asks IANA to register a set of OpenPGP Signature 291 Notation Data Subpacket Types defined in Section 4. The following 292 table is a summary of the requested registrations. 294 +--------------+---------+--------------------------+---------------+ 295 | Allowed | Name | Type | Reference | 296 | Values | | | | 297 +--------------+---------+--------------------------+---------------+ 298 | Any String | manu | Manufacturer Name | This doc | 299 | | | | Section 4.1 | 300 +--------------+---------+--------------------------+---------------+ 301 | Any String | make | Product Make | This doc | 302 | | | | Section 4.2 | 303 +--------------+---------+--------------------------+---------------+ 304 | Any String | model | Product Model | This doc | 305 | | | | Section 4.3 | 306 +--------------+---------+--------------------------+---------------+ 307 | Any String | prodid | Product ID | This doc | 308 | | | | Section 4.4 | 309 +--------------+---------+--------------------------+---------------+ 310 | Any String | pvers | Product Version | This doc | 311 | | | | Section 4.5 | 312 +--------------+---------+--------------------------+---------------+ 313 | Any String | lot | Product Lot Number | This doc | 314 | | | | Section 4.6 | 315 +--------------+---------+--------------------------+---------------+ 316 | Decimal | qty | Package Quantity | This doc | 317 | Integer | | | Section 4.7 | 318 | String | | | | 319 +--------------+---------+--------------------------+---------------+ 320 | A geo: URI | loc | Current Geo-location | This doc | 321 | without the | | Latitude/Longitude | Section 4.8 | 322 | "geo:" | | | | 323 +--------------+---------+--------------------------+---------------+ 324 | A geo: URI | dest | Destination Geo-location | This doc | 325 | without the | | Latitude/Longitude | Section 4.8 | 326 | "geo:" | | | | 327 +--------------+---------+--------------------------+---------------+ 328 | Hash | hash | The Hash of external | This doc | 329 | Notation | | data | Section 4.9 | 330 | data | | | | 331 +--------------+---------+--------------------------+---------------+ 333 Table 2: Device Certificate Notations 335 7. Security Considerations 337 The Security Considerations of [RFC4880] apply. 339 OpenPGP was designed with security in mind, with many smart, 340 intelligent people spending a lot of time thinking about the 341 ramifications of their decisions. Removing the requirement for self- 342 certifying User ID (and User Attribute) packets on a key means that 343 someone could surreptitiously add an unwanted ID to a key and sign 344 it. If enough "trusted" people sign that surreptitious identity then 345 other people might believe it. The attack could wind up sending 346 encrypted mail destined for alice to some other target, bob, because 347 someone added "alice" to bob's key without bob's consent. 349 In the case of device certificates the device itself does not have 350 any consent. It is given an identity by the device manufacturer and 351 the manufacturer can insert that ID on the device certificate, 352 signing it with the manufacturer's key. If another people wants to 353 label the device by another name, they can do so. There is no harm 354 in multiple IDs, because the verification is all done based on who 355 has signed those IDs. 357 When a key can self-sign, it is still suggested to self-certify IDs, 358 even if it no longer required by this modification to OpenPGP. This 359 at least signals to recipients of keys that yes, the owner of this 360 key asserts that this identity belongs to herself. Note, however, 361 that mallet could still assert that he is 'alice' and could even 362 self-certify that. So the attack is not truly different. Moreover, 363 in the case of device certificates, it's more the manufacturer than 364 the device that wants to assert an identity (even if the device could 365 self-certify). 367 There is no signaling whether a key is using this new, looser- 368 requirement key format. An attacker could therefore just remove the 369 self-signature off a published key. However one would hope that wide 370 publication would result in another copy still having that signature 371 and it being returned quickly. However, the lack of signaling also 372 means that a user with an application following RFC 4880 directly 373 would see a key following this specification as "broken" and may not 374 accept it. 376 On a different note, including the "geo" notation could leak 377 information about where a signer is located. However it is just an 378 assertion (albeit a signed assertion) so there is no verifiable truth 379 to the location information released. Similarly, all the rest of the 380 signature notations are pure assertions, so they should be taken with 381 the trustworthiness of the signer. 383 Combining the User ID with the User Attribute means that an ID and 384 image would not be separable. For a person this is probably not 385 good, but for a device it's unlikely the image will change so it 386 makes sense to combine the ID and image into a single signed packet 387 with a single signature. 389 8. References 391 8.1. Normative References 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 397 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 399 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 400 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 401 May 2008. 403 8.2. Informative References 405 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 406 2001. 408 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 409 Identifier for Geographic Locations ('geo' URI)", RFC 410 5870, June 2010. 412 Author's Address 414 Derek Atkins 415 SecureRF Corporation 416 100 Beard Sawmill Rd, Suite 350 417 Shelton, CT 06484 418 US 420 Phone: +1 617 623 3745 421 Email: datkins@securerf.com, derek@ihtfp.com