draft-ietf-jose-json-web-key-35.txt   draft-ietf-jose-json-web-key-36.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track October 17, 2014 Intended status: Standards Track October 24, 2014
Expires: April 20, 2015 Expires: April 27, 2015
JSON Web Key (JWK) JSON Web Key (JWK)
draft-ietf-jose-json-web-key-35 draft-ietf-jose-json-web-key-36
Abstract Abstract
A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data
structure that represents a cryptographic key. This specification structure that represents a cryptographic key. This specification
also defines a JSON Web Key Set (JWK Set) JSON data structure that also defines a JSON Web Key Set (JWK Set) JSON data structure that
represents a set of JWKs. Cryptographic algorithms and identifiers represents a set of JWKs. Cryptographic algorithms and identifiers
for use with this specification are described in the separate JSON for use with this specification are described in the separate JSON
Web Algorithms (JWA) specification and IANA registries defined by Web Algorithms (JWA) specification and IANA registries defined by
that specification. that specification.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 20, 2015. This Internet-Draft will expire on April 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 42 skipping to change at page 5, line 42
"kid":"Public key used in JWS A.3 example" "kid":"Public key used in JWS A.3 example"
} }
Additional example JWK values can be found in Appendix A. Additional example JWK values can be found in Appendix A.
4. JSON Web Key (JWK) Format 4. JSON Web Key (JWK) Format
A JSON Web Key (JWK) is a JSON object that represents a cryptographic A JSON Web Key (JWK) is a JSON object that represents a cryptographic
key. The members of the object represent properties of the key, key. The members of the object represent properties of the key,
including its value. This JSON object MAY contain white space and/or including its value. This JSON object MAY contain white space and/or
line breaks. This document defines the key parameters that are not line breaks before or after any JSON values or structural characters,
algorithm specific, and thus common to many keys. in accordance with Section 2 of RFC 7159 [RFC7159]. This document
defines the key parameters that are not algorithm specific, and thus
common to many keys.
In addition to the common parameters, each JWK will have members that In addition to the common parameters, each JWK will have members that
are key type-specific. These members represent the parameters of the are key type-specific. These members represent the parameters of the
key. Section 6 of the JSON Web Algorithms (JWA) [JWA] specification key. Section 6 of the JSON Web Algorithms (JWA) [JWA] specification
defines multiple kinds of cryptographic keys and their associated defines multiple kinds of cryptographic keys and their associated
members. members.
The member names within a JWK MUST be unique; JWK parsers MUST either The member names within a JWK MUST be unique; JWK parsers MUST either
reject JWKs with duplicate member names or use a JSON parser that reject JWKs with duplicate member names or use a JSON parser that
returns only the lexically last duplicate member name, as specified returns only the lexically last duplicate member name, as specified
skipping to change at page 8, line 10 skipping to change at page 8, line 10
because of the potential vulnerabilities associated with using the because of the potential vulnerabilities associated with using the
same key with multiple algorithms. Thus, the combinations "sign" same key with multiple algorithms. Thus, the combinations "sign"
with "verify", "encrypt" with "decrypt", and "wrapKey" with with "verify", "encrypt" with "decrypt", and "wrapKey" with
"unwrapKey" are permitted, but other combinations SHOULD NOT be used. "unwrapKey" are permitted, but other combinations SHOULD NOT be used.
Additional Key Operations values can be registered in the IANA JSON Additional Key Operations values can be registered in the IANA JSON
Web Key Operations registry defined in Section 8.3. The same Web Key Operations registry defined in Section 8.3. The same
considerations about registering extension values apply to the considerations about registering extension values apply to the
"key_ops" member as do for the "use" member. "key_ops" member as do for the "use" member.
The "use" and "key_ops" JWK members SHOULD NOT be used together. The "use" and "key_ops" JWK members SHOULD NOT be used together;
Applications should specify which of these members they use, if however, if both are used, the information they convey MUST be
either is to be used by the application. consistent. Applications should specify which of these members they
use, if either is to be used by the application.
4.4. "alg" (Algorithm) Parameter 4.4. "alg" (Algorithm) Parameter
The "alg" (algorithm) member identifies the algorithm intended for The "alg" (algorithm) member identifies the algorithm intended for
use with the key. The values used should either be registered in the use with the key. The values used should either be registered in the
IANA JSON Web Signature and Encryption Algorithms registry defined in IANA JSON Web Signature and Encryption Algorithms registry defined in
[JWA] or be a value that contains a Collision-Resistant Name. Use of [JWA] or be a value that contains a Collision-Resistant Name. Use of
this member is OPTIONAL. this member is OPTIONAL.
4.5. "kid" (Key ID) Parameter 4.5. "kid" (Key ID) Parameter
skipping to change at page 11, line 45 skipping to change at page 11, line 45
omitted. omitted.
See Appendix C for an example encrypted JWK. See Appendix C for an example encrypted JWK.
8. IANA Considerations 8. IANA Considerations
The following registration procedure is used for all the registries The following registration procedure is used for all the registries
established by this specification. established by this specification.
Values are registered on a Specification Required [RFC5226] basis Values are registered on a Specification Required [RFC5226] basis
after a three-week review period on the [TBD]@ietf.org mailing list, after a three-week review period on the jose-reg-review@ietf.org
on the advice of one or more Designated Experts. However, to allow mailing list, on the advice of one or more Designated Experts.
for the allocation of values prior to publication, the Designated However, to allow for the allocation of values prior to publication,
Expert(s) may approve registration once they are satisfied that such the Designated Expert(s) may approve registration once they are
a specification will be published. satisfied that such a specification will be published.
Registration requests must be sent to the [TBD]@ietf.org mailing list Registration requests must be sent to the jose-reg-review@ietf.org
for review and comment, with an appropriate subject (e.g., "Request mailing list for review and comment, with an appropriate subject
for access token type: example"). [[ Note to the RFC Editor: The name (e.g., "Request for access token type: example").
of the mailing list should be determined in consultation with the
IESG and IANA. Suggested name: jose-reg-review. ]]
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. Registration requests that are undetermined for a period successful. Registration requests that are undetermined for a period
longer than 21 days can be brought to the IESG's attention (using the longer than 21 days can be brought to the IESG's attention (using the
iesg@ietf.org mailing list) for resolution. iesg@ietf.org mailing list) for resolution.
Criteria that should be applied by the Designated Expert(s) includes Criteria that should be applied by the Designated Expert(s) includes
skipping to change at page 38, line 30 skipping to change at page 38, line 30
Hannes Tschofenig, and Sean Turner. Hannes Tschofenig, and Sean Turner.
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner, Stephen Farrell, and Kathleen Moriarty served as Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
Security area directors during the creation of this specification. Security area directors during the creation of this specification.
Appendix E. Document History Appendix E. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
-36
o Stated that if both "use" and "key_ops" are used, the information
they convey MUST be consistent.
o Clarified where white space and line breaks may occur in JSON
objects by referencing Section 2 of RFC 7159.
o Specified that registration reviews occur on the
jose-reg-review@ietf.org mailing list.
-35 -35
o Used real values for examples in the IANA Registration Templates. o Used real values for examples in the IANA Registration Templates.
-34 -34
o Addressed IESG review comments by Pete Resnick, Stephen Farrell, o Addressed IESG review comments by Pete Resnick, Stephen Farrell,
and Richard Barnes. and Richard Barnes.
o Referenced RFC 4945 for PEM certificate delimiter syntax. o Referenced RFC 4945 for PEM certificate delimiter syntax.
 End of changes. 8 change blocks. 
19 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/