idnits 2.17.1 draft-barnes-jose-jsms-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 == Line 556 has weird spacing: '...128-ccm yes (...' == Line 559 has weird spacing: '...128-gcm yes (...' == Line 565 has weird spacing: '...es-oaep no ...' == Line 729 has weird spacing: '... sign ature...' -- The document date (June 15, 2012) is 4326 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: 'FIPS186' is mentioned on line 535, but not defined == Missing Reference: 'RFC6090' is mentioned on line 571, but not defined == Missing Reference: 'FIPS180-1' is mentioned on line 549, but not defined == Missing Reference: 'FIPS180-3' is mentioned on line 552, but not defined == Missing Reference: 'RFC3610' is mentioned on line 556, but not defined == Missing Reference: 'RFC3394' is mentioned on line 564, but not defined == Missing Reference: 'RFC2631' is mentioned on line 569, but not defined == Missing Reference: 'TODO' is mentioned on line 1093, but not defined == Unused Reference: 'RFC2045' is defined on line 1011, but no explicit reference was found in the text == Unused Reference: 'RFC3339' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 1025, but no explicit reference was found in the text == Unused Reference: 'RFC5116' is defined on line 1034, but no explicit reference was found in the text == Unused Reference: 'RFC5649' is defined on line 1045, but no explicit reference was found in the text == Unused Reference: 'RFC5840' is defined on line 1049, but no explicit reference was found in the text == Unused Reference: 'FIPS-180-3' is defined on line 1053, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 1060, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-jose-json-web-signature' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'GCM' is defined on line 1086, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5649 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-3' == Outdated reference: A later version (-41) exists of draft-ietf-jose-json-web-signature-02 Summary: 4 errors (**), 0 flaws (~~), 24 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft BBN Technologies 4 Intended status: Standards Track June 15, 2012 5 Expires: December 17, 2012 7 JavaScript Message Security Format 8 draft-barnes-jose-jsms-00.txt 10 Abstract 12 Many applications require the ability to send cryptographically 13 secured messages. While the IETF has defined a number of formats for 14 such messages (e.g. CMS) those formats use encodings which are not 15 easy to use in modern applications. This document describes the 16 JavaScript Message Security format (JSMS), a new cryptographic 17 message format which is based on JavaScript Object Notation (JSON) 18 and thus is easy for many applications to generate and parse. 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 17, 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 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 56 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Operational Modes . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Design Principles . . . . . . . . . . . . . . . . . . . . 4 59 3.3. Certificate Processing . . . . . . . . . . . . . . . . . . 5 60 3.4. Certificate Discovery . . . . . . . . . . . . . . . . . . 5 61 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Data types . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Basic Types . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.3. SignedData . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.3.1. Signature . . . . . . . . . . . . . . . . . . . . . . 7 66 4.3.2. Generating a SignedData Object . . . . . . . . . . . . 8 67 4.3.3. Verifying a SignedData Object . . . . . . . . . . . . 8 68 4.4. AuthenticatedData . . . . . . . . . . . . . . . . . . . . 9 69 4.4.1. Generating an AuthenticatedData Object . . . . . . . . 9 70 4.4.2. Verifying an AuthenticatedData Object . . . . . . . . 9 71 4.5. EncryptedData . . . . . . . . . . . . . . . . . . . . . . 10 72 4.5.1. Generating an EncryptedData Object . . . . . . . . . . 10 73 4.5.2. Decrypting a EncryptedData Object . . . . . . . . . . 11 74 4.6. Useful Objects . . . . . . . . . . . . . . . . . . . . . . 11 75 4.6.1. AlgorithmIdentifier . . . . . . . . . . . . . . . . . 11 76 4.6.2. PublicKey . . . . . . . . . . . . . . . . . . . . . . 14 77 4.6.3. WrappedKey . . . . . . . . . . . . . . . . . . . . . . 16 78 5. Compact Format . . . . . . . . . . . . . . . . . . . . . . . . 17 79 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 6.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 18 81 6.2. SignedData . . . . . . . . . . . . . . . . . . . . . . . . 18 82 6.3. AuthenticatedData . . . . . . . . . . . . . . . . . . . . 19 83 6.4. EncryptedData . . . . . . . . . . . . . . . . . . . . . . 20 84 7. Mapping to CMS . . . . . . . . . . . . . . . . . . . . . . . . 20 85 8. Comparison to JWS/JWE/JWK . . . . . . . . . . . . . . . . . . 21 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 92 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 25 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 1. Introduction 97 Many applications require the ability to send cryptographically 98 secured (encrypted, digitally signed, etc.) messages. While the IETF 99 has defined a number of formats for such messages, those formats are 100 widely viewed as being excessively complicated for the demands of Web 101 applications, which typically only need the ability to secure simple 102 messages. In addition, existing formats use encoding mechanisms 103 (e.g., ASN.1 DER) which are not congenial for many classes of 104 applications (e.g., Web applications). This presents an obstacle to 105 the deployment of strong security by such applications. 107 This document describes a new cryptographic message format, 108 JavaScript Message Security (JSMS). This format is intended to meet 109 the need of modern applications, including JavaScript-based Web 110 applications. While JSMS is modeled on existing formats -- 111 principally CMS [RFC5652] -- it uses JavaScript Object Notation 112 (JSON) rather than ASN.1, making it far easier for applications to 113 handle. In the interest of simplicity, JSMS also omits many of less 114 commonly used CMS modes (such as password-based encryption). 116 2. Conventions Used In This Document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 In order to enable JSON to carry binary data, JSMS makes extensive 123 use of Base64 encoding [RFC4648]. Whenever this document refers to 124 Base64 encoding, we mean the URL-safe variant "base64url" encoding. 125 As stated in section 3.1 of [RFC4648], Base64 does not allow 126 linefeeds. Since linefeeds are not valid characters in a JSON 127 string, whenever a field is specified to be Base64-encoded in this 128 document, it MUST NOT include any line breaks. Base64-encoded fields 129 also MUST NOT include JSON-encoded linefeeds such as "\n". Any 130 linebreaks in the middle of Base64-encoded sections of the examples 131 in this document have been inserted in order to make the examples fit 132 on the page. Any trailing "=" characters SHOULD be removed. They 133 are not needed, because JSON strings have defined lengths (namely the 134 number of characters between unescaped '"' characters). 136 3. Overview 138 The JSMS message format is simply a JSON [RFC4627] object with an 139 appropriate collection of fields. Each operating mode will have a 140 separate set of fields, with a common field to distinguish between 141 the modes. 143 3.1. Operational Modes 145 JSMS supports three operational modes: 146 Signed Data 147 A block of data signed by a single signer using his asymmetric key 148 and optionally carrying his certificate. 149 Authenticated Data 150 A block of data with authentication and integrity protection 151 provided using a symmetric-key Message Authentication Code (MAC). 152 The MAC key may be provided in encrypted form (as with Encryped 153 Data) or identified by name. 154 Encrypted Data 155 A block of data encrypted under a random message encryption key 156 (MEK). The MEK is then separately encrypted for each recipient, 157 either via symmetric or asymmetric encryption. The data is always 158 integrity protected, through the use of an Authenticated 159 Encryption with Associated Data (AEAD) algorithm such as AES-GCM 160 or AES-CCM. 162 Any other desired security functions are provided by composition of 163 these modes. For instance, a signed and encrypted message is 164 produced by first creating a Signed message and then encrypting that 165 data. 167 3.2. Design Principles 169 In general, JSMS follows the following design principles. 171 Minimize implementation complexity 172 Wherever possible, protocol choices have been made such that the 173 time and effort required to implement the protocol in many 174 different programming languages will be minimized. This means 175 that optimizations for bandwidth, CPU, and memory utilization have 176 been explicitly avoided. 177 Base64 as the only encoding 178 Any data that does not have a straightforward string 179 representation (binary values, large integers, etc.) is base64- 180 encoded (see: [RFC4648]). In some cases, hexadecimal encodings 181 might be more convenient, but consistency is even more important 182 to reduce implementation complexity. 183 No canonicalization 184 In many cryptographic message formats, canonical encodings are 185 used to allow the same value to be computed at both sender and 186 recipient (e.g., for digital signatures). This is inconvenient in 187 JSON, which just views messages as a bundle of key/value pairs. 188 Instead, whenever canonicalization would be required, the relevant 189 data is serialized and base64-encoded for transport, allowing both 190 sides to run computations over the same original set of octets. 191 In-memory processing 192 We assume that the entire message can fit in main memory and make 193 no effort to design a wire representation which can be handled in 194 small chunks in a single pass. This means, for instance, that 195 there is no need to have a message digest indicator at the 196 beginning of the message and then the signature at the end, as is 197 done in CMS. Fields are simply serialized in whatever order is 198 most convenient for the JSON implementation. The examples in this 199 document are generally shown in whatever order seems most readable 200 and are not normative. 201 Consistency with CMS 202 To simplify the adaptation of existing cryptographic modules and 203 the validation of JSMS implementations, changes from the CMS 204 cryptographic operations are minimized. JSMS is semantically 205 equivalent to a profile of CMS, as described in Section 7. 207 3.3. Certificate Processing 209 Experience has shown that certificate handling (path construction) is 210 one of the trickier parts of building a cryptographic system. While 211 JSMS supports PKIX certificates, its certificate processing is far 212 simpler than that of CMS. (It also supports the use of bare public 213 keys in order to avoid the use of X.509 altogether.) When a JSMS 214 agent provides its certificate, it must provide an ordered chain (as 215 in TLS [RFC5246]) terminating in its own certificate, thus removing 216 the need to construct certificate paths. The certificates MUST be 217 ordered with the end-entity certificate first and each certificate 218 that follows signing the certificate immediately preceding it. 220 3.4. Certificate Discovery 222 JSMS will often be used in an online messaging environments with 223 users that have an address of the form user@domain, such as email, 224 XMPP, or SIP. As such, protocols such as WebFinger 225 [I-D.hammer-webfinger] or an end-to-end protocol can be used to 226 retrieve appropriate certificates. Downstream uses of JSMS SHOULD 227 define a discovery mechanism suitable for the intended use. 229 4. Message Format 231 A JSMS object is a JSON object that encodes cryptographic informaton 232 related to a content byte string. This document specifies the set of 233 keys that must be present in a JSMS object, what the associated 234 values are, and how these values are generated and processed in order 235 to realize security features. In processing JSMS objects, unknown 236 keys MUST be ignored. 238 JSMS defines three top-level types of secure object, each of which 239 provides a specific cryptographic protection to a byte string. 241 SignedData: Signature using a public-key digital signature algorithm 242 AuthenticatedData: Authentication using a Message Authentication 243 Code (MAC) 244 EncryptedData: Encryption and authentication using an Authenticated 245 Encryption with Associated Data (AEAD) algorithm 247 4.1. Data types 249 For each field in a JSON object, we define the type of information 250 that must be included in that field. At base are the object, array, 251 string, number types defined by JSON. We also use two special sub- 252 classes of strings: Fields with type "Token" contain a string drawn 253 from a defined list of strings (e.g., an IANA registry for algorithm 254 names). Fields with type "ByteString" contain a Base64-encoded byte 255 string (note the considerations related to Base64 encoding in 256 Section 2 above). 258 In addition to the primitive data types, Section 4.6 defines a 259 collection of useful object types that are used by the top-level JSMS 260 objects. These are simply referred to by name when they appear as a 261 field value in another object. 263 4.2. Basic Types 265 The following elements are common to all JSMS messages: 267 "version": REQUIRED Number. The version of JSMS used by this 268 objec.t. This field MUST be set to 1. 269 "type": REQUIRED Token. The type of this JSMS object. This field 270 MUST be set to one of the following values 271 "signed": SignedData object 272 "authenticated": AuthenticatedData object 273 "encrypted": EncryptedData object 274 "content": OPTIONAL ByteString. The content byte string, Base64- 275 encoded. 277 If the "content" key is not present in a given JSMS object, then the 278 JSMS object is "detached". In this case, the content must be 279 associated with the JSMS object through some out-of-band mechanism 280 before the JSMS object can be processed. Note that there is a risk 281 that detached JSMS object might become invalid if the content is 282 transformed, even if this transformation preserves the semantics of 283 the content. For example, if the content is a JSON object, and the 284 object passes through an intermediate process that adds whitespace or 285 re-orders the fields in the object (neither of which changes the 286 meaning of the object), then the recipient will not be able to verify 287 the signature. For this reason, detached JSMS objects SHOULD NOT be 288 used unless there is a canonical form for the content being 289 processed. 291 4.3. SignedData 293 A SignedData object MUST have a "type" field set to "signed". In 294 addition, a SignedData object contains the following keys: 296 "digestAlgorithm": REQUIRED AlgorithmIdentifier. The digest 297 algorithm used in signing the content. 298 "signatures": REQUIRED Array of Signature. One or more digital 299 signatures over the content. 300 "certificates": OPTIONAL Array of String. A certificate chain 301 associating the signer's public key with an identifier. Each 302 element in the array is a string containing the Base64-encoded 303 representation of a DER-formatted certificate. The certificates 304 MUST be ordered with the end-entity certificate first and each 305 certificate that follows signing the certificate immediately 306 preceding it. 307 "certificatesURI": OPTIONAL String. An HTTP or HTTPS URI referring 308 to a certificate chain. The referenced resource MUST have type 309 "application/json" and contain an array of certificates in the 310 same format as the "certificates" element above, including the 311 ordering constraint. 313 4.3.1. Signature 315 A Signature object represents the signature over the content in the 316 SignedData object by a specific key pair. A Signature objec can 317 contain the following keys: 319 "signatureAlgorithm": REQUIRED AlgorithmIdentifier. The signature 320 algorithm used in signing the content. 321 "key" REQUIRED PublicKey. The public key identifier for the signer, 322 represented as a PublicKey object (see Section 4.6.2) 323 "signature" REQUIRED ByteString. The Base64-encoded signature value 325 If the "key" value represents the public key as an identifier, then a 326 certificate for the signer MUST be provided by setting either the 327 "certificates" or "certificatesURL" fields. The subject key in the 328 end-entity certificate MUST match the identifier in the "key" value; 329 the certificate SHOULD contain the subjectKeyIdentifier field, with a 330 value matching the "key" value. (Note that this implies that when 331 there are multiple signers, only one key can be represented by ID.) 333 4.3.2. Generating a SignedData Object 335 The inputs to the process of generating a SignedData object are: 337 o The content, as a byte string 338 o A digest algorithm 339 o One or more signature algorithms and asymmetric key pairs 341 To generate the signature for SignedData object, the originator takes 342 the following steps: 344 1. Compute the message digest by applying the digest algorithm to 345 the content. 346 2. For each signing key pair, compute the signature by using the 347 signature algorithm to sign the message digest with the private 348 key from the asymmetric key pair. 350 The originator then encodes the SignedData object by including the 351 appropriate AlgorithmIdentifiers for the digest algorithms, a 352 Signature object for each signature, and (optionally) the content. 354 4.3.3. Verifying a SignedData Object 356 To verify a SignedData object, the recipient takes the following 357 steps: 359 1. Verify that the digest and signature algorithms are supported. 360 Otherwise, report an error and fail. 361 2. Compute the content byte string by decoding the "content" value 362 of the JSMS object. If the JSMS object does not contain a 363 "content" field, retrieve the content by other means. 364 3. Compute the message digest by applying the digest algorithm to 365 the content. 366 4. Compute the signature by decoding the "signature" value of the 367 JSMS object. 368 5. Compute the public key: 369 * If the key is represented directly, then decode it according 370 to the rules specified by the algorithm name. 371 * If the key is represented by an ID, then retrieve the 372 corresponding subject public key from the end-entity 373 certificate . If no "certificates" or "certificatesURI" value 374 is present, then report an error and fail. 375 * If the key is represented by a URI, retrieve the public key 376 from the URI. 377 6. Verify the signature by using the signature algorithm to verify 378 the message digest with the public key. 380 4.4. AuthenticatedData 382 An AuthenticatedData object MUST have a "type" field set to 383 "authenticated". In addition, an AuthenticatedData object contains 384 the following keys: 386 "algorithm": REQUIRED AlgorithmIdentifier. The MAC algorithm used 387 to authenticate the content. 388 "mac": REQUIRED ByteString. The MAC value 389 "keys": OPTIONAL Array of WrappedKey. Wrapped versions of the 390 symmetric key used for this MAC. Each element in the array MUST 391 be a WrappedKey object (see below) 392 "keyId": OPTIONAL ByteString. An opaque identifier for a pre-shared 393 MAC key 395 An AuthenticatedData object MUST contain either the "key" field or 396 the "keyId" field, so that the recipient knows which key to use to 397 verify the MAC. 399 4.4.1. Generating an AuthenticatedData Object 401 The inputs to the process of generating a AuthenticatedData object 402 are: 404 o The content, as a byte string 405 o A MAC algorithm 406 o A MAC key and key identifier, or 407 o One or more recipient keys and key encipherment algorithms 409 If the recipient key is specified rather than the MAC key directly, 410 then a random MAC key is generated and encoded in a WrappedKey 411 objects for each recipient (see Section 4.6.3). Once the MAC key has 412 been determined, the originator uses the MAC algorithm and MAC key to 413 compute the MAC over the content byte string. 415 The originator then encodes the AuthenticatedData object by including 416 the appropriate AlgorithmIdentifier for the MAC algorithm and the 417 Base64 representations of the MAC value and (optionally) the content. 418 If the MAC key was specified directly, then the Base64 representation 419 of the key identifier is set as the "keyId" value; otherwise, the 420 WrappedKey objects are collected in an array and set as the "keys" 421 value. 423 4.4.2. Verifying an AuthenticatedData Object 425 To verify a AuthenticatedData object, the recipient takes the 426 following steps: 428 1. Verify that the MAC algorithm is supported. If not, report an 429 error and fail. 430 2. Compute the content byte string by decoding the "content" value 431 of the JSMS object. If the JSMS object does not contain a 432 "content" field, retrieve the content by other means. 433 3. Compute the MAC key: 434 * If the "keyId" value is present and represents a known key, 435 use the identified key. 436 * If the "keys" value is present, check each WrappedKey object 437 to determine if it matches a known key for this recipient. If 438 any of the wrapped keys matches, unwrap the key from the first 439 one and use it (see Section Section 4.6.3). Otherwise, report 440 an error and fail. 441 4. Use the MAC algorithm and MAC key to compute the MAC over the 442 content byte string 443 5. Decode the MAC value from the "mac" field. 444 6. Verify that the computed MAC matches the MAC from the object. 446 4.5. EncryptedData 448 An EncryptedData object MUST have a "type" field set to "encrypted". 449 Note also that in an EncryptedData object, the "content" field 450 contains the encrypted form of the content, not the content itself 451 (as plaintext). An EncryptedData object contains the following keys 452 in addition to any common fields: 454 "algorithm": REQUIRED AlgorithmIdentifier. The encryption algorithm 455 used to encrypt the content 456 "keys": REQUIRED Array of WrappedKey. Wrapped versions of the 457 symmetric key used to encrypt the content. Each element in the 458 array MUST be a WrappedKey object (see Section 4.6.3). 459 "mac": OPTIONAL ByteString. The MAC value, if required by the 460 algorithm 462 Note that although the "mac" field is optional, an EncryptedData 463 object always has an integrity check. All of the encryption 464 algorithms used in JSMS are "Authenticated Encryption with Associated 465 Data" algorithms, which include an authentication / integrity fuction 466 by definition. The MAC field is optional because some AEAD 467 algorithms have a separate MAC value (e.g., GCM), while others 468 incorporate the MAC value into the ciphertext (e.g., CCM). 470 4.5.1. Generating an EncryptedData Object 472 The inputs to the process of generating a SignedData object are: 474 o The content, as a byte string 475 o An encryption algorithm 476 o One or more recipient keys and key encipherment algorithms 478 The originator generates a random encryption key of a length suitable 479 for the encryption algorithm, then encodes it in a WrappedKey object 480 for each recipient (see Section 4.6.3). The content is then 481 encrypted using the generated encryption key and the specified 482 encryption algorithm. 484 The originator then encodes the EncryptedData object by including the 485 appropriate AlgorithmIdentifier for the encryption algorithm, an 486 array containing the WrappedKey objects, and (optionally) the Base64 487 representation of the content. 489 4.5.2. Decrypting a EncryptedData Object 491 To decrypt an EncryptedData object, the recipient takes the following 492 steps: 494 1. Verify that the encryption algorithm is supported. If not, 495 report an error and fail. 496 2. Compute the content byte string by decoding the "content" value 497 of the JSMS object. If the JSMS object does not contain a 498 "content" field, retrieve the content by other means. 499 3. Locate the encryption key: Check each WrappedKey object to 500 determine if it matches a known key for this recipient. If any 501 of the wrapped keys matches, unwrap the key from the first one 502 and use it (see Section 4.6.3). Otherwise, report an error and 503 fail. 504 4. Decrypt the content using the encryption key and the specified 505 encryption algorithm. 506 5. Verify that the integrity check in the AEAD decryption was 507 successful. If not, report an error and fail. 508 6. Return the decrypted content. 510 4.6. Useful Objects 512 In this section we define some common object types that are used 513 across the top-level objects above. 515 4.6.1. AlgorithmIdentifier 517 An AlgorithmIdentifier object names a cryptographic algorithm and 518 specifies any associated parameters such as nonces or initialization 519 vectors (IVs). If the algorithm has no parameters, then the 520 AlgorithmIdentifier object is simply a token representing the name of 521 the algorithm, drawn from an IANA registry of algorithm names. 523 If the algorithm specifies parameters, the AlgorithmIdentifier object 524 is a JSON object. There is only one required field, "name". Any 525 other fields are specified in the algorithm definition. 526 "name": REQUIRED Token. The name of the algorithm, chosen from one 527 of the IANA registries defined by this document. 529 The following table summarizes the algorithms to be used with JSMS. 530 [[ More detail to be added later, in a separate document ]] 531 Name Parameters Reference Example 532 =================================================================== 533 SIGNING 534 rsa no [RFC3447] "rsa" 535 dsa yes (p,q,g) [FIPS186] {name:"dsa", 536 p:1, q:2, g:3} 537 ecdsa yes (curve) [RFC6090] {name:"ecdsa", 538 curve:"P-256"} 540 ------------------------------------------------------------------- 541 DIGEST 542 sha1 no [FIPS180-1] "sha1" 543 sha256 no [FIPS180-3] "sha256" 544 sha384 no [FIPS180-3] "sha384" 545 sha512 no [FIPS180-3] "sha512" 547 ------------------------------------------------------------------- 548 MAC 549 hs1 no [FIPS180-1] "hs1" 550 hs256 no [FIPS180-3] "hs256" 551 hs384 no [FIPS180-3] "hs384" 552 hs512 no [FIPS180-3] "hs512" 554 ------------------------------------------------------------------- 555 ENCRYPTION 556 aes128-ccm yes (n,M) [RFC3610] {name:"aes128-ccm", 557 n:"ZONce...lU-g", 558 m:8} 559 aes128-gcm yes (iv) [McGrew & Viega] {name:"aes128-gcm", 560 iv:"ZONce...lU-g"} 562 ------------------------------------------------------------------- 563 KEY ENCIPHERMENT 564 aes no [RFC3394] "aes" 565 rsaes-oaep no [RFC3447] "rsaes-oaep" 567 ------------------------------------------------------------------- 568 KEY AGREEMENT 569 dh-es yes (group) [RFC2631] {name:"dh-es", 570 group: 14} 571 ecdh-es yes (curve) [RFC6090] {name:"ecdh-es", 572 curve:"P-256"} 573 =================================================================== 575 Obviously, there will be more detail needed beyond the above, and 576 some IANA considerations to create the necessary registries. For 577 some algorithms, there will be specific notes about how they are to 578 be used with JSMS, for example: 579 o The signature value produced by DSA is comprised of two integers. 580 The byte string to be filled in the "signature" field is the two- 581 element JSON array containing two integers, "[r,s]" 582 o RSAES-OAEP is always used with SHA-256 and the default MGF1 583 masking generation function 584 o Elliptic curves may only be specified by name, not by directly 585 specifying curve parameters. [[ We may define our own registry, or 586 re-use the ones from TLS/IKE. ]] 587 o AEAD algorithms are only used for authenticated encryption; there 588 is never associated data. Further AEAD algorithms may be defined 589 using [draft-mcgrew-aead-aes-cbc-hmac-sha1] 591 4.6.2. PublicKey 593 A PublicKey object describes the public key used by a signer. The 594 key may be specified as a JSON structure directly, as a URI, or as an 595 identifier. A PublicKey object has the following fields: 597 "type" OPTIONAL Token. The name of the algorithm with which this 598 key is to be used 599 "id" OPTIONAL ByteString. An identifier for the key 600 "uri" OPTIONAL String. A URI pointing to a direct form of the key 602 If the key is specified directly, then the "type" key MUST be 603 present; the "id" and "uri" fields MAY be present. Subsequent 604 entries in the array specify the elements of the key, in a manner 605 determined by the algorithm. Formats for RSA and ECDH/ECDSA public 606 keys are specified below. 608 If the key is provided as a URI, then the "uri" field MUST be 609 present, containing a URI where the key can be retrieved, in the JSON 610 format described above. The method that the recipient of a JSMS 611 object uses to retrieve the key will depend on the URI scheme. For 612 HTTP URIs, the relying party MUST issue an HTTP request with the GET 613 method and an Accept header including the MIME type for JSMS 614 PublicKey object, "[[MIMETYPE-TBD]]". For MAILTO, SIP, and XMPP 615 URIs, the recipient MAY use the WebFinger protocol 616 [I-D.hammer-webfinger] to retrieve a public key for the user. 618 If the key is referenced by an opaque identifier or "fingerprint", 619 then the "id" field MUST be present, and contain the Base64-encoded 620 SHA-1 hash of the public key, represented as a DER-encoded 621 subjectPublicKeyInfo data structure. (This fingerprint value is the 622 same as the one commonly included in the subjectKeyIdentifier field 623 in an X.509 certificate.) 625 The recipient of a JSMS object can determine which of the above cases 626 a given key falls into by seeking the three fields in sequence. If a 627 "type" field is present, then the key is represented directly. If a 628 "uri" field is present, then the key is represented directly, but 629 must be retreived from the URI. Finally, if the "id" field is the 630 only one of the three present, then the key is represented by ID 631 only, and must be retrieved from somewhere else (e.g., from a 632 certificate in the JSMS object). 634 Example: {"id": "i1LbR8FCEw-aiFcAAfUvpp75wdY="} 636 Example: {"uri": "xmpp:juliet@example.com"} 638 4.6.2.1. RSA Public Key 640 An RSA public key comprises two additional parameters in addition to 641 the algorithm identifier "rsa". 643 "n": REQUIRED ByteString. The modulus, represented as an integer in 644 network byte order (big-endian) 645 "e": REQUIRED Integer. The public exponent, represented as an 646 integer in network byte order (big-endian) 648 Example: {"type":"rsa", "n":98739...04251, "e": 3} 650 4.6.2.2. Elliptic-Curve Public Key 652 Public keys for several types of elliptic curve algorithms, including 653 ECDSA and ECDH, have the same format, namely an point on a specified 654 elliptic curve. In an elliptic curve PublicKey object, the curve 655 parameters are specified in the algorithm identifier, and there are 656 two additional fields that specify the point on the curve: 658 "x": REQUIRED ByteString. The x coordinate of the point 659 "y": REQUIRED Integer. The y coordinate of the point. MUST be 660 equal to 0 or 1. 662 These coordinates correspond to the compressed form of an elliptic 663 curve point, as specified in [[SEC01]]. In terms of the calculation 664 specified in section 2.3.3 of [[SEC01]], the "x" coordinate is the 665 byte string X and the "y" coordinate is the reduced y coordinate (or, 666 equivalently, Y mod 2). 668 Example: {"type":"ecdh", 669 "x":"IIIs_x1m6Na6xKN37vOwvy7AvFeG9HhBN2EN3u5EZQ4", "y": 1} 671 4.6.3. WrappedKey 673 In JSMS objects that use symmetric keys (for MAC or encryption), it 674 is necessary for the originator to convey the symmetric key used for 675 in JSMS computations to the recipient. The WrappedKey object is a 676 JSON object that allows these keys to be provided either using key 677 transport or key agreement. The following fields may be present in a 678 WrappedKey object: 680 "type": REQUIRED TOKEN The type of wrapping being done. This 681 document defines the following values for this field: 682 "encryption": Symmetric key transport. The "KEKIdentifier" field 683 MUST be present. Any other non-required fields MUST be 684 ignored. 685 "transport": Asymmetric key transport. The "recipientKey" field 686 MUST be present. Any other non-required fields MUST be 687 ignored. 688 "agreement": Key agreement. The "originatorKey" and 689 "recipientKey" MUST be present, and the "userKeyMaterial" field 690 MAY be present. Any other non-required fields MUST be ignored. 691 "algorithm": REQUIRED AlgorithmIdentifier The algorithm used to 692 encrypt the symmetric key 693 "encryptedKey": REQUIRED BYTES The symmetric key, encrypted 694 according to the algorithm indicated by the "algorithm" value 695 "KEKIdentifier": OPTIONAL BYTES An opaque identifier for the 696 symmtric key encryption key 697 "originatorKey": OPTIONAL PublicKey The public key of the originator 698 "recipientKey": OPTIONAL PublicKey The public key of the recipient 699 "userKeyMaterial": OPTIONAL BYTES User key material 701 The techniques used for wrapping and unwrapping the encrypted key is 702 determined by "type" and "algorithm" fields. In general, the options 703 are the same as for CMS [RFC5280], without the option for password- 704 based key wrapping. 706 "encryption": The key is encrypted under a pre-shared symmetric 707 key encryption key identified by the "KEKIdentifier" field 708 "transport": The key is encrypted under the recipient's public key, 709 identified in the "recipientKey" field. 710 "agreement": The key is encrypted under a shared secret derived 711 using a key agreement algorithm combining the originator's private 712 key and the recipient's public key, corresponding to the 713 "originatorKey" and "recipientKey", respectively. The value 714 provided in the "userKeyMaterial" field may be used to provide 715 additional entropy. 716 [[ More detail to be added. ]] 718 5. Compact Format 720 The compact JSON format of a JSMS object is identical to the normal 721 JSMS format, except that field names are replaced with shorter 722 equivalent field names. Translations for the field names above are 723 given in the table below. In a given JSMS object, field names MUST 724 either all be in long form or all be in short form. An 725 implementation MUST reject a JSMS object with mixed long and short 726 names as improperly formatted. 727 Common Signature 728 -------------------------- -------------------------- 729 version v sign atureAlgorithm sa 730 type t key k 731 signed s signature sg 732 authenticated au -------------------------- 733 encrypted en 734 content c 735 -------------------------- AlgorithmIdentifier 736 -------------------------- 737 name nm 738 SignedData -------------------------- 739 -------------------------- 740 digestAlgorithm da 741 signatures ss PublicKey 742 certificates ce -------------------------- 743 certificatesURI cu type t 744 -------------------------- id i 745 uri u 746 -------------------------- 747 AuthenticatedData 748 -------------------------- 749 algorithm a WrappedKey 750 mac mac -------------------------- 751 keys ks type t 752 keyId ki encryption ec 753 -------------------------- transport tr 754 agreement ag 755 algorithm a 756 EncryptedData encryptedKey ek 757 -------------------------- KEKIdentifier i 758 algorithm a originatorKey o 759 keys ks recipientKey r 760 mac mac userKeyMaterial uk 761 -------------------------- -------------------------- 763 In applications where a JSMS object is required to be URL-safe, it is 764 RECOMMENDED that it be rendered in the compact serialization, then 765 Base64-encoded. 767 [[ If there is a desire to avoid double-base64url-encoding things, 768 then we could define a mechanism for moving some fields out of the 769 object. ]] 771 6. Examples 773 This section contains complete examples of all three JSMS types. All 774 white space is for readability only, and must be removed before the 775 examples can be considered valid JSMS objects. 777 6.1. Parameters 779 RSA key: 780 { 781 "type": "rsa", 782 "n": "AfWGinFrdktMCi4LkD_vcIsqc0m4JSS0rNDk_5Zdi8fwja_qH0M7d3 783 U4tPUw7L0gP1iSMakdTKX0S7uTV_v9FeY8_WrxDgbphrH9Zaz0PvTL 784 OuiKfRkMWK5A6nzl_PdP7_ujDWkvHKhWcJtM7irdn9K059X21EDtuq 785 GJyq7_v_c_", 786 "e": "AQAB", 787 "d": "EMwfyOqzfJQgZyhl_W40k8SpNdfgDpmqjBiPYubhLqIk7LZns6XDO3 788 7ZuLiZxT_WP04uMZ7UmV5URwUJVlxEpmfozhtLooCTP1oWtRQQjhTa 789 Pz1f5nRKoHsO8e3PZY7O44ut2prRWNNxYxDk52rH9GTECqGAmDNb1f 790 he6zX4KJk=" 791 } 793 Key Tag: HK1RA8AQwcI= 794 Symmetric key: rQS8Dx6WQ_xDWTER8mAHnw== 796 Content: 797 "Attack at dawn!" 799 6.2. SignedData 801 In this object the content is signed under the specified RSA key 802 pair, using SHA256 as the digest. 804 { 805 "version": 1, 806 "type": "signed", 807 "digestAlgorithm": "sha256", 808 "content": "QXR0YWNrIGF0IGRhd24h", 809 "signatures": [{ 810 "signatureAlgorithm": "rsa", 811 "key": { 812 "type": "rsa", 813 "n": "AfWGinFrdktMCi4LkD_vcIsqc0m4JSS0rNDk_5Zdi8 814 fwja_qH0M7d3U4tPUw7L0gP1iSMakdTKX0S7uTV_v9 815 FeY8_WrxDgbphrH9Zaz0PvTLOuiKfRkMWK5A6nzl_P 816 dP7_ujDWkvHKhWcJtM7irdn9K059X21EDtuqGJyq7_ 817 v_c_", 818 "e": "AQAB", 819 }, 820 "signature": "AJll1tVYsRtGeHaJenAU-U3x4LxXklNoGrFwyu 821 xJWnYIeLZL16Ib7ZPvD79peMiSQAHAdLKcI8e- 822 CpU6HNQ-MxeE-tEXvaXOxuNZfVG9LBP9hq_ZwX 823 SguffHHzS9lLtVB0OzrXeszXtqD5igmeco1A0E 824 8eabzujA4bdN6Umyc7rA" 825 }] 826 } 828 6.3. AuthenticatedData 830 In this object the content is authenticated with a MAC under a 831 randomly-generated key (AuthenticatedData Key above), wrapped using 832 the key encryption key above, identified by the above key tag. 833 { 834 "version": 1, 835 "type": "authenticated", 836 "algorithm": "hs256", 837 "content": "QXR0YWNrIGF0IGRhd24h", 838 "mac": "990xwhrsX-COXUN0uF09HUHLU2CjdneeMqTtM4sGVDY=", 839 "keys": [{ 840 "type": "encryption", 841 "algorithm": "aes", 842 "encryptedKey": "Dbf2O_ZIX0_Zfj-0aU6zQjn3xixj6vm7LVX 843 XFDdX4xqie5bZUS1nnstIPYOyzxNx9Udt-J 844 LZZh-zM8A_FbsZ8zAibdJ3EPyd", 845 "KEKIdentifier": "HK1RA8AQwcI=" 846 }] 847 } 849 As another example, the following object is a detached MAC (over the 850 same content string) in the compact encoding. Here we use the key as 851 the MAC key directly (instead of as a key encryption key). The 852 object is shown both in raw JSON form and in the Base64 encoding. 853 {"v": 1,"t": "au","a": "hs256","ki": "HK1RA8AQwcI=", 854 "mac": "PMVmhmrgbj-KNybfMqHu4ySJ0GnVrwe11MKpiuuGlIQ="} 856 eyJ2IjogMSwidCI6ICJhdSIsImEiOiAiaHMyNTYiLCJraSI6ICJISzFSQThBUXdj 857 ST0iLA0KICAibWFjIjogIlBNVm1obXJnYmotS055YmZNcUh1NHlTSjBHblZyd2Ux 858 MU1LcGl1dUdsSVE9In0= 860 6.4. EncryptedData 862 In this object, the content is encrypted under the general AEAD 863 algorithm using AES-128-CBC for encryption and HMAC-SHA1 for 864 authentication. The keys are described above as "EncryptedData Key 865 (E)" and "EncryptedData Key (A)", respectively. The temporary keys 866 are wrapped using the PKCS#1 wrapping, under the RSA key pair above. 867 { 868 "version": 1, 869 "type": "encrypted", 870 "algorithm": { 871 "name": "aes128-ccm", 872 "n": "LTR8s7KKbd1QlQ==", 873 "m": 8 874 }, 875 "content": "0nkXCLOVxM2oNJOsDCwASLTODIMVZQE=", 876 "keys": [{ 877 "type": "transport", 878 "algorithm": "rsaes-oaep", 879 "encryptedKey": "AbAxRnd_u7lICJlBskq3kgQVs54RLMgOjNmALXF 880 JjKqsQ4kLNL60VAoEswGOd2arGfcxoMCw9wMeSP 881 FOIvOXGvSt2wJXR_6kwzOJv_YyTC_eZUJHpcLNr 882 jKxB7Zf2_ap24W6JqcOYYVy2DhECcPgyvVRA_Ql 883 ZNHFYdqaImgOKJv-", 884 "recipientKey": { 885 "type": "rsa", 886 "n": "AfWGinFrdktMCi4LkD_vcIsqc0m4JSS0rNDk_5Zdi8fwja 887 _qH0M7d3U4tPUw7L0gP1iSMakdTKX0S7uTV_v9FeY8_Wrx 888 DgbphrH9Zaz0PvTLOuiKfRkMWK5A6nzl_PdP7_ujDWkvHK 889 hWcJtM7irdn9K059X21EDtuqGJyq7_v_c_", 890 "e": "AQAB", 891 } 892 }] 893 } 895 7. Mapping to CMS 897 The JSMS message format is semantically equivalent to a profile of 898 the Cryptographic Message Syntax (CMS), and mirrors a fair bit of its 899 syntactical structure as well. The top-level message types each map 900 to top-level CMS types: SignedData to SignedData, AuthenticatedData 901 to AuthenticatedData, and EncryptedData to AuthEnvelopedData 902 [RFC5083]. The main difference other than encoding is that many 903 optional fields have been removed, for example the protected and 904 unprotected attributes. 906 This similarity also applies to the secondary objects. Just as in 907 CMS, AlgorithmIdentifier objects carry an identifier for the 908 algorithm (here a name instead of an OID) and any related parameters. 909 The PublicKey object format is an amalgam of the SubjectKeyIdentifier 910 from CMS and the SubjectPublicKeyInfo from X.509. PublicKey objects 911 can be mapped to CMS constructs by converting them to 912 SubjectKeyIdentifier objects (using the appropriate hash) and 913 including a certificate containing the public key. The WrappedKey 914 object format maps directly to the CMS RecipientInfo structure, with 915 the above considerations related to public keys, and without the 916 option for password-based wrapping. 918 The major way in which JSMS diverges from CMS is that it allows the 919 use of static MAC keys, referenced by an identifier. CMS requires 920 the use of random MAC keys, encrypted in a RecipientInfo (i.e., a 921 WrappedKey) for each recipient. JSMS allows the use of random keys, 922 but also includes the "keyId" field to reference static MAC keys 923 directly. The security implications of this change are discussed in 924 Section 10. 926 In fact, it should be possible to translate JSMS objects back and 927 forth to CMS without changing any values (simply reformatting), with 928 only a couple of exception cases: 930 o JSMS objects that use static MAC keys cannot be translated to CMS 931 because CMS does not allow this keying mechanism. 932 o JSMS objects using general AEAD algorithms (according to 933 [[draft-mcgrew-aead-aes-cbc-hmac-sha1]]) because the required 934 algorithm identifiers have not been defined for CMS. 935 o CMS objects using features that are not supported in JSMS (e.g., 936 password-based key wrapping) cannot be translated to JSMS. 938 8. Comparison to JWS/JWE/JWK 940 The overall JSMS structure covers the integrity, authentication, and 941 encryption use cases as the JSON Web Encryption (JWE) and JSON Web 942 Signature (JWS) specifications. Most of the fields in JWS and JWE 943 map conceptually to JSMS fields, with a couple of exceptions. The 944 major differences are as follows: 946 o The signature and MAC functions of the JWS object are separated 947 into SignedData and AuthenticatedData JSMS objects. 948 o JSMS is pure JSON, whereas in JWE and JWS only the header 949 parameters are represented in JSON. 950 o JSMS parameters are not integrity-protected, as they are in JWE 951 and JWS. 952 o JSMS allows for full algorithm agility in key agreement, while JWE 953 only allows ECDH-ES. 954 o JSMS supports multiple recipients for EncryptedData and 955 AuthenticatedData objects via the inclusion of multiple WrappedKey 956 objects. Sending a JWE to multiple recipients requires re- 957 encryption of the entire object for each recipient. 958 o The "typ" and "zip" parameters are not defined in JSMS, but could 959 be added without significant change. 960 o JSMS requires that recipients MUST ignore unknown header 961 parameters, in order to facilitate extensibility. 963 The PublicKey structure is analogous to the JSON Web Key (JWK) (with 964 the public key parameters specified in the JSON Web Algorithms (JWA) 965 document). The JWK "use" and "kid" parameters are not defined in 966 JSMS, but could be added without significant change. 968 9. IANA Considerations 970 TODO: 971 o Register MIME types 972 o Registries for algorithms (signing, hash, MAC, encrypion, 973 encipherment, agreement) 975 10. Security Considerations 977 Much more to follow here. 979 [[ Given the CMS mapping above, import CMS security considerations. 980 ]] 982 [[ Notes on identity for SignedData and AuthenticatedData: It is 983 important to note that the above verification process only checks 984 that the JSMS object was signed with a given public key. In order 985 for this information to be useful to an applications, it is usually 986 necessary to bind the public key to an application-layer identifier. 987 If the "certificates" or "certificatesURI" value is present, then the 988 recipient SHOULD verify that the chain is valid, and that the the 989 end-entity certificate chains to a trust anchor. In this case, the 990 recipient can consider the identity asserted in the end-entity 991 certificate to be bound to the public key. Applications using this 992 specification without certificates will need to specify an 993 alternative mechanism for binding public keys to identifiers. ]] 995 [[ Notes on the security of static-key MACs. Need to periodically 996 refresh keys. ]] 998 [[ For multiple signatures, the considerations of RFC 4853. ]] 1000 11. Acknowledgements 1002 The inspirataion and starting point for this document was 1003 draft-rescorla-jsms-00. Thanks to Eric Rescorla and Joe Hildebrand 1004 for allowing me to re-use a fair bit of their document, and for some 1005 helpful early reviews. 1007 12. References 1009 12.1. Normative References 1011 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1012 Extensions (MIME) Part One: Format of Internet Message 1013 Bodies", RFC 2045, November 1996. 1015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1016 Requirement Levels", BCP 14, RFC 2119, March 1997. 1018 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1019 Internet: Timestamps", RFC 3339, July 2002. 1021 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1022 Standards (PKCS) #1: RSA Cryptography Specifications 1023 Version 2.1", RFC 3447, February 2003. 1025 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1026 Requirements for Security", BCP 106, RFC 4086, June 2005. 1028 [RFC4627] Crockford, D., "The application/json Media Type for 1029 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1031 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1032 Encodings", RFC 4648, October 2006. 1034 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1035 Encryption", RFC 5116, January 2008. 1037 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1038 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1040 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1041 Housley, R., and W. Polk, "Internet X.509 Public Key 1042 Infrastructure Certificate and Certificate Revocation List 1043 (CRL) Profile", RFC 5280, May 2008. 1045 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 1046 (AES) Key Wrap with Padding Algorithm", RFC 5649, 1047 September 2009. 1049 [RFC5840] Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped 1050 Encapsulating Security Payload (ESP) for Traffic 1051 Visibility", RFC 5840, April 2010. 1053 [FIPS-180-3] 1054 National Institute of Standards and Technology (NIST), 1055 "Secure Hash Standard (SHS)", FIPS PUB 180-3, 1056 October 2008. 1058 12.2. Informative References 1060 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1061 Resource Identifier (URI): Generic Syntax", STD 66, 1062 RFC 3986, January 2005. 1064 [I-D.hammer-webfinger] 1065 Hammer-Lahav, E., Fitzpatrick, B., and B. Cook, "The 1066 WebFinger Protocol", draft-hammer-webfinger-00 (work in 1067 progress), October 2009. 1069 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1070 RFC 5652, September 2009. 1072 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 1073 Authenticated-Enveloped-Data Content Type", RFC 5083, 1074 November 2007. 1076 [I-D.ietf-jose-json-web-signature] 1077 Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1078 Signature (JWS)", draft-ietf-jose-json-web-signature-02 1079 (work in progress), May 2012. 1081 [krawczyk-ate] 1082 Krawczyk, H., "The Order of Encryption and Authentication 1083 for Protecting Communications (or: How Secure Is SSL?)", 1084 Advances in cryptology--CRYPTO 2001 August 2001. 1086 [GCM] National Institute of Standards and Technology (NIST), 1087 "Recommendation for Block Cipher Modes of Operation: 1088 Galois/Counter Mode (GCM) and GMAC", SP 800-38D, 1089 November 2007. 1091 Appendix A. Acknowledgments 1093 [TODO] 1095 Author's Address 1097 Richard Barnes 1098 BBN Technologies 1099 1300 N. 17th St. 1100 Arlington, VA 22209 1101 USA 1103 Email: rbarnes@bbn.com