idnits 2.17.1 draft-friel-pki-for-devices-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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 129: '... where "keyword" MUST be one of:...' RFC 2119 keyword, line 151: '...r-chosen string that MUST identify the...' RFC 2119 keyword, line 154: '...r-chosen string that MUST identify the...' RFC 2119 keyword, line 157: '...ufacturer", "model", and "serial" MUST...' RFC 2119 keyword, line 163: '...denfitier format MUST follow the ident...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2364 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) == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-07 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Friel 3 Internet-Draft R. Barnes 4 Intended status: Standards Track Cisco 5 Expires: May 3, 2018 October 30, 2017 7 PKI Certificate Identifier Format for Devices 8 draft-friel-pki-for-devices-00 10 Abstract 12 This document defines a standard Subject field identifier format for 13 certificates issued to Internet of Things (IoT) devices. This will 14 allow applications to easily and uniquely identify certificates 15 issued to devices as opposed to certificates issue to services or 16 users. The certificates will adhere to standard Web PKI 17 specifications thus ensuring interoperability with existing 18 Certificate Authorities processes and workflows, and standard client 19 and service libraries and applications. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 3, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Manufacturing vs. Deploy Time Certificates . . . . . . . . . 3 57 3. Device Information Domain Name . . . . . . . . . . . . . . . 3 58 3.1. IDevID Certificates . . . . . . . . . . . . . . . . . . . 3 59 3.2. LDevID Certificates . . . . . . . . . . . . . . . . . . . 4 60 4. Certificate Fields . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Subject Alternate Name . . . . . . . . . . . . . . . . . 5 63 4.3. Extended Key Usage . . . . . . . . . . . . . . . . . . . 5 64 4.4. Certificate Lifetime . . . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. Informative References . . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 There is an increasing need for devices to be able to uniquely 73 identify themselves and assert their identity, and associated 74 identity attributes, using standard Web PKI techniques. In order to 75 faclitate issuing certificates to devices, this document defines a 76 mechanism for uniquely identifying devices using a structured Subject 77 field identifier that should be supported by all major Certificate 78 Authorities (CAs), including those CAs that support 79 [I-D.ietf-acme-acme]. 81 The use of Web PKI for the purpose of issuing device certificates has 82 multiple benefits including: 84 o Existing code, processes, and policies for managing Web PKI 85 certificates can be re-used 87 o Device certificates can be trusted by web browsers 89 o For small-scale device manufacturers, it is possible to use 90 existing CAs to issue device certificates of this kind 92 o For more mature manufacturers, the use of structured DNS names to 93 encode device information means that name-constrained intermediate 94 CAs can be used to allow the manufacturer to issue device 95 certificates independently of the root CA. 97 Previous attempts to uniquely identify device certificates have not 98 proven to be broadly supported by common certificate management 99 software libraries. These include: 101 o [IEEE802.1AR] which defines a serialNumber field 103 o [RFC4108] which defines a hardwareModuleName field 105 2. Manufacturing vs. Deploy Time Certificates 107 Devices will typically have a unique certificate that is baked into 108 the device at manufacturing time i.e. the device will leave the 109 factory with a unique manufacturer installed certificate already 110 baked in. This certificate will typically be signed by a CA that the 111 manufacturer controls, or a CA that the manufacturer explicitly 112 authorizes. This CA does not necessarily have be a public root CA 113 that is trusted by web browsers. This certificate is referred to as 114 the Initial Device Identifier (IDevID). 116 A common deployment requirement is that the end customer that 117 purchases and deploys the device in their local domain will need to 118 install a certificate on the device that is signed by a CA under 119 their control, or signed by a CA of their choosing. This certificate 120 is referred to as the Locally Significant Device Identifier (LDevID). 122 3. Device Information Domain Name 124 A unique device identifier is encoded in a structured Device 125 Information Domain Name Identifier (DIDN-ID) of the following form: 127 ..keyword. 129 where "keyword" MUST be one of: 131 _mDevice 132 _device 134 The fields "serial", "model" and "domain" are described in the 135 following sections. 137 3.1. IDevID Certificates 139 IDevID certificates have the following form: 141 .._mDevice. 143 Where: 145 o "manufacturer" is a fully-qualified domain name identifying the 146 manufacturer of the device 148 o "_mDevice" is a mandatory keyword that indicates this is an IDevID 149 installed at manufacturing time 151 o "model" is a manufacturer-chosen string that MUST identify the 152 model or type of the device 154 o "serial" is a manufacturer-chosen string that MUST identify the 155 specific serial number of this model 157 The combination of "manufacturer", "model", and "serial" MUST 158 uniquely identify the device. 160 3.2. LDevID Certificates 162 If the LDevID is issued by a public trusted CA, then the LDevID 163 idenfitier format MUST follow the identifier format specified in this 164 section. 166 Where the LDevIDs are issued by private domain CAs that do not 167 necessarily need to adhere to CA/Browser forum guidelines, it is 168 strongly recommended that the private CA follows this identifier 169 format specification. 171 LDevID certificates have the following form: 173 .._device. 175 Where: 177 o "deployment-domain" is a fully-qualified domain name identifying 178 the local domain where the device is installed. This will 179 typically be a domain that the purchaser or owner of the device 180 can assert ownership of 182 o "_device" is a mandatory keyword that indicates this is an LDevID 183 installed during live deployment 185 o "model" this SHOULD be copied from the IDevID of the device 187 o "serial" this SHOULD be copied from the IDevID of the device 189 The combination of "manufacturer", "model", and "serial" SHOULD 190 uniquely identify the device. 192 If the customer who owns the device uses a public CA to issue the 193 LDevID, and if the device "serial" number and/or "model" is 194 considered sensitive or Personally Identifiable Information (PII), 195 then the "serial" and "model" fields MAY be replaced with suitable 196 alternate identifiers. However, the public CA MUST ensure that the 197 format and structure of the DIDN-ID adheres to this specification. 199 4. Certificate Fields 201 4.1. Subject 203 Following the recommendations set out in [RFC6125], the Subject field 204 of the certificate MAY contain the "commonName" field, set to the 205 DIDN-ID for the device. 207 The Subject field MAY also contain a "serialNumber" or 208 "hardwareModuleName" field. 210 4.2. Subject Alternate Name 212 The certificate MUST contain a "subjectAltName" extension 213 contataining a single "dnsName" entry with the DIDN-ID for the 214 device. 216 4.3. Extended Key Usage 218 The certificate MUST contain an "extKeyUsage" extension with the 219 values "id-kp-serverAuth" and "id-kp-clientAuth", and no other 220 values. 222 4.4. Certificate Lifetime 224 IDevID certificates with "_mDevice" identifiers in their DIDN-ID MUST 225 have a "notAfter" value of 99991231235959Z (i.e. Y10K). 227 It should be noted that at the time of writing, web browsers do not 228 check for Y10K and will happily establish connections with endpoints 229 whose identity certificate has a "notAfter" value of Y10K. 231 LDevID certificates are issued during live deployment and MUST follow 232 the standard lifetime and expiration requirements of the issuing CA. 234 5. IANA Considerations 236 [[ TODO: Register the "_device" and "_mDevice" labels ]] 238 6. Security Considerations 240 [[ TODO ]] 242 7. Informative References 244 [I-D.ietf-acme-acme] 245 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 246 Certificate Management Environment (ACME)", draft-ietf- 247 acme-acme-07 (work in progress), June 2017. 249 [IEEE802.1AR] 250 IEEE, ., "Secure Device Identity", 2017. 252 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 253 Protect Firmware Packages", RFC 4108, 254 DOI 10.17487/RFC4108, August 2005, 255 . 257 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 258 Verification of Domain-Based Application Service Identity 259 within Internet Public Key Infrastructure Using X.509 260 (PKIX) Certificates in the Context of Transport Layer 261 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 262 2011, . 264 Authors' Addresses 266 Owen Friel 267 Cisco 269 Email: ofriel@cisco.com 271 Richard Barnes 272 Cisco 274 Email: rlb@ipv.sx