idnits 2.17.1 draft-mccallum-jose-pkcs11-jwk-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2017) is 2485 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. McCallum 3 Internet-Draft Red Hat, Inc. 4 Updates: 7517 (if approved) June 30, 2017 5 Intended status: Standards Track 6 Expires: January 1, 2018 8 PKCS #11 for JSON Web Keys 9 draft-mccallum-jose-pkcs11-jwk-00 11 Abstract 13 This document updates RFC 7517 in order to specify an extension to 14 the JSON Web Key (JWK) format so that private key material may be 15 stored in cryptographic hardware using PKCS #11. It defines a new 16 property for JWKs which contains the PKCS #11 URI identifying the 17 location of the private key material. Implementations can use this 18 URI to offload the cryptographic operations to the identified 19 hardware. 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 http://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 January 1, 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 (http://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. Document Conventions . . . . . . . . . . . . . . . . . . . . 2 57 3. JWK PKCS #11 URI Property . . . . . . . . . . . . . . . . . . 2 58 4. Implementation Considerations . . . . . . . . . . . . . . . . 3 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 JSON Web Key (JWK) [RFC7517] defines a format for keys which can be 67 used to perform cryptographic operations. When these JWKs contain 68 private key material, illegitimate access to this material creates 69 the possibility for wide-scale security compromise. 71 As a defensive strategy, other key types will offload their private 72 key material to cryptographic hardware or other secure storage using 73 PKCS #11. The locations of these keys are communicated using PKCS 74 #11 URIs [RFC7512]. Therefore, this document defines a method to 75 replace the private key material of a JWK with a PKCS #11 URI. 77 2. Document Conventions 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [RFC2119]. 83 3. JWK PKCS #11 URI Property 85 JWKs that wish to offload their private key material using PKCS #11 86 will provide a JSON property named "p11" instead of the private key 87 material. The "p11" property MUST contain a valid PKCS #11 URI 88 [RFC7517] that points to a private key object (that is, 89 type=private). 91 Private key material is defined by the Parameter Information Class of 92 Section 8.1.1 of RFC 7517 [RFC7517]. JWKs MUST NOT provide both the 93 "p11" property and other private key material. However, 94 implementations SHOULD provide full public key material appropriate 95 to the key type. This enables implementations to perform public key 96 cryptographic operations without consulting PKCS #11. 98 4. Implementation Considerations 100 The PKCS #11 URI standard provides mappings to URI format for most 101 metadata attributes available over PKCS #11. Some of these 102 attributes may differ based on operating system, driver or even 103 hardware implementations. The generation of URIs which can only be 104 used in a specific context should be avoided for the sake of clarity. 106 The following path attributes are RECOMMENDED for general use: 108 o model 109 o manufacturer 110 o serial 111 o token 112 o id 113 o object 114 o type 116 The following query attributes are RECOMMENDED for general use: 118 o pin-value 120 Tools which generate PKCS #11 URIs for use in JWKs SHOULD NOT 121 generate path or query attributes that are not recommended above. On 122 the other hand, tools which process JWKs containing the "p11" 123 property MAY process path or query attributes that are not 124 recommended above. 126 Using PKCS #11 for cryptographic operations is usually associated 127 with a performance penalty. Implementations SHOULD perform public 128 key operations, such as asymmetric signature verification or 129 asymmetric encryption, without using PKCS #11 in order to increase 130 speed and should fall back to PKCS #11 where access to the private 131 key material is required. 133 5. Security Considerations 135 Accessing a JWK containing the "p11" property in place of the private 136 key material may still allow an attacker to perform operations using 137 the private key while not obtaining the private key itself. This is 138 particularly true when the "pin-value" query attribute is used. 140 Nevertheless, because the attacker does not learn the private key 141 itself, the attacker's access to use of the key can be limited to a 142 particular context; for example, only the host with direct access to 143 the hardware. Because of this, the ability to remove the attacker's 144 access to this context provides the option for significant damage 145 mitigation strategies. Therefore, offloading the private key 146 material should not be misunderstood to be a cryptographic panacea 147 but rather a way to reduce the cost of a compromise. 149 Exposing the "p11" property can leak institutional or configuration 150 information to an attacker that could be used as part of a 151 multifaceted attack. This is particularly true when the PKCS #11 URI 152 contains the "pin-value" or "pin-source" query attributes since this 153 PIN is used to protect access to the private key material. For this 154 reason, the "p11" property MUST be treated as a private key material 155 in its own right and care should be taken not to expose it. 157 It may be desirable to avoid the use of the "pin-value" query 158 attribute altogether by passing in this value out of band. This 159 strategy implies that the attacker will need to target the out of 160 band delivery mechanism in addition to the JWK in order to use the 161 private key material. 163 6. IANA Considerations 165 The following has been added to the "JSON Web Key Parameters" 166 registry: 168 o Parameter Name: "p11" 169 o Parameter Description: The PKCS #11 URI 170 o Parameter Information Class: Private 171 o Used with "kty" Value(s): * 172 o Change Controller: IESG 173 o Specification Document(s): Section 3 of THIS DOCUMENT 175 7. Normative References 177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", BCP 14, RFC 2119, 179 DOI 10.17487/RFC2119, March 1997, 180 . 182 [RFC7512] Pechanec, J. and D. Moffat, "The PKCS #11 URI Scheme", 183 RFC 7512, DOI 10.17487/RFC7512, April 2015, 184 . 186 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 187 DOI 10.17487/RFC7517, May 2015, 188 . 190 Author's Address 192 Nathaniel McCallum 193 Red Hat, Inc. 194 100 East Davie Street 195 Raleigh, NC 27601 196 USA 198 EMail: npmccallum@redhat.com