Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Web packaging IETF 側

428 views

Published on

Web Packagingに関して
- Signed HTTP exchanges
- Bundled HTTP exchanges

Published in: Internet
  • Be the first to comment

Web packaging IETF 側

  1. 1. WebPackaging IETF 側 @flano_yuki
  2. 2. 誰 - @flano_yuki - プロロコルの人らしい - 主にWeb関連のプロトコル - たまにIETF行ったり - たまにブログ書いたり (asnokaze blog) - WebPackaging歴 7ヶ月
  3. 3. WebPackaging とは - WebPackaging とは - Webページをひとつに固めて再配布可能とする仕組み - HTTP exchanges(リクエスト/レスポンス)をCBOR形式で固める - 署名が付けられる(元のオリジンによる署名) - ユースケース - Use Cases and Requirements for Web Packages - オフライン ブラウジング - CDN等からの配布 - HTTP2 クロスドメインサーバプッシュ - AMP? ServiceWorker? etc... - 標準化 - ちゃんと標準化する流れ - IETF 101 のHTTPbis WGで関連文書の議論予定
  4. 4. WebPackaging と標準化 ココまでの流れ, 3行で - GoogleのJeffrey Yasskinが主導してW3CのWICGで議論されていた - IETF99 でdispatch wgに持ち込まれる - WebPackagingは、現在 幾つかの仕様に分割され標準化が進む模様 IETF (dispatch wg -> HTTPbis) - Bundled HTTP exchanges: ひとつに束ねるフォーマット定義 - Signed HTTP exchanges: 署名する仕組みを定義 W3C or WHATWG - Loading: ブラウザがWebPackageをどのように読み込むかの仕様
  5. 5. Bundled HTTP exchanges
  6. 6. Bundled HTTP exchanges HTTP exchangesをひとつに固めるフォーマットを定義する(bundle)。 提案仕様はIETFにまだ提出されていないが、J. Yasskinの個人リポジトリから見 ることが出来る(URL)。 特徴 - CBOR形式 - 必要な情報のみにアクセス出来るようになっている - Load a bundle’s metadata (meta, index情報を読み込む) - Load a response (必要なHTTPレスポンス情報を読み込む) - 将来のバージョンアップでセクションが追記できる
  7. 7. Bundled HTTP exchanges (format) - magic: マジックコード - section-offsets: 各セクションへのオフセット。開始場所がわかる - sections: セクション。index, manifest, critical, responses (後述) - length: 長さ bundle = [ magic: h'F0 9F 8C 90 F0 9F 93 A6', ; in UTF-8. section-offsets: {* (($section-name .within tstr) => uint) }, sections: [* $section ], length: bytes .size 8, ]
  8. 8. Bundled HTTP exchanges (index) index セクション - HTTPリクエストに対するレスポンスが、responsesセクションの何処にあるかの オフセットを示す - HTTPリクエスト(http-request)は、ヘッダのkey/valueで表現され、 :url, :method を必ずもつ index = {* http-request => [ offset: uint, length: uint] } http-request = { * bstr => bstr }
  9. 9. Bundled HTTP exchanges (responses) responses セクション - HTTPレスポンスが格納される - 各responseは複数のレスポンスヘッダとペイロードデータから成る。 responses = [*response] response = [headers: {* bstr => bstr}, payload: bstr]
  10. 10. Bundled HTTP exchanges (残り) manifest セクション - このbundle自身のWeb App Manifestへのリクエスト - 中身はresponsesセクションに記述されるはず manifest = http-request criticalセクション - bundleは将来のバージョンでsection定義が追加される可能性がある - 未知のsectionは無視されるが、サポートしてなければいけないsection名がセク ションに記述される critical = [*tstr]
  11. 11. Signed HTTP exchanges先月仕様読んだはずなのに変わってて辛い
  12. 12. Signed HTTP exchanges HTTP exchangesを署名するための仕様 (実際にHTTPリクエストレスポンスす る必要はない) - Signatureヘッダの定義 - 署名範囲と検証方法 - Signed-Headersヘッダ - HTTP/2 クロスオリジンサーバプッシュ拡張の定義 Intermediate 取得/再配布 Author 署名 Client 検証 利用 :method : GET :authority : example.com :path : /index.html ... :status : 200 signature : xxxxxx digest: yyyyy ... {payload}
  13. 13. Signatureヘッダ, Signed-Headersヘッダ Signatureヘッダは ”Structured Headers for HTTP” の仕様則り定義される Signature: sig1; sig=*MEUCIQD….huBdqp5UY; integrity="mi"; validityUrl="https://example.com/resource.validity.1511128380"; certUrl="https://example.com/oldcerts"; certSha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI; date=1511128380; expires=1511733180, thirdpartysig; sig=*MEYCIQCNxJzn….Owgj2mRXALhfXPztXgPupii+; integrity="mi"; … Signed-Headers: "content-type", "digest" #レスポンスヘッダの署名範囲を示す
  14. 14. Signatureヘッダ - sig: - HTTP exchange の署名 (Authorの秘密鍵で署名される) - 仕様で定義された手順でHTTP exchangeをselializedして署名される(略) - 署名範囲 - HTTPリクエストのmethod, effective request URI - Signed-Headersヘッダで指定されるヘッダ - 後述のintegirtyを通してペイロードも署名される sig=*MEUCIQD….huBdqp5UY;
  15. 15. Signatureヘッダ - integrity - payloadの完全性を担保するのに使用するアルゴリズムを指定する。 - 下記のどちらかを必ずサポートする - “mi” : Merkle Integrity Content Encoding ([I-D.thomson-http-mice]): - "digest" : Instance Digests in HTTP (RFC3230) - 完全性を担保するためのヘッダが付くので、それを署名範囲に含めることでpayload の完全性を担保することが出来る integrity="mi";
  16. 16. Signatureヘッダ - validityUrl - 署名リストが失効している場合などに、新しい署名を取得するURL先 validityUrl="https://example.com/resource.validity.1511128380"; { "signatures": [ 'sig1; ' 'sig=*MEQCIC/I9Q+7BZ…...86UjkPbj4jw; ' 'validityUrl="https://example.com/resource.validity.1511157180"; ' ... 'certSha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw; ' 'date=1511733180; expires=1512337980' ], "update": {"size": 5557452 } }
  17. 17. Signatureヘッダ - certUrl - 署名に使用した鍵に対応する証明書チェーンの取得出来るURL - ココから得た公開鍵は署名のvalidationに使用される - TLS1.3 Certificate message形式のデータ - TLS 1.3 CertificateEntry 形式のOCSPレスポンスを付けられる - 変更するかも=>「Avoid the TLS 1.3 Certificate message. #122」 - certSha256 - 証明書のハッシュ値 certUrl="https://example.com/oldcerts"; certSha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI;
  18. 18. Signatureヘッダ - date - この署名を行ったunix time - expires - 有効期限を示す unixtime - date より 7日以内である必要がある date=1511128380; expires=1511733180,
  19. 19. Signed HTTP exchanges (再掲) HTTP exchangesを署名するための仕様 (実際にHTTPリクエストレスポンスす る必要はない) - Signatureヘッダの定義 - 署名範囲と検証方法 - Signed-Headersヘッダ - HTTP/2 クロスオリジンサーバプッシュ拡張の定義 Intermediate 取得/再配布 Author 署名 Client 検証 利用 :method : GET :authority : example.com :path : /index.html ... :status : 200 signature : xxxxxx digest: yyyyy ... {payload}
  20. 20. HTTP/2 クロスオリジンサーバプッシュ - HTTP Exchangeが署名されていればクロスオリジンサーバプッシュが可能 - HTTP Exchange = PUSH_PROMISのとプッシュするレスポンス - HTTP/2拡張として以下を定義 - NO_TRUSTED_EXCHANGE_SIGNATURE エラー - ENABLE_CROSS_ORIGIN_PUSH SETTINGSパラメータ
  21. 21. htxg - HTTP1.xなどサーバプッシュが使えない環境で、クロスオリジンレスポンスを表現 するフォーマット (これを渡せば、クロスオリジンレスポンスとなる) - Content-Type:application/http-exchange+cbor [ "htxg", "request", { ':method': 'GET', ':url': 'https://example.com/', 'accept', '*/*' }, "response", { ':status': '200', 'content-type': 'text/html' }, "payload", '<!doctype html>rn<html>...' ]
  22. 22. htxg ツール - htxg生成ツールがある - 手元にある鍵で、手元にある index.htmlに対してのHTTP Exchangeを署名する $ git clone https://github.com/WICG/webpackage.git $ go run ./go/signedexchange/cmd/gen-signedexchange/main.go -certificate cert.pem -privateKey cert-key.pem -content index.html -o out.htxg $ od -An -tx1z ./out.htxg 87 64 68 74 78 67 67 72 65 71 75 65 73 74 a2 44 >.dhtxggrequest.D< 3a 75 72 6c 58 1e 68 74 74 70 73 3a 2f 2f 65 78 >:urlX.https://ex< 61 6d 70 6c 65 2e 63 6f 6d 2f 69 6e 64 65 78 2e >ample.com/index.< 68 74 6d 6c 47 3a 6d 65 74 68 6f 64 43 47 45 54 >htmlG:methodCGET< 68 72 65 73 70 6f 6e 73 65 a6 42 6d 69 58 35 6d >hresponse.BmiX5m< 69 2d 73 68 61 32 35 36 3d 54 67 65 45 6f 49 52 >i-sha256=TgeEoIR< 67 4b 6d 71 54 76 6b 74 78 56 6a 48 41 53 6e 6d >gKmqTvktxVjHASnm<
  23. 23. http://cbor.me/ に食わせる
  24. 24. まとめ
  25. 25. まとめ / その他 - WebPackagingは複数の仕様に標準化が進められている - Bundled HTTP exchanges: ひとつに束ねるフォーマット定義 - Signed HTTP exchanges: 署名する仕組みを定義 - Loading: ブラウザがWebPackageをどのように読み込むかの仕様 - HTTP exchangesをひとつに束ねて、署名することで再配布可能 - まだまだ仕様は変わりそう - IETF 101で議論がりそう? - BoFの開催をfailしてたように見えたが...
  26. 26. backup slides
  27. 27. Signed HTTP exchanges HTTP exchangesを署名するための仕様 - Signatureヘッダの定義 - 署名範囲と検証方法 - Signed-Headersヘッダ - Accept-Signatureの定義 - HTTP/2 クロスオリジンサーバプッシュ拡張の定義 Intermediate 取得/再配布 Author 署名 Client 利用/検証 :method : GET :authority : example.com :path : /index.html ... :status : 200 signature : xxxxxx digest: yyyyy ... {payload} HTTP Exchange
  28. 28. Accept-Signatureヘッダ クライアントが対応している署名方式を通知する。 Accept-Signature: -rsa/2048, rsa/4096

×