More Related Content
Similar to Web packaging IETF 側 (20)
Web packaging IETF 側
- 3. WebPackaging とは
- WebPackaging とは
- Webページをひとつに固めて再配布可能とする仕組み
- HTTP exchanges(リクエスト/レスポンス)をCBOR形式で固める
- 署名が付けられる(元のオリジンによる署名)
- ユースケース
- Use Cases and Requirements for Web Packages
- オフライン ブラウジング
- CDN等からの配布
- HTTP2 クロスドメインサーバプッシュ
- AMP? ServiceWorker? etc...
- 標準化
- ちゃんと標準化する流れ
- IETF 101 のHTTPbis WGで関連文書の議論予定
- 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をどのように読み込むかの仕様
- 6. Bundled HTTP exchanges
HTTP exchangesをひとつに固めるフォーマットを定義する(bundle)。
提案仕様はIETFにまだ提出されていないが、J. Yasskinの個人リポジトリから見
ることが出来る(URL)。
特徴
- CBOR形式
- 必要な情報のみにアクセス出来るようになっている
- Load a bundle’s metadata (meta, index情報を読み込む)
- Load a response (必要なHTTPレスポンス情報を読み込む)
- 将来のバージョンアップでセクションが追記できる
- 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. 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. Bundled HTTP exchanges (responses)
responses セクション
- HTTPレスポンスが格納される
- 各responseは複数のレスポンスヘッダとペイロードデータから成る。
responses = [*response]
response = [headers: {* bstr => bstr}, payload: bstr]
- 10. Bundled HTTP exchanges (残り)
manifest セクション
- このbundle自身のWeb App Manifestへのリクエスト
- 中身はresponsesセクションに記述されるはず
manifest = http-request
criticalセクション
- bundleは将来のバージョンでsection定義が追加される可能性がある
- 未知のsectionは無視されるが、サポートしてなければいけないsection名がセク
ションに記述される
critical = [*tstr]
- 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. 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. Signatureヘッダ
- sig:
- HTTP exchange の署名 (Authorの秘密鍵で署名される)
- 仕様で定義された手順でHTTP exchangeをselializedして署名される(略)
- 署名範囲
- HTTPリクエストのmethod, effective request URI
- Signed-Headersヘッダで指定されるヘッダ
- 後述のintegirtyを通してペイロードも署名される
sig=*MEUCIQD….huBdqp5UY;
- 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;
- 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. HTTP/2 クロスオリジンサーバプッシュ
- HTTP Exchangeが署名されていればクロスオリジンサーバプッシュが可能
- HTTP Exchange = PUSH_PROMISのとプッシュするレスポンス
- HTTP/2拡張として以下を定義
- NO_TRUSTED_EXCHANGE_SIGNATURE エラー
- ENABLE_CROSS_ORIGIN_PUSH SETTINGSパラメータ
- 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. 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<
- 25. まとめ / その他
- WebPackagingは複数の仕様に標準化が進められている
- Bundled HTTP exchanges: ひとつに束ねるフォーマット定義
- Signed HTTP exchanges: 署名する仕組みを定義
- Loading: ブラウザがWebPackageをどのように読み込むかの仕様
- HTTP exchangesをひとつに束ねて、署名することで再配布可能
- まだまだ仕様は変わりそう
- IETF 101で議論がりそう?
- BoFの開催をfailしてたように見えたが...
- 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