私のHTTPSサイトから昔ながらの証明書が無くなった理由とは？

＞So, yes, instead of saying that ”e” equals ”65537”, you’re saying that ”e” equals ”AQAB”. Aren’t you glad you did those extra steps?Oh JSON.For those unfamiliar with the reason here, it’s that JSON parsers cannot be relied upon to treat numbers properly. Is 4723476276172647362476274672164762476438 a valid JSON number? Yes, of course it is. What will a JSON parser due with it? Silently truncate it to a 64-bit or 63-bit integer, or a float, probably or if you’re very lucky emit an error (a good JSON decoder written in a sane language like Common Lisp would of course just return the number, but few of us are so lucky).So the only way to reliably get large integers into and out of JSON is to encode them as something else. Base64-encoded big-endian bytes is not a terrible choice. Silently doing the wrong thing is the root of many security errors, so it not wrong to treat every number in the protocol this way. Of course, then one loses the readability of JSON.JSON is better than XML, but it really isn’t great. Canonical S-expressions would have been far preferable, but for whatever reason the world didn’t go that way.
＞つまり、「e」は「65537」と言う代わりに、「e」は「AQAB」と言ってるわけだね。この余計な手順踏んで良かったね？ああ、JSONね。
なぜこんなことになってるか知らない人のために説明すると、JSONパーサーは数値をちゃんと扱ってくれないんだよね。たとえば、4723476276172647362476274672164762476438みたいなすごく長い数字、これは有効なJSONの数値かな？もちろんそうだよ。じゃあJSONパーサーはこれどうする？たぶん、黙って64ビットとか63ビットの整数に切り詰めたり、浮動小数点数にしちゃうんだ。運が良ければエラーを出してくれるかもね（Common Lispみたいなちゃんとした言語で書かれた良いJSONデコーダーなら、もちろんそのまま数値を返してくれるけど、そんな幸運な人は少ないんだ）。
だから、大きな整数をJSONで確実に出し入れする唯一の方法は、何か別の形式でエンコードすることなんだ。Base64エンコードされたビッグエンディアンのバイト列っていうのは、悪くない選択肢だね。黙って間違った処理をするのは多くのセキュリティエラーの元凶だから、プロトコル内の全ての数値をこうやって扱うのは間違いじゃない。もちろん、そうするとJSONの読みやすさは失われるけどね。
JSONはXMLよりマシだけど、正直すごく良いわけじゃないよ。Canonical S-expressionsの方がずっと良かったんだけど、なぜか世の中はそっちを選ばなかったんだよね。

＞Canonical S-expressions would have been far preferable, but for whatever reason the world didn’t go that way.
＞Canonical S-expressionsの方がずっと良かったんだけど、なぜか世の中はそっちを選ばなかったんだよね。
JSONが勝った理由が分からないのは、意図的に鈍感になってる気がするな。JSONはほとんどのデータで手書きしたり編集したり読むのが簡単なんだ。Canonical S-expressionsは読むのがそんなに簡単じゃないし、手書きするのはずっと大変だよ。全てのアトムに長さをプレフィックスとしてつけなきゃいけないから、手書きがすごく面倒くさいんだ。手で編集したいJSONオブジェクトがあったら、ただ入力するだけ…Canonical S-expressionの場合は、入力したり削除したりしてる文字数を数えて、プレフィックスを更新しなきゃいけないんだ。
手で生成、読み込み、編集できる能力が重要じゃないって思うかもしれないけど、それがJSONが結局勝った大きな理由だとかなり確信してるよ。
そうそう、RubyのJSONパーサーはあの大きな数値をちゃんと扱ってくれるよ。

＞I feel like not understanding why JSON won out is being intentionally obtuse.
＞JSONが勝った理由が分からないのは、意図的に鈍感になってる気がするな。
僕のコメントは代替案をゴリ押しする場所じゃなくて、JSONへの不満を言う場所だって感じてたんだ。でも、君がそれを持ち出したからね。
＞JSON can easily be hand written, edited, and read for most data.
＞JSONはほとんどのデータで手書きしたり編集したり読むのが簡単なんだ。
Canonical S-expressionsだってそうだよ！
＞Canonical S-expressions are not as easy to read and much harder to write by hand; having to prefix every atom with a length makes is very tedious to write by hand.
＞Canonical S-expressionsは読むのがそんなに簡単じゃないし、手書きするのはずっと大変だよ。全てのアトムに長さをプレフィックスとしてつけなきゃいけないから、手書きがすごく面倒くさいんだ。
だからadvanced representationがあるんだよ。僕はこれの方が：
(urn:ietf:params:acme:error:malformed
(detail ”Some of the identifiers requested were rejected”)
(subproblems ((urn:ietf:params:acme:error:malformed
(detail ”Invalid underscore in DNS name ¥”_example.org¥””)
(identifier (dns _example.org)))
(urn:ietf:params:acme:error:rejectedIdentifier
(detail ”This CA will not issue for ¥”example.net¥””)
(identifier (dns example.net))))))
RFC 8555の最初のJSON（これね）：
{
”type”: ”urn:ietf:params:acme:error:malformed”,
”detail”: ”Some of the identifiers requested were rejected”,
”subproblems”: [
{
”type”: ”urn:ietf:params:acme:error:malformed”,
”detail”: ”Invalid underscore in DNS name ¥”_example.org¥””,
”identifier”: {
”type”: ”dns”,
”value”: ”_example.org”
}
},
{
”type”: ”urn:ietf:params:acme:error:rejectedIdentifier”,
”detail”: ”This CA will not issue for ¥”example.net¥””,
”identifier”: {
”type”: ”dns”,
”value”: ”example.net”
}
}
]
}
よりもずっと読みやすいと思うよ。
＞for an Canonical S-expression, you have to count how many characters you are typing/deleting, and then update the prefix.
＞Canonical S-expressionの場合、入力したり削除したりしてる文字数を数えて、プレフィックスを更新しなきゃいけないんだ。
見た通り、そんなことする必要ないんだよ。

IEEE754 double precision floatで表現できない数値を確実に保存しない場合、JSONパーサーは技術的に標準に従ってないってことなのかな？パーサーが正しさよりパフォーマンスを優先して、数値にbignumsを使わないのは残念だね。

でも、数値を文字列で送る、”65537”ってする代わりに”AQAB”ってするのは何が悪いの？

君の例はs-expressionsを使ってるね、canonical s-expressionsじゃないよ。canonical s expressionsは基本的にバイナリフォーマットなんだ。各アトム／文字列は、文字列の10進数の長さとコロンでプレフィックスされてる。通常のs expressionsに対する利点は、空白を含む文字列をエスケープしたりクオートしたりする必要がないこと、そして与えられたデータ構造に対して可能な表現が一つしかないことだね。欠点は、人間が書いたり読んだりするのがずっと難しいこと。
s-expressionsとjsonについては、それぞれ長所短所があるよ。s-expressionsにはデータ自体に型情報をエンコードする方法がないから、特定の値が数値として扱われるべきか文字列として扱われるべきかを知るためにはスキーマが必要なんだ。そして、どちらがより読みやすいかは主観だね。
＞[1]：https://en.m.wikipedia.org/wiki/Canonical_S-expressions

RFC7159か8259を読んで絶望してみてよ。
＞This specification allows implementations to set limits on the range and precision of numbers accepted
＞この仕様は、実装が受け付ける数値の範囲と精度に制限を設定することを許可している
JSONはひどい相互運用性標準だよ。

僕が理解できないのは、君（や他の多くの人）がS-expressionパーサーが全く同じ問題を抱えないとどうして期待するのかってことだよ。

じゃあ、2すら保存できないJSONパーサーは技術的に準拠してるってこと？:(

＞Your example uses s-expressions, not canonical s-expressions.
＞君の例はs-expressionsを使ってるね、canonical s-expressionsじゃないよ。
僕はいつも’canonical S-expressions’をRivestのS-expressions提案（https://www.ietf.org/archive/id/draft-rivest-sexp-13.html）を指すのに使ってたんだ。この提案にはcanonical、basic transport ＆ advanced transportの表現があって、それらは全て互いに等価なんだ（つまり、全てadvanced transport表現は単一のcanonical表現を持つ）。どこで最初に見かけたか覚えてないけど、たぶんLispとかSchemeの他のS-expressionsと区別するためだったのかな？もしかしたら、代わりに’Rivest S-expressions’とか’SPKI S-expressions’って呼ぶべきかもしれないね。
＞S-expressions don’t have any way to encode type information in the data itself, you need a schema to know if a certain value should be treated as a number or a string.
＞s-expressionsにはデータ自体に型情報をエンコードする方法がないから、特定の値が数値として扱われるべきか文字列として扱われるべきかを知るためにはスキーマが必要なんだ。
JSONだってそうだよ、このスレッド全体がそれを示してる通り。これは他のデータ型にも当てはまるね。Rivest expressionはこういう風にできたかもしれないけど：
(date [iso8601]2025-05-24T12:37:21Z)
JSONはこれに固執してるんだ：
{
”date”: ”2025-05-24T12:37:21Z”
}
＞And it’s subjective which is more readable.
＞そして、どちらがより読みやすいかは主観だね。
本当に同意できないな。YAMLが存在する唯一の理由はJSONをより読みやすくするためだよ。限られた範囲で、テキストの画面内に多くのデータがあるほど良いんだ。JSONはpretty-printすると非常に冗長で、少量のデータを表現するのに画面いっぱいのテキストを占めるんだ—そしてpretty-printされてないと、メモリーダンプを読もうとしてるのに近いよ。
編集：2025年1月の提案へのリンクを更新したよ。

RivestのドラフトだとCanonical S-expressionsはトークンの前に長さが入るフォーマットだから、「Canonical」って言葉を提案全体に使うのは紛らわしいね。JSONみたいな形式がRivestのより人気出る理由はその辺にあるのかも。JSONは読み書きのフォーマットだけで、転送は別。名前も短くて発音しやすいし、指してるものが明確だ。JSONがSPKIより優れてると言いたいわけじゃなくて、Rivestの提案は野心がありすぎて現実の普及には合わないってこと。JSONの転送にはgzipとかMessagePackとか色々あるけど、単一の標準がないのが逆に重要じゃないってのも面白いね。全部まとめて定義しようとするのは関心の分離に違反してる感あるかもね。

それって「こうなったのはこういう理由だ」っていう後付けの説明みたいだね。｛”e” ： ”AQAB”｝と｛”e” ： 65537｝を比較するなら話はわかるけど、それが唯一の選択肢なわけじゃないし。JSONの｛”e” ： ”65537”｝はどんなJSONパーサーでも同じように読むよ。”65537”って文字列を数値にするのは”AQAB”を数値にするのと同じくらい簡単だし、絶対にあいまいさはない。JSでやるとして、結果の数値がdoubleの精度を超える可能性があるなら、どっちの方法でもデカい問題抱えることになるけどね。Cでlong longに入りきらない数を扱うのと同じ。それはJSONでどう表現するかに関係ないよ。

面白いことに、Javascript言語自体はもう何年もBigIntをサポートしてるんだよね。123nみたいに書ける。JSONも簡単に拡張できるはずなんだけど、そういう変更を決定できる標準化団体がないんだ。だからJSONはこのまま永遠に変わらないんだろうね。生きてる間に何か良い代替が出てきて、みんながそれに同意できるといいな。ついでに言うと、JSONにバイナリデータを埋め込む方法とか、日付の標準的な表現とか、コメントとか、Sum Typeのまともで一貫した表現、あとSetやMap（文字列以外のキーも）も欲しいな。Javascriptはネイティブでサポートしてるのにね。はぁ。

＞JSONがなんで勝ったか理解できないのは意図的に鈍感になってる気がする。JSONは手で簡単に書いたり編集したり読んだりできる。
君はJSONが成功した理由を理屈付けようと頑張りすぎてるよ。正直なところ、そんな複雑な理由じゃなくてずっとシンプル：あれは有効なJavascriptだったから。JavascriptのWebアプリはeval()一発でJSONをパースできたんだ。XMLみたいなデシリアライズの面倒さもないし、パーサーをインポートする必要もない。ファイルをフェッチして、eval()に渡せば終わり。それが真実だよ。

これ、大丈夫なの？
Python 3.13.3 （main， May 21 2025， 07：49：52） ［GCC 14．2．0］ on linux
Type ”help”， ”copyright”， ”credits” or ”license” for more
information．
＞＞＞ import json
＞＞＞

json．loads（’47234762761726473624762746721647624764380000000000000000000000000000000000000000000’）
47234762761726473624762746721647624764380000000000000000000000000000000000000000000
（とても大きな整数をJSONとして読み込めるPythonの例を見せてる）

PHPみたいな一部のパーサーは、65537っていう数値と”65537”っていう文字列を同じものとして扱うかもね。脆弱性の余地があるよ。

Canonical S-expressionsには数値がなくて、アトム（つまりバイト列）とリストだけだからだよ。だから、”34”っていうのを文字列の”34”として解釈するか、数値の34として解釈するか、はたまた別の値として解釈するかは、使ってるプロトコル次第なんだ。だいたいは10進数の数値だろうけどね。プログラミング言語のLispで使うS-expressionsには数値があるけど、Lispはbignumを持ってる。他の言語で書かれたLisp S-expressionsパーサーは、標準に準拠するならbignumをサポートする必要があるんだ。

JSONでbigintを扱う簡単な回避策はあるよ： https://github.com/GoogleChromeLabs/jsbi/issues/30#issuecomm…

Goだと数値を文字列としてロスレスにデコードできるよ（ https://pkg.go.dev/encoding/json#Numberjson.Numberは（ほとんど）僕の”お気に入り”のarbitrary decimalだね（半分冗談だけど）。 https://github.com/ncruces/decimal?tab=readme-ov-file#decima...S-expressionがここでどうしてベターなのか分からないな。arbitrary precision mathをやらないLISPsもあるし。

JSONには、最初から巨大なエコシステムがあったっていう大きな利点もあったんだ。見た目はイケてないし、ちょっと安全じゃなかったけど、あらゆるJavaScript実装が最初からJSONをパース・生成できたってのは、すごく大きな後押しになったね。たとえ世界一のフォーマットがあったとしても、これに勝つのは難しいよ。

JSONはテキスト形式で、数値の解釈は仕様の範囲外だよ。プラットフォーム間で使う時は、数値の“解釈”について同意しないとダメだね。じゃないと、同じデータが見れないよ。

もちろん、マップやセット、バイナリデータをエンコードできるけど、したくないんだ。JSONにはネイティブサポートがないのが事実。これらの機能を最初からネイティブにサポートするJSONライクなものが欲しいね。いちいちエンコード方法を考えたり、JacksonやSerdeやJavaScriptでハックしたりしたくないよ。

Common Lispはデフォルトでbigintを持ってるってことを言ってるんだと思うな。

そうだね、Pythonもarbitrary-precision arithmeticを持つ「正気な」言語のカテゴリーに入るよ。

＞ clearly refers to one thing
いいね、これJSONみたいだね。これJSON5？bigintサポート期待できる？エスケープ文字使える？

君にはそうかもね。僕には前者は密すぎ。JSONはインデントがあって見やすいし、リストとオブジェクトの区別もできるのがいい。でも、まあ、基本的にホモモルフィックだよね。{}と[]を()に変えるとか、キーやタイプの扱いが暗黙的か明示的かとか、ちょっと違うだけだし。

＞ Canonical S-expressions are not as easy to read and much harder to write by hand
そんなことしないよ。バイナリでマシンコードを読み書きするのと同じ。普通のS-expression（やアセンブリコード）を読み書きして、それをツール（アセンブラ/逆アセンブラ）でCanonical S-expression（やマシンコード）に変換するんだ。

JSONにオプションで型宣言があればいいのにって思うくらいシンプルで当然のことなのに、なんでまだないんだろ？ほとんどの場合いらないだろうけど、際どいケースでパーサーが間違った推測をするのを防げるのにね。少なくとも意味のあるエラーを出せるはず。

Let’s EncryptのSRE/infraチームの技術リードだけど、JSON Web Signaturesは扱いにくいフォーマットだし、ACME APIも結構頑張ってる。IETF標準や設計委員会の影響かもね。C言語のライブラリも大変。RFCも分かりにくいから、クライアントとドキュメントを作業中だよ。

＞JSON Web Signaturesは扱いにくいフォーマットだって？ASN.1、Kerberos、PKIの中にいる身からすると、JWSはそんなに”gnarly”じゃないな。オープンコードするのも簡単なくらい。JWSの何がそんなに扱いづらいんだ？JWTに問題があるのは確かだけどね。主に取得方法の標準がないことかな。