[Cryptographic Message Syntax (CMS)] Web API or Library?

[dadrian]

I don't fully understand the reasoning the CMS needs to be a browser API, rather than an application-layer library. I understand that the CMS RFC is not very good, and ambiguous, and that implementations are often incompatible or buggy. However, this seems like all the more reason that a browser should not commit to keeping an implementation that will have compatibility issues right out of the box.

This reminds me of when the Go stdlib attempted to maintain a PGP implementation, and ultimately removed it, because it was not particularly compatible, required bringing in a large amount of code and algorithms that were otherwise a bad idea, and the general consensus was that new applications should not use PGP.

Similarly, the main usage for CMS is S/MIME and nothing else. No one is building new applications with CMS, and should not.

If there are things that are missing in Web Crypto to make implementing a CMS API in WASM or Typescript better, we should add them. However, I'm not sure that the browser offering a CMS API make sense, versus S/MIME applications shipping their own implementation.

Could you expand on the rationale? I suspect the actual reason is "we would like to share a CMS implementation that already exists in the underlying cryptographic library used with the browser".

[dadrian]

Also, from a very practical standpoint, the CMS code was some of the first code that BoringSSL removed from OpenSSL when it was created.

[jonchoukroun]

We will update the proposal to clarify our rationale for adding CMS as a browser API. Primarily our concern is what @dadrian mentioned, that existing implementations can be incompatible or buggy. However we think that limiting CMS implementations to those bundled with browsers, rather than requiring all applications to choose their own, will reduce those incompatibilities. We’ve been holding encrypted email discussions in a working group with many other email providers, who would like to move forward with S/MIME for encryption. So while CMS’s use case is mostly only S/MIME, it is a large use case that we expect to see grow. We hope that providing a standardized API will simplify the implementation effort for these email providers.

[twiss]

If there are things that are missing in Web Crypto to make implementing a CMS API in WASM or Typescript better, we should add them.

FWIW, I also think that even if we do add an API for CMS, Web Crypto should still be updated to add the required cryptographic algorithms, otherwise we would end up in a situation where calling the CMS API could be the most efficient way to run those algorithms, which would be unfortunate. AFAIK, ChaCha20-Poly1305 is the only one missing, so I've proposed adding it here: https://twiss.github.io/webcrypto-modern-algos/#chacha20-poly1305.

Beyond that, while I think it's actually a good idea to add a more high-level API to Web Crypto, I would worry if the only high-level API we add is for CMS, as it might push people to use that when other choices might be more appropriate. Tangentially, I know there are ideas floating around to add APIs for HPKE (RFC 9180) and MLS (RFC 9420) to the web; it might be good to do that before adding CMS, so that "better" options are available, at least. (Neither is a 1:1 replacement to what CMS does, of course - but they could still fill some of the use cases.)

[jonchoukroun]

After discussing with other industry colleagues, we’ve decided not to pursue standardization of a CMS API in Web Crypto. However we may pursue an alternative, like a JS or WASM library.

[marcoscaceres]

Thanks everyone for the really valuable input on this.