#1190: Incubation: Cryptography usage in Web Standards

Visit on Github

Opened Feb 3, 2026

Explainer

https://www.w3.org/TR/2026/DNOTE-security-guidelines-cryptography-20260129/

The explainer

Where and by whom is the work is being done?

Feedback so far

There's some review in the issue tracker that is worth looking at. https://github.com/w3c/security-guidelines-cryptography/issues/15 in particular has some good feedback.

You should also know that...

(Note that I didn't know how to classify this request. The forms don't really fit this, so I've lied: this doesn't really include the necessary items from the explainer explainer.)

After looking at this document personally, I think that the TAG should take a serious and critical look at this document. Focus on high level goals and whether this document is addressing those goals. To be clear, the purpose of this guide is presently unclear, but there is serious risk of harm out of this. If I were to infer a goal, it might be to instill confidence in people about their use of cryptography, which would likely be unwise.

To quote a recent article:

In fact, ability and motive may even be negatively correlated. The kind of person who has the ability to release a plague is probably highly educated: likely a PhD in molecular biology, and a particularly resourceful one, with a promising career, a stable and disciplined personality, and a lot to lose. This kind of person is unlikely to be interested in killing a huge number of people for no benefit to themselves and at great risk to their own future—they would need to be motivated by pure malice, intense grievance, or instability. -- Dario Amodei, The Adolescence of Technology

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1190

Discussions

Log in to see TAG-private discussions.

Discussed Feb 2, 2026 (See Github)

Lola: Martin has opened an issue to look at a document regarding crypto in web standards, and Martin has concerns. Think we should assign Martin, anybody else interested? Just to be clear, purpose is to check if the goals are good, and the document meets these goals.

Ehsan: Happy to support.

Yves: Is Martin available for this, given his term ended?

Lola: Right. Let’s assign Ehsan and me.

Discussed Feb 9, 2026 (See Github)

Ehsan: Not finished yet, but started looking into it.

Lola: That was the issue that Martin opened?

Ehsan: Yes.

Lola: If someone else wants to join, feel free to assign yourselves. We’re not reviewing a specific design review, that’s just work happening inside W3C that he thinks we should be aware of.

Jeffrey: Basically a design principle, asked Google security people to have a look.

Lola: Martin was concerned. Not that we should be biased, but be aware of that.

Ehsan: Share Martin’s impression.

Comment by @lolaodelola Feb 13, 2026 (See Github)

@martinthomson thanks for putting this on our radar.

To be clear, the purpose of this guide is presently unclear, but there is serious risk of harm out of this.

What specific harms do you foresee coming from this?

Comment by @Solix45456767 Feb 13, 2026 (See Github)

{ "comment": { "topic": "Incubation: Cryptography usage in Web Standards", "best_practice": "Ensure all cryptographic implementations follow established standards like NIST guidelines and use well-vetted libraries rather than custom implementations, while maintaining clear documentation of which algorithms are used and their security properties. Always provide secure key management practices and deprecation timelines for older cryptographic methods to help developers migrate safely.", "question": "Have you considered including guidance on post-quantum cryptography readiness, given the evolving threat landscape? What mechanisms will be in place to update these standards as cryptographic threats evolve?" } }

Comment by @martinthomson Feb 15, 2026 (See Github)

I found some of the advice misleading, both in detail and in structure. A source of inaccurate information on cryptography that purports to be reliable, from a trusted/trustworthy source might lead people to act on a false belief of accuracy. Problems in the deployment of cryptography tend to be more serious than other problems.

As an example of the structural problems, there is no mention of the tools that we recommend most people use. Things like TLS and SSH (and more recently, MLS) are at a level that the document fails to engage with. The relatively low level of the things that are covered is usually reserved for trained practitioners, who are able to reason about cryptographic properties like IND-CCA or EUF-CMA or discuss the value of FO or Feistel or Fiat-Shamir. These are all basics on the same level as the material in the document, but not given any mention.

At the level that this document operates, a brief note suggesting that people use composed protocols (TLS, SSH, etc..) rather than try to use cryptographic primitives would be far more useful. If the goal is to help give a grounding in the use of those tools, I'd suggest finding a good school. These are not skills that can be taught by a short document like this.

Discussed Feb 16, 2026 (See Github)

Lola: Martin has replied to my question. Wanted Martin to be explicit in his concerns, found the original concern a bit vague. Haven’t read over the response. Heather and I have commented in the private-brainstorm, and I have two questions: 1) Hadley, you mentioned this is not… oh, Lola and Martin have replied? Does Martin still have access to the TAG org?

Yves: Yes, and it will be removed after the next F2F. Usually, we keep departing members until the next F2F.

Lola: How can we continue the conversation when he leaves the org?

Yves: There is still the Slack.

Heather: Read through the doc in question. What I saw is that it is good in defining terms, but not in providing direction. Think some of the internal comments regarding the specific algorithms, and I wanted to point out that I think the authentication definition is wrong.

Lola: Did you have a look, Ehsan?

Ehsan: I have, working on a comment. Overall, my feeling is that this could be good start, but it’s just a start. Doesn’t go further than that. Many of the things are available in the textbook as well. Is this repetition really needed? Mainly talking about concepts. Language that only cryptographers understand may not be helpful for the audience.

Lola: Think they need to pick an audience. Don’t think it’s appropriate for application developers, if this means web application developers. I think it could be appropriate for spec authors or standards peope creating standards and specifications.

… However, the document came to us not from the group, and it seems it isn’t finished. So, the group didn’t ask us, it isn’t finished, I don’t think we have to say something here. I think they are now aware of the things that we were pointing out.

Hadley: There might still be some value in pointing them out anyway.

Lola: Would a document like this usually pass our table, like a design review would do?

Hadley: Probably not, it would either come in via the Horizontal Review process or the Blink launch process. I think it’s totally fine for us if we have opinions.

Ehsan: Don’t think it’s future-proof; things like zero-knowledge proofs, differential privacy, are missing.

Heather: Agree.

Lola: Based on this discussion, I think we should open some issues on their repo (https://github.com/w3c/security-guidelines-cryptography/issues). There are a few different problem statements that we’ve identified with the document. We should convert each of those problem statements into issues. We should draft them in the brainstorming doc. Ehsan, if you are ready, could you post your review there?

Ehsan: Sure.

Lola: From my perspective, this could be a useful document for spec authors. They should clarify the audience.

Hadley: Process-wise: In the past, we asked whoever opened the review if they wanted feedback. Found we had a hard time keeping up what has been posted in other issues. Over time, we decided to keep the discussion in our repo. Do we know them?

Lola: We do know Simone. They have examples of other people opening issues. Seems like there is a process? But again, they haven’t asked us.

Yves: Yes, Simone is the staff contact.

Hadley: Two suggestions: 1) We could send a link to our GitHub issue to someone so that they are aware of it. 2) It would be helpful to have a summary of all GitHub issues that are of our concern, regardless of where they are.

… Would prefer to have that in the public-facing issue. Sometimes, people go back to previous TAG discussions and have a look at the resolution. If there is no comment that clearly lines out why we have decided like this, people may come to a wrong conclusion.

Lola: Think the first step is that we should draft a closing comment-ish comment, send a link to the group so that they are aware of it, and if they want to do something with that, they can.

(Agreement.)

Discussed Feb 23, 2026 (See Github)

Lola: Ehsan put in some comments and covers a lot. IIRC Hadley mentioned we could open this as an issue on their repo, but that'd be hard for us to track - but they've not asked us to review this anyway. So what do we want to do with these comments?

Hadley: It'd be helpful for us to keep a copy of our comment in our repo, and open a blanket issue in their repo to point to the TAG feedback. They can consider it and do what they think right with it.

Whoever opens the issue in their repo should be extra kind, since they won't be expecting our review.

Lola: Heather: does Ehsan's comment cover your concerns too?

Heather: yes.

Lola: I like Ehsan's comment - want to include some editorial issues. Ehsan: Once you've posted your comment, please open an issue in their repo, and point them to it.