idnits 2.17.1 draft-manger-jose-jwsec-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 11, 2012) is 4331 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) == Missing Reference: '96-bit IV' is mentioned on line 184, but not defined == Missing Reference: 'TODO' is mentioned on line 588, but not defined ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Manger 3 Internet-Draft Telstra 4 Intended status: Standards Track June 11, 2012 5 Expires: December 13, 2012 7 JSON Web Security Message Format 8 draft-manger-jose-jwsec-00.txt 10 Abstract 12 This document describes a cryptographic message format based on 13 JavaScript Object Notation (JSON) and base-64 encodings to be easy 14 for web applications to generate and process. Signed, encrypted, 15 signed-then-encrypted, and unprotected messages are supported using 16 symmetric and/or asymmetric keys. 18 Please discuss this document on the jose@ietf.org mailing list. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 13, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Conventions Used In This Document . . . . . . . . . . . . 4 68 1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Unprotected message (mode U) . . . . . . . . . . . . . . . . . 7 72 5. Signed message (mode S) . . . . . . . . . . . . . . . . . . . 8 73 6. Encrypted message (mode E) . . . . . . . . . . . . . . . . . . 8 74 6.1. Key transport . . . . . . . . . . . . . . . . . . . . . . 10 75 6.2. Key agreement . . . . . . . . . . . . . . . . . . . . . . 10 76 6.3. Symmetric key wrapping . . . . . . . . . . . . . . . . . . 10 77 7. Header elements . . . . . . . . . . . . . . . . . . . . . . . 10 78 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. JWsec Header Element Registry . . . . . . . . . . . . . . 11 80 8.2. Media type . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9. Security considerations . . . . . . . . . . . . . . . . . . . 12 82 10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 83 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 [[ This document presents the author's ideas for improving the 89 JWS/JWE/JWT drafts -- formulated as a complete spec. This 90 document copies lots of text from draft-rescorla-jsms-00, 91 draft-ietf-jose-json-web-signature-01, 92 draft-ietf-jose-json-web-encryption, and (parts of) 93 draft-ietf-oauth-json-web-token-00. ]] 95 Many applications require the ability to send cryptographically 96 secured messages (encrypted, digitally signed, etc.). While the IETF 97 has defined a number of formats for such messages -- such as 98 Cryptographic Message Syntax (CMS) [RFC5652] -- those formats are 99 widely viewed as being excessively complicated for the demands of 100 many web applications, which typically only need the ability to 101 secure simple messages. In addition, existing formats use encoding 102 mechanisms that are not congenial for web applications, such as 103 Abstract Syntax Notation (ASN.1) Distinguished Encoding Rules (DER). 104 This presents an obstacle to the deployment of strong security by 105 such applications. 107 This document describes a new cryptographic message format, nicknamed 108 JWsec, intended to meet the needs of the web environment. JWsec uses 109 JavaScript Object Notation (JSON) [RFC4627] and base64url encodings 110 (without padding) [RFC4648] section 5. JWsec is loosly modelled on 111 some of the basic functionality of CMS, but omits many CMS modes in 112 the interests of simplicity. 114 A JWsec message can protect any array of bytes, though it is more 115 suited to protecting kilobytes than gigabytes. A JWsec message can 116 provide data origin authenticity and/or confidentiality for the data. 117 It can compress the data. A JWsec message can also carry the data 118 with no cryptographic protection, which enables protocols to specify 119 JWsec for fields that do not require security in all circumstances. 121 After providing some example JWsec messages, this document describes 122 the processing model, the message syntax, and then three modes of 123 protection: unprotected; signed; and encrypted. The JSON elements 124 that can appear in a JWsec message header are summarized in section 125 7. 127 An initial set of algorithms that a JWsec message can use for 128 signing, encrypting, and compressing are specified separately in JSON 129 Web Security Message Algorithms [ALGS]. That document also 130 establishes a registry for listing further algorithms. 132 1.1. Conventions Used In This Document 134 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 [RFC2119]. 138 Requirements are specified for originators who create JWsec messages 139 and recipients who receive them. Requirements stated for messages 140 apply to originators who create them. 142 Long base64url encodings are wrapped over multiple lines only for 143 display purposes. The real values do not include line breaks. 145 1.2. Examples 147 This simple JWsec message consists of 3 dot-separated components: 149 U.e30.SGVsbG8sIFdvcmxkIQ 151 The initial letter "U" indicated that this is an unprotected JWsec 152 message. The other components are base64url encodings (without 153 padding). The second component decodes to a JSON object (the 154 header), in this case an empty JSON object {} indicating that no 155 processing (eg no compression) of the data has occured. The last 156 component decodes to the actual data: 13 bytes, which is the UTF-8- 157 encoded 13-character string "Hello, World!". 159 The next example is a signed JWsec message since it starts with "S". 161 S.eyAic2lnIjoiSFMyNTYiLCAia2lkIjoiRmViMTJrMSIgfQ. 162 SGVsbG8sIFdvcmxkIQ. 163 MDEyMzQ-FIX-OWFiY2RlZj_xMjM0NTY-ODlhYmNkZWY 165 The header (the JSON object decoded from the second dot-separated 166 component) is: 167 { "sig":"HS256", "kid":"Feb12k1" } 169 The next component decodes to the data "Hello, World!". The final 170 component decodes to a 256-bit MAC (message authentication code) 171 calculated over the preceeding portion of the JWsec message. In this 172 instance the MAC uses the HS256 algorithm (HMAC with SHA-256) with 173 the secret key identified by the label "Feb12k1", and covers the 71 174 initial characters of the message (UTF-8 encoded into 71 bytes). 176 MDEyMzQ-FI...ZWY = B64(HMAC(S.eyAi...IgfQ.SGVsbG8sIFdvcmxkIQ)) 178 The following example is a signed-then-encrypted JWsec message. 180 e.ew0KICJhbGc-FIX-U0ExXzUiLA0KICJraWQiOiJodHRwOi8vZX 181 hhbXBsZS5vcm-FIX-ibGljLmp3ayNrMiIsDQogImVuYyI6IkEyN 182 TZHQ00iLA0KI-FIX-AiOiJERUYiLA0KICJlbnYiOnRydWUNCn0. 183 [2048-bit RSA BT2 value]. 184 [96-bit IV][ciphertext][128-bit tag] 186 The decoded header is: 188 { 189 "kmg":"RSA1_5", 190 "kid":"http://example.org/public.jwk#k2", 191 "enc":"A256GCM", 192 "zip":"DEF", 193 } 195 The third component is a random 256-bit AES key encrypted with a 196 2048-bit RSA public key, as per the RSA1_5 key transport algorithm. 197 The fourth component is the concatenation of a 96-bit IV, the 198 ciphertext, and a 128-bit authentication tag. The ciphertext and tag 199 are calculated using AES in Galois/Counter mode. 201 After verifying the tag, decrypting the ciphertext, and decompressing 202 with the DEFLATE algorithm, the result is S.eyJzaWciOiJSUzI1... This 203 data is processed as another (inner) JWsec messages. 205 The initial lowercase "e" on the outer JWsec messages indicates the 206 encryption wraps another JWsec message. The initial "S" on the inner 207 JWsec message indicates signed data. Together they show that this is 208 a signed-then-encrypted message. 210 Appendix A has a complete example. 212 2. Model 214 The starting point for creating a JWsec message is the input data, 215 which is a byte array. One or more modes of protection are applied 216 in turn, using algorithms and keys chosen by the message originator. 217 Three modes of protection are specified in this document: 218 unprotected; signed; and encrypted. The resultant JWsec message is a 219 string, using a limited alphabet of 65 characters. To apply multiple 220 modes of protection, the output JWsec message from one mode is UTF-8 221 encoded to give the input data for the next mode. 223 -->[unprotected]--- 224 input data | | JWsec message 225 -------------+->--+->[ signed ]--+->--+---------------> 226 [byte array] ^ | | | [string] 227 | -->[ encrypted ]--- | 228 | | 229 --------[UTF-8 encode]<------ 231 3. Syntax 233 A JWsec message is a string consisting of dot-separated components. 234 Each component only uses a limited set of 64 characters: A-Z, a-z, 235 0-9, "-" (hypen-minus), and "_" (low line). This set is sufficient 236 to hold a base64url encoding (without padding), as defined in RFC4648 237 section 5 "Base 64 Encoding with URL and Filename Safe Alphabet" 238 [RFC4648]. The limited range of characters used in a JWsec message 239 make it suitable to be carried in fields of many web protocols 240 without requiring escaping (eg in an HTTP header, URI query string, 241 HTML form POST, XML document, JSON string value etc). 243 A JWsec message MUST match the production, defined using 244 Augmented Backus-Naur Form (ABNF) [RFC5234]: 246 jwsec = ("U" "." header64 "." compressed64) / 247 ("S" "." header64 "." compressed64 "." signature64) / 248 ("E" "." header64 "." enckey64 "." ciphertext64) / 249 (ext "." header64 *("." component64)) 250 ; note: "X" matches "X" or "x" in ABNF 252 ext = %x41-5A / %x61-7A ; A-Z a-z 254 header64 = 1*b64url ; base64url-encoded UTF-8-encoded JSON object 256 ; base64url-encoded byte arrays 257 compressed64 = *b64url ; input data, optionally compressed 258 signature64 = *b64url ; digital signature or MAC 259 enckey64 = *b64url ; encrypted per-message key 260 ciphertext64 = *b64url ; IV, encrypted data, and authentication tag 261 component64 = *b64url 263 b64url = %x41-5A / %x61-7A / %x30-39 / %x2D / %x5F 264 ; A-Z a-z 0-9 - _ 266 The first dot-separated component in a JWsec message is a single 267 letter indicating the nature of the protection provided to the data. 268 It determines the semantics of the components after the header. 269 Three modes are defined in this specification: "U" or "u" for 270 unprotected data; "S" or "s" for signed data; and "E" or "e" for 271 encrypted data. A lowercase letter for the mode indicates that the 272 input data for the JWsec message is another a JWsec message (UTF-8 273 encoded). 275 Additional modes can be defined in RFCs that update this 276 specification. 278 Each JWsec message incorporates a header that is a JSON object with 279 0, 1, or more elements [RFC4627]. The header64 field is the 280 base64url encoding (without padding) of the UTF-8 encoding of the 281 header JSON object. Header elements identify the algorithms and keys 282 required to process the message. 284 Various header elements are defined in this document. Further header 285 elements holding algorithm-specific parameters are likely to be 286 defined as algorithms are specified for use with JWsec. Other header 287 elements could be defined to hold status information about keys or 288 certificates, for instance. A recipient MUST ignore any header 289 elements it does not recognize so new header elements can be deployed 290 while maintaining interoperability. 292 Subsequent sections for each mode define output components that are 293 bytes arrays. Those byte arrays are base64url encoded (without 294 padding) then joined to the mode and header (all separated by dots) 295 to form a JWsec message. A component's value can be a zero-length 296 byte array, in which case the corresponding part of the JWsec message 297 is an empty string but the dot-separators are still present. 299 4. Unprotected message (mode U) 301 An unprotected JWsec message offers no security for the input data it 302 carries. It can compress the data. An unprotected message can be 303 useful when security is provided by a lower layer. Using an 304 unprotected JWsec message as the input data for an encrypted JWsec 305 message provides a place (the unprotected JWsec message's header) to 306 include any header elements associated with the input data that are 307 confidential. 309 Output components (other than the mode and header) are: 311 compressed [byte array] 313 The compressed data is the input data after applying the compression 314 algorithm specified by the "zip" header element. If there is no 315 "zip" element the compressed data equals the input data. A recipient 316 MUST understand the "zip" header element. 318 There are no mandatory header elements so an empty JSON object {} is 319 a valid header. 321 5. Signed message (mode S) 323 A signed JWsec message provides data-origin authentication for the 324 input data. Signing can use the private key of a public/private key 325 pair to create a digital signature; or it can use a secret symmetric 326 key to create a message authentication code (MAC). The data can, 327 optionally, be compressed. 329 Output components (other than the mode and header) are: 331 compressed [byte array] 332 signature [byte array] 334 The compressed data is the input data after applying the compression 335 algorithm specified by the "zip" element in the header. If there is 336 no "zip" element the compressed data equals the input data. A 337 recipient MUST understand the "zip" header element. 339 The header MUST include a "sig" element identifying either an 340 asymmetric signature algorithm or a MAC algorithm [see [ALGS] 341 sections 4 and 5]. The signature or MAC covers the mode, header, and 342 compressed data. It is calculated over the (UTF-8 encoded) prefix of 343 the JWsec message upto (but excluding) the dot-separator before the 344 signature64 component. 346 signature = SIGN(("S" or "s") "." B64(header) "." B64(compressed)) 348 When using a MAC algorithm the header MUST include a "kid" element to 349 identify the secret key. 351 When using an asymmetric signature algorithm the public verification 352 key needs to be available to the recipient. The header MUST include 353 an "okid" element to identify the public key. The header SHOULD 354 include a "jku" or "x5u" element holding a URI for the raw or 355 certified public key respectively. 357 6. Encrypted message (mode E) 359 An encrypted JWsec message provides confidentiality for the input 360 data. The input data is, optionally, compressed. The message is 361 also integrity protected. This is achieved by using an authenticated 362 encryption algorithm that supports additional data (AEAD algorithm), 363 keyed with a randomly-chosen per-message secret key. Three 364 techniques are available to distribute the per-message key: 366 o Key transport: the per-message key is encrypted with the 367 recipient's public key 368 o Key agreement: a pairwise symmetric key is generated from the 369 originator's and recipient's public/private key pairs, and then 370 used to encrypt the per-message key 371 o Symmetric key wrapping: the per-message key is encrypted using a 372 shared symmetric secret key 374 An intermediate component to aid describing the process is: 376 plaintext [byte array] 378 Output components (other than the mode and header) are: 380 enckey [byte array] 381 ciphertext [byte array] 383 The plaintext is the input data after applying the compression 384 algorithm specified by the "zip" element in the header. If there is 385 no "zip" element the plaintext equals the input data. A recipient 386 MUST understand the "zip" header element. 388 The header MUST include an "enc" element identifying an AEAD 389 algorithm [see [ALGS] section 9]. A random per-message key is 390 chosen, using the key size required by the AEAD algorithm. See 391 [RFC4086] for considerations on generating random values. The data 392 to be encrypted by the AEAD algorithm is the plaintext. The 393 additional data to be authenticated by the AEAD algorithm is the 394 (UTF-8 encoded) prefix of the JWsec message up to (but excluding) the 395 dot-separator before the ciphertext64 component. 397 If the AEAD algorithm involves an initialization vector (IV) it is 398 prepended to the ciphertext. The authentication tag generated by the 399 AEAD algorithm is appended to the ciphertext. The lengths of the IV 400 and authentication tag are defined by the AEAD algorithm. 402 additionalData = ("E" or "e") "." B64(header) "." B64(enckey) 404 ciphertext = [iv] ENCRYPT(plaintext) authtag 406 The header MUST include a "kmg" element identifying a key transport, 407 key agreement, or symmetric key wrapping algorithm [see [ALGS] 408 sections 6, 7, and 8]. The encrypted per-message key is held in the 409 enckey component. 411 6.1. Key transport 413 When the "kmg" header element identifies a key transport algorithm, 414 that algorithm is used to encrypted the per-message key with the 415 recipient's public key. 417 The header MUST include a "kid" element to identify the recipient's 418 asymmetric key pair. 420 6.2. Key agreement 422 When the "kmg" header element identifies a key agreement algorithm, 423 the originator and recipient each use their own private key and the 424 other party's public key to generate a pairwise symmetric key. That 425 symmetric key is used to encrypted the per-message key using a 426 symmetric key wrapping algorithm. 428 Note: the specification of a key agreement algorithm has to specify 429 a symmetric key wrapping algorithm as well. 431 The header MUST include a "kid" element to identify the recipient's 432 asymmetric key pair. 434 The originator's public key also needs to be identified. The header 435 MUST include either an "epk" element or an "okid" element. The 436 former hold the originator's actual public key. The latter is an 437 identifier for the public key, and SHOULD be accompanied by either a 438 "jku" or "x5u" element, conveying a URI for the raw or certified 439 public key respectively. 441 6.3. Symmetric key wrapping 443 When the "kmg" header element identifies a symmetric key wrapping 444 algorithm, that algorithm is used to encrypted the per-message key 445 with a secret key shared by the originator and recipient. 447 The header MUST include a "kid" element to identify the shared secret 448 key. 450 7. Header elements 452 The following header elements are defined in this document: 454 +------+------------------------------------------------------------+ 455 | Name | Description | 456 +------+------------------------------------------------------------+ 457 | zip | String identifier for a compression algorithm. See [ALGS] | 458 | | section 3. | 459 | sig | String identifier for an asymmetric digital signature | 460 | | algorithm, or for a symmetric message authentication code | 461 | | (MAC) algorithm. See [ALGS] sections 4 and 5. | 462 | kmg | String identifier for a key transport algorithm, a key | 463 | | exchange algorithm, or a symmetric key wrapping algorithm. | 464 | | See [ALGS] sections 6, 7, or 8 respectively. | 465 | enc | String identifier for an authenticated encryption with | 466 | | additional data (AEAD) algorithm. See [ALGS] section 9. | 467 | kid | String identifier for the recipient's key that is needed | 468 | | to process the message. The identified key can be either: | 469 | | a symmetric secret key shared by the message originator | 470 | | and recipient; or an asymmetric key pair for which the | 471 | | recipient has the private key while the originator used | 472 | | the public key. | 473 | okid | String identifier for the originator's asymmetric key | 474 | | pair, the public key of which is needed by the recipient | 475 | | to process the message. | 476 | jku | String holding a Uniform Resource Identifier (URI) for one | 477 | | or more public keys in JSON Web Key format | 478 | | [draft-ietf-jose-json-web-key]. It MUST be an HTTPS URI. | 479 | x5u | String holding a Uniform Resource Identifier (URI) for an | 480 | | X.509 certificate chain. | 481 +------+------------------------------------------------------------+ 483 Additional header elements can be defined in other documents. A 484 header element name can be a URI or a short name. A short name MUST 485 NOT contain a colon ":" (which a URI will contain), but can otherwise 486 be any Unicode string. A header element name that is a short name 487 MUST be registered in the JWsec header element registry. A header 488 element name that is a URI MAY be registered. 490 8. IANA considerations 492 8.1. JWsec Header Element Registry 494 This document establishes a registry that IANA will maintain for 495 elements that can appear in the header of a JWsec message. The 496 registry's name is "JWsec Header Element Registry". The registry 497 lists element names and the specification where they are defined. 499 The policy for registring a name that is a URI is First Come First 500 Served (as per [RFC5226] section 4.1). The policy for registring a 501 name that is not a URI (and MUST NOT contain a colon) is 502 Specification Required. 504 The initial contents of the registry are: 506 +------+-----------------+ 507 | Name | Reference | 508 +------+-----------------+ 509 | zip | [this document] | 510 | sig | [this document] | 511 | kmg | [this document] | 512 | enc | [this document] | 513 | kid | [this document] | 514 | okid | [this document] | 515 | jku | [this document] | 516 | x5u | [this document] | 517 +------+-----------------+ 519 8.2. Media type 521 The "application/jwsec" media type is registered with IANA to 522 identify a JWsec message. 524 Type name: application 525 Subtype name: jwsec 526 Required parameters: none 527 Optional parameters: none 528 Encoding considerations: 7bit 529 Security considerations: Some JWsec messages provide data origin 530 authenticity and confidentiality, but others provide no security. 531 A recipient of a message with this media type needs to ensure that 532 the security provided by the actual message received meets the 533 receiver's expectations for the message. 534 Interoperability considerations: no known issues 535 Published specification [this document] 536 Applications that use this media type: expected to be used by a 537 range of web applications 538 Additional information: none 539 Contact: IETF 540 Intended usage: COMMON 541 Restrictions on usage: none 542 Author: IETF 543 Change controller: IETF 545 9. Security considerations 547 JWsec messages have different security properties depending on the 548 modes of protection applied, the order they are applied, and whether 549 symmetric or asymmetric keys are used. A JWsec message can have no 550 security. Consequently, a recipient needs to explicitly confirm that 551 the protection applied to each received message matchs the expected 552 protection. 554 ... 556 10. Normative References 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, March 1997. 561 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 562 Requirements for Security", BCP 106, RFC 4086, June 2005. 564 [RFC4627] Crockford, D., "The application/json Media Type for 565 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 567 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 568 Encodings", RFC 4648, October 2006. 570 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 571 RFC 5652, September 2009. 573 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 574 Specifications: ABNF", STD 68, RFC 5234, January 2008. 576 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 577 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 578 May 2008. 580 [draft-ietf-jose-json-web-key] 581 Jones, M., "JSON Web Key (JWK)", May 2012. 583 [ALGS] Doe, J., "JSON Web Security Message Algorithms (similar to 584 draft-ietf-jose-json-web-algorithms)", June 2012. 586 Appendix A. Acknowledgments 588 [TODO] 590 Author's Address 592 James Manger 593 Telstra 595 Email: james@manger.com.au