Secure Messaging vs. Javascript Object Signing and Encryption

The Web Payments group at the World Wide Web Consortium (W3C) is currently performing a thorough analysis on the MozPay API. The first part of the analysis examined the contents of the payment messages . This is the second part of the analysis, which will focus on whether the use of the Javascript Object Signing and Encryption (JOSE) group’s solutions to achieve message security is adequate, or if the Web Payment group’s solutions should be used instead.

The Contenders

The IETF JOSE Working Group is actively standardizing the following specifications for the purposes of adding message security to JSON:

JSON Web Algorithms (JWA)
Details the cryptographic algorithms and identifiers that are meant to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Token (JWT), and JSON Web Key (JWK) specifications. For example, when specifying an encryption algorithm, a JSON key/value pair that has alg as the key may have HS256 as the value, which means HMAC using the SHA-256 hash algorithm.
JSON Web Key (JWK)
Details a data structure that represents one or more cryptographic keys. If you need to express one of the many types of cryptographic key types in use today, this specification details how you do that in a standard way.
JSON Web Token (JWT)
Defines a way of representing claims such as “Bob was born on November 15th, 1984″. These claims are digitally signed and/or encrypted using either the JSON Web Signature (JWS) or JSON Web Encryption (JWE) specifications.
JSON Web Encryption (JWE)
Defines a way to express encrypted content using JSON-based data structures. Basically, if you want to encrypt JSON data so that only the intended receiver can read the data, this specification tells you how to do it in an interoperable way.
JSON Web Signature (JWS)
Defines a way to digitally sign JSON data structures. If your application needs to be able to verify the creator of a JSON data structure, you can use this specification to do so.

The W3C Web Payments group is actively standardizing a similar specification for the purpose of adding message security to JSON messages:

Secure Messaging (code named: HTTP Keys)
Describes a simple, decentralized security infrastructure for the Web based on JSON, Linked Data, and public key cryptography. This system enables Web applications to establish identities for agents on the Web, associate security credentials with those identities, and then use those security credentials to send and receive messages that are both encrypted and verifiable via digital signatures.

Both groups are relying on technology that has existed and been used for over a decade to achieve secure communications on the Internet (symmetric and asymmetric cryptography, public key infrastructure, X509 certificates, etc.). The key differences between the two have to do more with flexibility, implementation complexity, and how the data is published on the Web and used between systems.

Basic Differences

In general, the JOSE group is attempting to create a flexible/generalized way of expressing cryptography parameters in JSON. They are then using that information and encrypting or signing specific data (called claims in the specifications).

The Web Payments group’s specification achieves the same thing, but while not trying to be as generalized as the JOSE group. Flexibility and generalization tends to 1) make the ecosystem more complex than it needs to be for 95% of the use cases, 2) make implementations harder to security audit, and 3) make it more difficult to achieve interoperability between all implementations. The Secure Messaging specification attempts to outline a single best practice that will work for 95% of the applications out there. The 5% of Web applications that need to do more than the Secure Messaging spec can use the JOSE specifications. The Secure Messaging specification is also more Web-y. The more Web-y nature of the spec gives us a number of benefits, such as giving us a Web-scale public key infrastructure as a pleasant side-effect, that we will get into below.

JSON-LD Advantages over JSON

Fundamentally, the Secure Messaging specification relies on the Web and Linked Data to remove some of the complexity that exists in the JOSE specs while also achieving greater flexibility from a data model perspective. Specifically, the Secure Messaging specification utilizes Linked Data via a new standards-track technology called JSON-LD to allow anyone to build on top of the core protocol in a decentralized way. JSON-LD data is fundamentally more Web-y than JSON data. Here are the benefits of using JSON-LD over regular JSON:

  • A universal identifier mechanism for JSON objects via the use of URLs.
  • A way to disambiguate JSON keys shared among different JSON documents by mapping them to URLs via a context.
  • A standard mechanism in which a value in a JSON object may refer to a JSON object on a different document or site on the Web.
  • A way to associate datatypes with values such as dates and times.
  • The ability to annotate strings with their language. For example, the word ‘chat’ means something different in English and French and it helps to know which language was used when expressing the text.
  • A facility to express one or more directed graphs, such as a social network, in a single document. Graphs are the native data structure of the Web.
  • A standard way to map external JSON application data to your application data domain.
  • A deterministic way to generate a hash on JSON data, which is helpful when attempting to figure out if two data sources are expressing the same information.
  • A standard way to digitally sign JSON data.
  • A deterministic way to merge JSON data from multiple data sources.

Plain old JSON, while incredibly useful, does not allow you to do the things mentioned above in a standard way. There is a valid argument that applications may not need this amount of flexibility, and for those applications, JSON-LD does not require any of the features above to be used and does not require the JSON data to be modified in any way. So people that want to remain in the plain ‘ol JSON bucket can do so without the need to jump into the JSON-LD bucket with both feet.

JSON Web Algorithms vs. Secure Messaging

The JSON Web Algorithms specification details the cryptographic algorithms and identifiers that are meant to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Token (JWT), and JSON Web Key (JWK) specifications. For example, when specifying an encryption algorithm, a JSON key/value pair that has alg as the key may have HS256 as the value, which means HMAC using the SHA-256 hash algorithm. The specification is 70 pages long and is effectively just a collection of what values are allowed for each key used in JOSE-based JSON documents. The design approach taken for the JOSE specifications requires that such a document exists.

The Secure Messaging specification takes a different approach. Rather than declare all of the popular algorithms and cryptography schemes in use today, it defines just one digital signature scheme (RSA encryption with a SHA-256 hashing scheme), one encryption scheme (128-bit AES with cyclic block chaining), and one way of expressing keys (as PEM-formatted data). If placed into a single specification, like the JWA spec, it would be just a few pages long (really, just 1 page of actual content).

The most common argument against the Secure Messaging spec, with respect to the JWA specification, is that it lacks the same amount of cryptographic algorithm agility that the JWA specification provides. While this may seem like a valid argument on the surface, keep in mind that the core algorithms used by the Secure Messaging specification can be changed at any point to any other set of algorithms. So, the specification achieves algorithm agility while greatly reducing the need for a large 70-page specification detailing the allowable values for the various cryptographic algorithms. The other benefit is that since the cryptography parameters are outlined in a Linked Data vocabulary, instead of a process-heavy specification, that they can be added to at any point as long as there is community consensus. Note that while the vocabulary can be added to, thus providing algorithm agility if a particular cryptography scheme is weakened or broken, already defined cryptography schemes in the vocabulary must not be changed once the cryptography vocabulary terms become widely used to ensure that production deployments that use the older mechanism aren’t broken.

Providing just one way, the best practice at the time, to do digital signatures, encryption, and key publishing reduces implementation complexity. Reducing implementation complexity makes it easier to perform security audits on implementations. Reducing implementation complexity also helps ensure better interoperability and more software library implementations, as the barrier to creating a fully conforming implementation is greatly reduced.

The Web Payments group believes that new digital signature and encryption schemes will have to be updated every 5-7 years. It is better to delay the decision to switch to another primary algorithm as long as as possible (and as long as it is safe to do so). Delaying the cryptographic algorithm decision ensures that the group will be able to make a more educated decision than attempting to predict which cryptographic algorithms may be the successors to currently deployed algorithms.

Bottom line: The Secure Messaging specification utilizes a much simpler approach than the JWA specification while supporting the same level of algorithm agility.

JSON Web Key vs. Secure Messaging

The JSON Web Key (JWK) specification details a data structure that is capable of representing one or more cryptographic keys. If you need to express one of the many types of cryptographic key types in use today, JWK details how you do that in an standard way. A typical RSA public key looks like the following using the JWK specification:

{
  "keys": [{
    "kty":"RSA",
    "n": "0vx7agoe ... DKgw",
    "e":"AQAB",
    "alg":"RS256",
    "kid":"2011-04-29"
  }]
}

A similar RSA public key looks like the following using the Secure Messaging specification:

{
  "@context": "https://w3id.org/security/v1",
  "@id": "https://example.com/i/bob/keys/1",
  "@type": "Key",
  "owner": "https://example.com/i/bob",
  "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBG0BA...OClDQAB\n-----END PUBLIC KEY-----\n"
}

There are a number of differences between the two key formats. Specifically:

  1. The JWK format expresses key information by specifying the key parameters directly. The Secure Messaging format places all of the key parameters into a PEM-encoded blob. This approach was taken because it is easier for developers to use the PEM data without introducing errors. Since most Web developers do not understand what variables like dq (the second factor Chinese Remainder Theorem exponent parameter) or d (the Elliptic Curve private key parameter) are, the likelihood of transporting and publishing that sort of data without error is lower than placing all parameters in an opaque blob of information that has a clear beginning and end (-----BEGIN PUBLIC KEY-----, and --- END PUBLIC KEY ---)
  2. In the general case, the Secure Messaging key format assigns URL identifiers to keys and publishes them on the Web as JSON-LD, and optionally as RDFa. This means that public key information is discoverable and human and machine-readable by default, which means that all of the key parameters can be read from the Web. The JWK mechanism does assign a key ID to keys, but does not require that they are published to the Web if they are to be used in message exchanges. The JWK specification could be extended to enable this, but by default, doesn’t provide this functionality.
  3. The Secure Messaging format is also capable of specifying an identity that owns the key, which allows a key to be tied to an identity and that identity to be used for thinks like Access Control to Web resources and REST APIs. The JWK format has no such mechanism outlined in the specification.

Bottom line: The Secure Messaging specification provides four major advantages over the JWK format: 1) the key information is expressed at a higher level, which makes it easier to work with for Web developers, 2) it allows key information to be discovered by deferencing the key ID, 3) the key information can be published (and extended) in a variety of Linked Data formats, and 4) it provides the ability to assign ownership information to keys.

JSON Web Tokens vs. Secure Messaging

The JSON Web Tokens (JWT) specification defines a way of representing claims such as “Bob was born on November 15th, 1984″. These claims are digitally signed and/or encrypted using either the JSON Web Signature (JWS) or JSON Web Encryption (JWE) specifications. Here is an example of a JWT document:

{
  "iss": "joe",
  "exp": 1300819380,
  "http://example.com/is_root": true
}

JWT documents contain keys that are public, such as iss and exp above, and keys that are private (which could conflict with keys from the JWT specification). The data format is fairly free-form, meaning that any data can be placed inside a JWT Claims Set like the one above.

Since the Secure Messaging specification utilizes JSON-LD for its data expression mechanism, it takes a fundamentally different approach. There are no headers or claims sets in the Secure Messaging specification, just data. For example, the data below is effectively a JWT claims set expressed in JSON-LD:

{
  "@context": "http://json-ld.org/contexts/person",
  "@type": "Person",
  "name": "Manu Sporny",
  "gender": "male",
  "homepage": "http://manu.sporny.org/"
}

Note that there are no keywords specific to the Secure Messaging specification, just keys that are mapped to URLs (to prevent collisions) and data. In JSON-LD, these keys and data are machine-interpretable in a standards-compliant manner (unlike JWT data), and can be merged with other data sources without the danger of data being overwritten or colliding with other application data.

Bottom line: The Secure Messaging specifications use of a native Linked Data format removes the requirement for a specification like JWT. As far as the Secure Messaging specification is concerned, there is just data, which you can then digitally sign and encrypt. This makes the data easier to work with for Web developers as they can continue to use their application data as-is instead of attempting to restructure it into a JWT.

JSON Web Encryption vs. Secure Messaging

The JSON Web Encryption (JWE) specification defines a way to express encrypted content using JSON-based data structures. Basically, if you want to encrypt JSON data so that only the intended receiver can read the data, this specification tells you how to do it in an interoperable way. A JWE-encrypted message looks like this:

{
  "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
  "unprotected": {"jku": "https://server.example.com/keys.jwks"},
  "recipients": [{
    "header": {
      "alg":"RSA1_5"
        "kid":"2011-04-29",
        "enc":"A128CBC-HS256",
        "jku":"https://server.example.com/keys.jwks"
      },
      "encrypted_key": "UGhIOgu ... MR4gp_A"
    }]
  }],
  "iv": "AxY8DCtDaGlsbGljb3RoZQ",
  "ciphertext": "KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
  "tag": "Mz-VPPyU4RlcuYv1IwIvzw"
}

To decrypt this information, an application would retrieve the private key associated with the recipients[0].header, and then decrypt the encrypted_key. Using the decrypted encrypted_key value, it would then use the iv to decrypt the protected header. Using the algorithm provided in the protected header, it would then use the decrypted encrypted_key, iv, the algorithm specified in the protected header, and the ciphertext to retrieve the original message as a result.

For comparison purposes, a Secure Messaging encrypted message looks like this:

{
  "@context": "https://w3id.org/security/v1",
  "@type": "EncryptedMessage2012",
  "data": "VTJGc2RH ... Fb009Cg==",
  "encryptionKey": "uATte ... HExjXQE=",
  "iv": "vcDU1eWTy8vVGhNOszREhSblFVqVnGpBUm0zMTRmcWtMrRX==",
  "publicKey": "https://example.com/people/john/keys/23"
}   

To decrypt this information, an application would use the private key associated with the publicKey to decrypt the encryptionKey and iv. It would then use the decrypted encryptionKey and iv to decrypt the value in data, retrieving the original message as a result.

The Secure Messaging encryption protocol is simpler than the JWE protocol for three major reasons:

  1. The @type of the message, EncryptedMessage2012, encapsulates all of the cryptographic algorithm information in a machine-readable way (that can also be hard-coded in implementations). The JWE specification utilizes the protected field to express the same sort of information, which is allowed to get far more complicated than the Secure Messaging equivalent, leading to more complexity.
  2. Key information is expressed in one entry, the publicKey entry, which is a link to a machine-readable document that can express not only the public key information, but who owns the key, the name of the key, creation and revocation dates for the key, as well as a number of other Linked Data values that result in a full-fledged Web-based PKI system. Not only is Secure Messaging encryption simpler than JWE, but it also enables many more types of extensibility.
  3. The key data is expressed in a PEM-encoded format, which is expressed as a base-64 encoded blob of information. This approach was taken because it is easier for developers to use the data without introducing errors. Since most Web developers do not understand what variables like dq (the second factor Chinese Remainder Theorem exponent parameter) or d (the Elliptic Curve private key parameter) are, the likelihood of transporting and publishing that sort of data without error is lower than placing all parameters in an opaque blob of information that has a clear beginning and end (-----BEGIN PUBLIC KEY-----, and --- END PUBLIC KEY ---).

The rest of the entries in the JSON are typically required for the encryption method selected to secure the message. There is not a great deal of difference between the two specifications when it comes to the parameters that are needed for the encryption algorithm.

Bottom line: The major difference between the Secure Messaging and JWE specification has to do with how the encryption parameters are specified as well as how many of them there can be. The Secure Messaging specification expresses only one encryption mechanism and outlines the algorithms and keys external to the message, which leads to a reduction in complexity. The JWE specification allows many more types of encryption schemes to be used, at the expense of added complexity.

JSON Web Signatures vs. Secure Messaging

The JSON Web Signatures (JWS) specification defines a way to digitally sign JSON data structures. If your application needs to be able to verify the creator of a JSON data structure, you can use this specification to do so. A JWS digital signature looks like the following:

{
  "payload": "eyJpc ... VlfQ",
  "signatures":[{
    "protected":"eyJhbGciOiJSUzI1NiJ9",
    "header": {
      "kid":"2010-12-29"
    },
    "signature": "cC4hi ... 77Rw"
  }]
}

For the purposes of comparison, a Secure Messaging message and signature looks like the following:

{
  "@context": ["https://w3id.org/security/v1", "http://json-ld.org/contexts/person"]
  "@type": "Person",
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "signature":
  {
    "@type": "GraphSignature2012",
    "creator": "http://example.org/manu/keys/5",
    "created": "2013-08-04T17:39:53Z",
    "signatureValue": "OGQzN ... IyZTk="
  }
}

There are a number of stark differences between the two specifications when it comes to digital signatures:

  1. The Secure Messaging specification does not need to base-64 encode the payload being signed. This makes it easier for a developer to see (and work with) the data that was digitally signed. Debugging signed messages is also simplified as special tools to decode the payload are unnecessary.
  2. The Secure Messaging specification does not require any header parameters for the payload, which reduces the number of things that can go wrong when verifying digitally signed messages. One could argue that this also reduces flexibility. The counter-argument is that different signature schemes can always be switched in by just changing the @type of the signature.
  3. The signer’s public key is available via a URL. This means that, in general, all Secure Messaging signatures can be verified by dereferencing the creator URL and utilizing the published key data to verify the signature.
  4. The Secure Messaging specification depends on a normalization algorithm that is applied to the message. This algorithm is non-trivial, typically implemented behind a JSON-LD library .normalize() method call. JWS does not require data normalization. The trade-off is simplicity at the expense of requiring your data to always be encapsulated in the message. For example, the Secure Messaging specification is capable of pointing to a digital signature expressed in RDFa on a website using a URL. An application can then dereference that URL, convert the data to JSON-LD, and verify the digital signature. This mechanism is useful, for example, when you want to publish items for sale along with their prices on a Web page in a machine-readable way. This sort of use case is not achievable with the JWS specification. All data is required to be in the message. In other words, Secure Messaging performs a signature on information that could exist on the Web where the JWS specification performs a signature on a string of text in a message.
  5. The JWS mechanism enables HMAC-based signatures while the Secure Messaging mechanism avoids the use of HMAC altogether, taking the position that shared secrets are typically a bad practice.

Bottom line: The Secure Messaging specification does not need to encode its payloads, but does require a rather complex normalization algorithm. It supports discovery of signature key data so that signatures can be verified using standard Web protocols. The JWS specification is more flexible from an algorithmic standpoint and simpler from a signature verification standpoint. The downside is that the only data input format must be from the message itself and can’t be from an external Linked Data source, like an HTML+RDFa web page listing items for sale.

Conclusion

The Secure Messaging and JOSE designs, while attempting to achieve the same basic goals, deviate in the approaches taken to accomplish those goals. The Secure Messaging specification leverages more of the Web with its use of a Linked Data format and URLs for identifying and verifying identity and keys. It also attempts to encapsulate a single best practice that will work for the vast majority of Web applications in use today. The JOSE specifications are more flexible in the type of cryptographic algorithms that can be used which results in more low-level primitives used in the protocol, increasing complexity for developers that must create interoperable JOSE-based applications.

From a specification size standpoint, the JOSE specs weigh in at 225 pages, the Secure Messaging specification weighs in at around 20 pages. This is rarely a good way to compare specifications, and doesn’t always result in an apples to apples comparison. It does, however, give a general idea of the amount of text required to explain the details of each approach, and thus a ballpark idea of the complexity associated with each specification. Like all specifications, picking one depends on the use cases that an application is attempting to support. The goal with the Secure Messaging specification is that it will be good enough for 95% of Web developers out there, and for the remaining 5%, there is the JOSE stack.

9 Comments

Got something to say? Feel free, I want to hear from you! Leave a Comment

  1. Kumar McMillan says:

    I am still a little uneasy at how Secure Messaging describes only one algorithm for signing/encryption. What if someone decides they want to support a different encryption scheme but they cannot get consensus on it? Are they out of luck or could they make a custom context (or something) to support their own algorithm in their own system? If there is consensus on a new algorithm then how do existing systems transition to the new algorithm? Can messages with the old algorithm pass through a new system?

    I like how JSON-LD uses URLs to define a context. You mention that because of this there is no need to define JWT claims (issued time, expiration time, etc). Is this because you would just define a custom context with parameters like expirationTime? I like how JSON-LD results in unambiguous JSON structures and how it has localization support.

    As for unencoded JSON vs. base64 encoded JWTs, the non-trivial normalization algorithm worries me a bit. Has this been a practical issue in any of the JSON-LD libraries yet? When I see key sorting I get a little nervous since non-ascii sorting (for example) may not always work the same across platforms. It is nice to glance at a log and read an input string rather than have to base64 decode it though. OTOH, most HTTP data is already base64 encoded and our technology stacks (like web servers) hide that from us in logs and such.

    Thanks for writing up a detailed comparison.

    • ManuSporny says: (Author)

      I am still a little uneasy at how Secure Messaging describes only one algorithm for signing/encryption. What if someone decides they want to support a different encryption scheme but they cannot get consensus on it?

      They can still implement it among agents that want to support the new encryption scheme. For example, if Elliptic Curve Crypto is desired, the digital signature can change from this:

      {
        ...
        "signature":
        {
          "@type": "GraphSignature2012",
          "creator": "http://manu.sporny.org/keys/5",
          "signatureValue": "OGQzNG ... IyZTk="
        }
      }
      

      to this:

      {
        ...
        "signature":
        {
          "@type": "EccGraphSignature2013",
          "creator": "http://manu.sporny.org/keys/6",
          "signatureValue": "OGQzNG ... IyZTk="
        }
      }
      

      Note that the only change is to the type of the signature, all other data remains the same.

      Are they out of luck or could they make a custom context (or something) to support their own algorithm in their own system?

      They just make a custom context. Really, they just need to add one entry to the context. They could do it like this:

      {
         "@context": [
           "https://w3id.org/security/v1",
           { "EccGraphSignature2013": "https://w3id.org/mysignatures/v1#ecc" }
         ],
         ...
      }
      

      The code above layers one more term on top of all of the ones provided by the Security Vocabulary. They could do that, or they could do something like this:

      {
         "@context": "https://w3id.org/foo-application/v1",
         ...
      }
      

      The document located at the context URL above would declare the EccGraphSignature2013 term.

      If there is consensus on a new algorithm then how do existing systems transition to the new algorithm? Can messages with the old algorithm pass through a new system?

      Existing systems would add support for the new algorithm while not removing the code path for the old algorithm. Messages using the old algorithm would continue to be supported while the transition is occurring. At some point, it will become too much of a risk for systems to support the old algorithm. Typically, a move to the new algorithm was
      triggered by the discovery of a security vulnerability in the old algorithm.

      We could say that support for the old algorithm would have a hard sunset date, but approaching technical upgrades based on sunset provisions rarely happen on the timeline that a Working Group would like to see. So, the fallback is to depend on the market to decide when the risk of using the old algorithm isn’t worth the cost of the algorithm being
      compromised. For example, a PaySwarm Authority has a damn good reason to care about the soundness of the digital signature algorithm because if it’s broken, then money starts being sucked out of the system without the owner’s consent via forged transactions.

      I like how JSON-LD uses URLs to define a context. You mention that because of this there is no need to define JWT claims (issued time, expiration time, etc). Is this because you would just define a custom context with parameters like expirationTime?

      Yes. With Secure Messaging and JSON-LD, it’s all just machine-readable data that is signed. There’s no concept of a claim because everything in the data is a claim of some sort or another (it’s just a list of facts… of information).

      If you want an expiration time, then you include such a thing in your context and use it in your data. If a vendor needs to declare the number of copies you purchased for a 3D-printable file, then they declare that in their context and they use it in the data. There’s no need for a specification to declare exactly what a Claim Set consists of.

      I like how JSON-LD results in unambiguous JSON structures and how it has localization support.

      +1

      For those that don’t know the benefits of these aspects of JSON-LD:

      Unambiguous JSON structures allow you to write software that can work with fuzziness. That is, while the application won’t be able to understand the entire data blob, it can still understand enough of the structure to process it. So, take the case where a 3D printable file is being sold. The asset can describe the dimensions of the file, printers
      that it’s compatible with, materials that can be used to print the asset, curing time, etc. None of this information is probably going to be used by the payment processor, however, the information will be preserved and can be used by the 3D printing software.

      For example, PaySwarm can understand enough about the financial and licensing aspect of it to perform a sale of it. The printing software can then use the digital receipt (which contains the asset and licensing description) to send the print job to the proper printer.

      Localization support allows you to create one asset that is multilingual capable by default. So, say you’re creating a Web App for sale. Using JSON-LD, you can include the English, French, Japanese, Mandarin, Tamil, and Afrikaans title and description in a single asset description in a standard way.

      As for unencoded JSON vs. base64 encoded JWTs, the non-trivial normalization algorithm worries me a bit. Has this been a practical issue in any of the JSON-LD libraries yet?

      Nope, not yet. There have been 6 different implementations of the normalization algorithm over the years (at different points in its development process). Nobody has really complained about it… in fact, I think we’re the ones that typically warn people about it because it’s an easy part of the spec to miss.

      The normalization algorithm is much like SSL and TLS. That is, all you need is an implementation in your language of choice and you never have to know or care how it works.

      At present, I think we have production-quality JavaScript, PHP, and Python implementations of the JSON-LD normalization algorithm. It has also been implemented in C++ at one point, but we abandoned that implementation as no one seemed to be using it.

      When I see key sorting I get a little nervous since non-ascii sorting (for example) may not always work the same across platforms.

      The sorting is done on UTF-8 strings. Are you saying that UTF-8 sorting doesn’t work the same across platforms?

      It is nice to glance at a log and read an input string rather than have to base64 decode it though. OTOH, most HTTP data is already base64 encoded and our technology stacks (like web servers) hide that from us in logs and such.

      While that’s true, when you’re writing software using JWS/JWT/Secure Messaging, you will inevitably have a problem that you have to debug that won’t be in any log.

      Printing out the object you’re working with is much easier if you don’t have to then also base-64 decode strings (that may or may not be binary data, as is the case with JWT). In Secure Messaging and JSON-LD, we only base64 encode binary data… all other data remains as cleartext (and thus easily debuggable).

  2. Zachary Lym says:

    While I understand the algorithmic agility argument, the safety engineer in me demands dual-protection and this is the only place where I see the SM spec falling short. SHA-3 is just around the corner and I think it should be required as well. SHA-1 and MD5 were born from in the early days of encryption and rather closely related, but requiring BOTH has made our legacy infrastructure more secure. SHA-2 and SHA-3 are very, very different from each other and a government being capable of breaking both in such a way that they could have real-world exploits requires a serious stretch of the imagination.

    Ciphers are another matter, as requiring dual encryption would severely slow down communication. However, the standard should require at least one additional cipher be available should a vulnerability is found in AES.

    The NSA leaks are proof that switching out algorithms isn’t good enough, we need at least two secure alternatives to protect us when one fails.

    “At present, I think we have production-quality JavaScript, PHP, and Python implementations of the JSON-LD normalization algorithm. It has also been implemented in C++ at one point, but we abandoned that implementation as no one seemed to be using it.”

    A Haxe implementation would get C++, Java, C#, JavaScript, PHP, and Python all from a single codebase.

    • ManuSporny says: (Author)

      re: Algorithm Agility, you make a good point and that’s easy enough to do. We just need to spec it in the security vocabulary and ensure the implementations can handle it. We’ve gotten enough push-back on the “single algorithm set” feature that we’re probably going to have GraphSignature2012 and GraphSignature2014 signature types. I would imagine that in practice, we’d deprecate GraphSignature2012 in 2016 and introduce a GraphSignature2016 instead.

      Re: HaXe, interesting. Know anyone that knows HaXe and has some spare time that could do an implementation? :)

  3. Zachary Lym says:

    Are there any JS libraries for this? “Secure Messaging” is un-googleable. I know the JSON-LD libraries exist, but I would prefer to just define params for a function call rather than build a record from scratch.

Trackbacks for this post

  1. Technical Analysis of 2012 MozPay API Message Format | The Beautiful, Tormented Machine
  2. The Marathonic Dawn of Web Payments | The Beautiful, Tormented Machine

Leave a Comment

Let us know your thoughts on this post but remember to play nicely folks!