I have updated the draft from the comments everyone has provided.
However, document uploads are currently locked due to the IETF
meeting, so I have attached the document here. Your feedback is
greatly appreciated.
On Fri, Jun 30, 2017 at 5:33 PM, Nathaniel McCallum
<[email protected]> wrote:
> I have prepared an initial stab at a draft for offloading JWK private
> key data to PKCS #11.
>
> You can find the document here:
> https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt
>
> Thanks for your consideration!
Internet Engineering Task Force N. McCallum
Internet-Draft Red Hat, Inc.
Updates: 7517 (if approved) July 5, 2017
Intended status: Standards Track
Expires: January 6, 2018
PKCS #11 for JSON Web Keys
draft-mccallum-jose-pkcs11-jwk-01
Abstract
This document updates RFC 7517 in order to specify an extension to
the JSON Web Key (JWK) format so that private key material may be
stored in cryptographic hardware using PKCS #11. It defines a new
property for JWKs which contains the PKCS #11 URI identifying the
location of the private key material. Implementations can use this
URI to offload the cryptographic operations to the identified
hardware.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
McCallum Expires January 6, 2018 [Page 1]
Internet-Draft PKCS #11 for JWK July 2017
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Conventions . . . . . . . . . . . . . . . . . . . . 2
3. JWK PKCS #11 URI Property . . . . . . . . . . . . . . . . . . 2
4. URI Attributes . . . . . . . . . . . . . . . . . . . . . . . 3
5. Implementation Considerations . . . . . . . . . . . . . . . . 3
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Examples of PKCS #11 JWKs . . . . . . . . . . . . . 6
A.1. Symmetric PKCS #11 JWK . . . . . . . . . . . . . . . . . 6
A.2. Elliptic Curve PKCS #11 JWK . . . . . . . . . . . . . . . 6
A.3. RSA PKCS #11 JWK (truncated) . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
JSON Web Key (JWK) [RFC7517] defines a format for keys which can be
used to perform cryptographic operations. When these JWKs contain
private key material, illegitimate access to this material creates
the possibility for wide-scale security compromise.
As a defensive strategy, other key types will offload their private
key material to cryptographic hardware or other secure storage using
PKCS #11. The locations of these keys are communicated using PKCS
#11 URIs [RFC7512]. Therefore, this document defines a method to
replace the private key material of a JWK with a PKCS #11 URI.
2. Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. JWK PKCS #11 URI Property
Users that wish to offload their private key material to
cryptographic hardware using PKCS #11 will provide a JSON property
named "p11" instead of the private key material. The "p11" property
MUST contain a valid PKCS #11 URI [RFC7517] that points to a private
key object (that is, type=private).
McCallum Expires January 6, 2018 [Page 2]
Internet-Draft PKCS #11 for JWK July 2017
Private key material for both symmetric and asymmetric keys is
defined by the Parameter Information Class of Section 8.1.1 of RFC
7517 [RFC7517]. JWKs MUST NOT provide both the "p11" property and
other private key material. However, implementations SHOULD provide
full public key material appropriate to the key type. This enables
implementations to perform public key cryptographic operations
without consulting PKCS #11.
4. URI Attributes
The PKCS #11 URI standard provides mappings to URI format for most
metadata attributes available over PKCS #11. Some of these
attributes may differ based on operating system, driver or
implementation version. In order to avoid URI fragility, the
generation of URIs SHOULD avoid parameters that may change
unnecessarily.
The following path attributes are REQUIRED for use in "p11":
o id
o type=private
The following path attributes are RECOMMENDED for use in "p11":
o model
o manufacturer
o serial
o token
o object
The following query attributes are RECOMMENDED for use in "p11":
o pin-value
o pin-source
o module-name
Tools which generate PKCS #11 URIs for use in JWKs SHOULD NOT
generate path or query attributes that are not recommended or
required above and MAY emit URIs which omit the recommended
attributes. On the other hand, tools which process JWKs containing
the "p11" property MAY process path or query attributes that are not
recommended or required above.
5. Implementation Considerations
Using PKCS #11 for cryptographic operations is often associated with
a performance penalty. Implementations MAY perform public key
McCallum Expires January 6, 2018 [Page 3]
Internet-Draft PKCS #11 for JWK July 2017
operations, such as asymmetric signature verification or asymmetric
encryption, without using PKCS #11 in order to increase speed.
Implementations that wish to use PKCS #11 even for public key
operations will need to transform the PKCS #11 private key URI into a
public key URI. This can be performed by retaining the "id" URI path
attribute, which correlates between related key types, and changing
"type=private" to "type=public". Implementations which create key
pairs via PKCS #11 for use in JWKs SHOULD take care to ensure that
related key types are differentiated only by the "type" URI path
attribute.
Symmetric JWKs, such as kty="oct", contain no public key material and
have no public key operations. Thus, all operations will need to be
performed using PKCS #11.
6. Security Considerations
Accessing a JWK containing the "p11" property in place of the private
key material may still allow an attacker to perform operations using
the private key while not obtaining the private key itself. This is
particularly true when the "pin-value" or "pin-source" query
attributes are used.
Nevertheless, because the attacker does not learn the private key
itself, the attacker's access to use of the key can be limited to a
particular context; for example, only the host with direct access to
the hardware. Because of this, the ability to remove the attacker's
access to this context provides the option for significant damage
mitigation strategies. Therefore, offloading the private key
material should not be misunderstood to be a panacea against
compromises but rather a way to reduce the cost of a compromise.
Exposing the "p11" property can leak institutional or configuration
information to an attacker that could be used as part of a
multifaceted attack. This is particularly true when the PKCS #11 URI
contains the "pin-value" or "pin-source" query attributes since this
PIN is used to protect access to the private key material. For this
reason, the "p11" property MUST be treated as a private key material
in its own right and care should be taken not to expose it.
It may be desirable to avoid the use of the "pin-value" and/or "pin-
source" query attributes altogether by passing in this value out of
band. This strategy implies that the attacker will need to target
the out of band delivery mechanism in addition to the JWK in order to
use the private key material.
McCallum Expires January 6, 2018 [Page 4]
Internet-Draft PKCS #11 for JWK July 2017
JWKs provide various methods for restricting usage (such as the "use"
and "key_ops" properties). Likewise, PKCS #11 contains similar usage
restrictions (such as CKA_SIGN, CKA_VERIFY, etc). Similarly, both
provide metadata to communicate supported algorithms (JWK: "alg"
property, PKCS #11: via the C_GetMechanismList() function).
Utilities which generate JWKs from PKCS #11 data SHOULD populate the
respective JWK properties from the PKCS #11 data in order to avoid
confusion. Implementations which use these keys MUST respect the
constraints present in either the JWK or its corresponding PKCS #11
object. This prevents confusion and possible compromise when the JWK
contains different restrictions than its PKCS #11 private key object.
7. IANA Considerations
The following has been added to the "JSON Web Key Parameters"
registry:
o Parameter Name: "p11"
o Parameter Description: The PKCS #11 URI
o Parameter Information Class: Private
o Used with "kty" Value(s): *
o Change Controller: IESG
o Specification Document(s): Section 3 of THIS DOCUMENT
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC7512] Pechanec, J. and D. Moffat, "The PKCS #11 URI Scheme",
RFC 7512, DOI 10.17487/RFC7512, April 2015,
<http://www.rfc-editor.org/info/rfc7512>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<http://www.rfc-editor.org/info/rfc7517>.
McCallum Expires January 6, 2018 [Page 5]
Internet-Draft PKCS #11 for JWK July 2017
Appendix A. Examples of PKCS #11 JWKs
A.1. Symmetric PKCS #11 JWK
{
"kty": "oct",
"use": "enc",
"p11": "pkcs11:id=%e8%a3%0c%0b%e3%9a;type=private?pin-value=123456"
}
A.2. Elliptic Curve PKCS #11 JWK
{
"kty": "EC",
"crv": "P-256",
"use": "sig",
"x": "QQSx1ZMKkbk5CgIfs3VQtdVi0Q6c4o5RC6esSW-cubVt",
"y": "bZdAG1myCd62E8IydPTpqEylz0RR4A0ZlQULQrgxkUJy",
"p11": "pkcs11:id=%b9%10%6d%f7%a9%17;type=private?pin-value=123456"
}
A.3. RSA PKCS #11 JWK (truncated)
{
"kty": "RSA",
"alg": "RS256",
"e": "AQAB",
"n": "3D5CTT4D3x_s7Ly8nSjMTjJntpVU431sLR8Xpdn5BTM...",
"p11": "pkcs11:id=%f1%9b%56%96%87%af;type=private?pin-value=123456"
}
Author's Address
Nathaniel McCallum
Red Hat, Inc.
100 East Davie Street
Raleigh, NC 27601
USA
EMail: [email protected]
McCallum Expires January 6, 2018 [Page 6]
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
