draft-ietf-jose-json-web-key-36.txt   draft-ietf-jose-json-web-key-37.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track October 24, 2014 Intended status: Standards Track November 19, 2014
Expires: April 27, 2015 Expires: May 23, 2015
JSON Web Key (JWK) JSON Web Key (JWK)
draft-ietf-jose-json-web-key-36 draft-ietf-jose-json-web-key-37
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 27, 2015. This Internet-Draft will expire on May 23, 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 8, line 20 skipping to change at page 8, line 20
The "use" and "key_ops" JWK members SHOULD NOT be used together; The "use" and "key_ops" JWK members SHOULD NOT be used together;
however, if both are used, the information they convey MUST be however, if both are used, the information they convey MUST be
consistent. Applications should specify which of these members they consistent. Applications should specify which of these members they
use, if either is to be used by the application. 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. The
this member is OPTIONAL. "alg" value is a case-sensitive ASCII string. Use of this member is
OPTIONAL.
4.5. "kid" (Key ID) Parameter 4.5. "kid" (Key ID) Parameter
The "kid" (key ID) member is used to match a specific key. This is The "kid" (key ID) member is used to match a specific key. This is
used, for instance, to choose among a set of keys within a JWK Set used, for instance, to choose among a set of keys within a JWK Set
during key rollover. The structure of the "kid" value is during key rollover. The structure of the "kid" value is
unspecified. When "kid" values are used within a JWK Set, different unspecified. When "kid" values are used within a JWK Set, different
keys within the JWK Set SHOULD use distinct "kid" values. (One keys within the JWK Set SHOULD use distinct "kid" values. (One
example in which different keys might use the same "kid" value is if example in which different keys might use the same "kid" value is if
they have different "kty" (key type) values but are considered to be they have different "kty" (key type) values but are considered to be
skipping to change at page 12, line 8 skipping to change at page 12, line 8
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 jose-reg-review@ietf.org after a three-week review period on the jose-reg-review@ietf.org
mailing list, on the advice of one or more Designated Experts. mailing list, on the advice of one or more Designated Experts.
However, to allow for the allocation of values prior to publication, However, to allow for the allocation of values prior to publication,
the Designated Expert(s) may approve registration once they are the Designated Expert(s) may approve registration once they are
satisfied that such a specification will be published. satisfied that such a specification will be published.
Registration requests must be sent to the jose-reg-review@ietf.org Registration requests must be sent to the jose-reg-review@ietf.org
mailing list for review and comment, with an appropriate subject mailing list for review and comment, with an appropriate subject
(e.g., "Request for access token type: example"). (e.g., "Request to register JWK parameter: example").
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 20, line 44 skipping to change at page 20, line 44
Any data associated with a key that is obtained in an untrusted Any data associated with a key that is obtained in an untrusted
manner should be treated with skepticism. See Section 10.3 of [JWS] manner should be treated with skepticism. See Section 10.3 of [JWS]
for security considerations on key origin authentication. for security considerations on key origin authentication.
The security considerations in Section 12.3 of XML DSIG 2.0 The security considerations in Section 12.3 of XML DSIG 2.0
[W3C.NOTE-xmldsig-core2-20130411] about the strength of a digital [W3C.NOTE-xmldsig-core2-20130411] about the strength of a digital
signature depending upon all the links in the security chain also signature depending upon all the links in the security chain also
apply to this specification. apply to this specification.
The TLS Requirements in Section 8 of [JWS] also apply to this The TLS Requirements in Section 8 of [JWS] also apply to this
specification. specification, except that the "x5u" JWK member is the only feature
defined by this specification using TLS.
9.2. Preventing Disclosure of Non-Public Key Information 9.2. Preventing Disclosure of Non-Public Key Information
Private and symmetric keys MUST be protected from disclosure to Private and symmetric keys MUST be protected from disclosure to
unintended parties. One recommended means of doing so is to encrypt unintended parties. One recommended means of doing so is to encrypt
JWKs or JWK Sets containing them by using the JWK or JWK Set value as JWKs or JWK Sets containing them by using the JWK or JWK Set value as
the plaintext of a JWE. Of course, this requires that there be a the plaintext of a JWE. Of course, this requires that there be a
secure way to obtain the key used to encrypt the non-public key secure way to obtain the key used to encrypt the non-public key
information to the intended party and a secure way for that party to information to the intended party and a secure way for that party to
obtain the corresponding decryption key. obtain the corresponding decryption key.
skipping to change at page 22, line 7 skipping to change at page 22, line 7
[ITU.X690.1994] [ITU.X690.1994]
International Telecommunications Union, "Information International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 1994. X.690, 1994.
[JWA] Jones, M., "JSON Web Algorithms (JWA)", [JWA] Jones, M., "JSON Web Algorithms (JWA)",
draft-ietf-jose-json-web-algorithms (work in progress), draft-ietf-jose-json-web-algorithms (work in progress),
October 2014. November 2014.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
draft-ietf-jose-json-web-encryption (work in progress), draft-ietf-jose-json-web-encryption (work in progress),
October 2014. November 2014.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature (work Signature (JWS)", draft-ietf-jose-json-web-signature (work
in progress), October 2014. in progress), November 2014.
[RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20, [RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20,
October 1969. October 1969.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
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 ]]
-37
o Updated the TLS requirements language to only require
implementations to support TLS when they support features using
TLS.
o Restricted algorithm names to using only ASCII characters.
o Updated the example IANA registration request subject line.
-36 -36
o Stated that if both "use" and "key_ops" are used, the information o Stated that if both "use" and "key_ops" are used, the information
they convey MUST be consistent. they convey MUST be consistent.
o Clarified where white space and line breaks may occur in JSON o Clarified where white space and line breaks may occur in JSON
objects by referencing Section 2 of RFC 7159. objects by referencing Section 2 of RFC 7159.
o Specified that registration reviews occur on the o Specified that registration reviews occur on the
jose-reg-review@ietf.org mailing list. jose-reg-review@ietf.org mailing list.
 End of changes. 10 change blocks. 
11 lines changed or deleted 23 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/