RFC の URL はどのドメインで貼るのが良いか | blog.jxck.io
Intro IETF の RFC は、いくつかの場所で同じものが公開されている。 どの URL が最適なのか、という話。 結論は www.rfc-editor.org だ。 RFC Hosting Site 例えば RFC 9110 - HTTP Semantics で言うと、以下の 4 つがある。 https://tools.ietf.org/html/rfc9110 https://datatracker.ietf.org/doc/html/rfc9110 https://www.rfc-editor.org/rfc/rfc9110.html https://httpwg.org/specs/rfc9110.html まずは、これらの違いを簡単に解説する。 tools.ietf.org IETF がホストする RFC は、 tools.ietf.org だった。 RFC 2616: H
一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
Stream: Internet Engineering Task Force (IETF) RFC: 9116 Category: Informational Published: April 2022 ISSN: 2070-1721 Authors: RFC 9116 A File Format to Aid in Security Vulnerability Disclosure Abstract When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a machine-parsa
OAuth & OpenID Connect 関連仕様まとめ - Qiita
はじめに OAuth や OpenID Connect に関連する仕様を紹介していこうと思います。 仕様はたくさんあるものの、ほとんどオプショナルです。しかし、「認可サーバーを実装する際は、RFC 6749 だけではなく、認可コード横取り攻撃への対抗策である RFC 7636 も実装すべきである」* という点は強調しておきたいと思います。 * 「PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと」という記事もご参照ください。 1. OAuth 2.0 (RFC 6749) OAuth 2.0 の仕様の本体は RFC 6749 (The OAuth 2.0 Authorization Framework) です。RFC 6749 の解説記事は世の中にたくさんあるので、ここでは要点だけ手短に紹介します。 RFC 6749 は、アクセストークンを発行
細かすぎて伝わらないSSL/TLS
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 「細かいと言うより長いよね」 はじめに こんにちは。ATS の脆弱性を発見した小柴さんや ATS に HTTP/2 の実装を行っている大久保さんと同じチームの一年目、匿名社員M さんからいじられている新人です。今回ありがたい事に、こういったすごい方々を含めモヒカン諸先輩方より「何か書かないの？」「いつ書くの？」という数々のプレッシャーお言葉をいただきました。 というわけで、SSL/TLS の Session 再開機能に関して書いていこうかと思います。 SSL/TLS は機密性、完全性そして真正性に対して安全な通信を行うための仕組みです。しかし、この仕組みは暗号技術を多用し特に接続において複雑なプロトコルを用い、Client, Se
ＲＦＣ日本語版リスト
リンク上の問題や追加情報があるようでしたらどしどし連絡してください。 インターネットに散らばるＲＦＣの 日本語訳（和訳）のリンクリストを作りました。 多分、同じ翻訳で、コピーが複数あると思えるのはまとめて１行にしています。 （高橋邦夫さんが訳したＲＦＣ１８５５はあまりにもコピーが多いので一部のリンクのみ掲載しています） 同じＲＦＣを、多分別の人が翻訳したと思えるのは別の行にしています。 時代の流れでなくなったページもあります（場所が変わって見つかっていないだけかもしれません）。 [日本語訳]が付いていない所はそんなページと思ってください。 ソースにはコメントとしてＵＲＬを残してあります。 いずれかのアーカイブを探せば見つかるかもしれません。 これらの日本語訳は完全なものとは限りません。 間違って翻訳していたり、 途中だけ翻訳されてたり、翻訳の途中で中断・中止してる事もあります。 翻訳の公開
Same-Origin Policy とは何なのか。 - 葉っぱ日記
ちょっと凝ったWebアプリケーションを作成していたり、あるいはWebのセキュリティに関わっている人ならば「Same-Origin Policy」(SOP)という言葉を一度は聞いたことがあると思います。日本語では「同一生成元ポリシー」あるいは「同一生成源ポリシー」などと訳されることもありますが、個人的には「オリジン」は固有の概念を表す語なので下手に訳さず「同一オリジンポリシー」と書いておくのが好きです。 さて、この「オリジン」とは何なのかという話ですが、これは「RFC 6454 - The Web Origin Concept」で定められており、端的に言うと「スキーム、ホスト、ポート」の組み合わせをオリジンと定め、それらが同じものは同一のオリジンとして同じ保護範囲のリソースとして取り扱うということです。 例えば、http://example.jp/fooとhttp://example.jp:
メール誕生からある「7ビットの制約」を越えるMIMEとは？ (1/2)
もともと電子メールは英語圏で開発されたシステムであり、コンピュータが普及して多言語対応になる以前から使われてきた。メッセージの標準文字セットは「US-ASCII」であり、そのメールを扱うプロトコルである「SMTP（Simple Mail Transfer Protocol）」を実装したソフトウェア（メールサーバーやメールクライアント）もまた、US-ASCIIを標準の文字セットとしている。 7ビットを越えるMIMEのヘッダフィールド 記述される文字は、1文字1バイトといっても実際には7ビットの情報である。つまり、7ビットで表現される文字で作られたシステムに、後から入ってきたものが8ビットで表現される文字で動作させようとしてもうまく動作しない可能性がある。 これではヨーロッパの英語以外の文字も日本語もメールで使うことはできず、データファイルなどバイナリデータはまったく扱えない厳しい制約となる。
vCard電子名刺のMIMEディレクトリプロファイル, TOC
標準情報(TR) TR X 0046:2001 vCard電子名刺のMIMEディレクトリプロファイル 目 次 まえがき 序文 0. 一般 0.1 適用範囲 0.2 表記 0.3 概要 1. vCard MIMEディレクトリプロファイルの登録 2. MIMEディレクトリの機能 2.1 定義済み型の利用 2.2 定義済みパラメタの利用 2.3 定義済みVALUE型の利用 2.4 定義済みVALUE型の拡張 2.5 構造型値 2.6 行区切り及び継続 3. vCardプロファイルの機能 3.1 識別型 3.2 配達用番地型 3.3 電気通信用番地型 3.4 地理型 3.5 組織型 3.6 説明用の型 3.7 セキュリティ型 3.8 拡張型 4. 形式文法 5. vCard v2.1との相違 6. 貢献者 7. 著者の連絡先 8. セキュリティへの考慮 9. 引用規定 10. 著作権表示 解説
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RFC標準を調べるための知識やツール - Qiita