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

1. WebPackaging IETF 側
@flano_yuki

2. 誰
- @flano_yuki
- プロロコルの人らしい
- 主にWeb関連のプロトコル
- たまにIETF行ったり
- たまにブログ書いたり (asnokaze blog)
- WebPackaging歴 7ヶ月

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をどのように読み込むかの仕様

5. Bundled HTTP exchanges

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]

11. Signed HTTP exchanges先月仕様読んだはずなのに変わってて辛い

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;

15. Signatureヘッダ
- integrity
- payloadの完全性を担保するのに使用するアルゴリズムを指定する。
- 下記のどちらかを必ずサポートする
- “mi” : Merkle Integrity Content Encoding ([I-D.thomson-http-mice]):
- "digest" : Instance Digests in HTTP (RFC3230)
- 完全性を担保するためのヘッダが付くので、それを署名範囲に含めることでpayload
の完全性を担保することが出来る
integrity="mi";

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. 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. Signatureヘッダ
- date
- この署名を行ったunix time
- expires
- 有効期限を示す unixtime
- date より 7日以内である必要がある
date=1511128380;
expires=1511733180,

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<

23. http://cbor.me/ に食わせる

24. まとめ

25. まとめ / その他
- WebPackagingは複数の仕様に標準化が進められている
- Bundled HTTP exchanges: ひとつに束ねるフォーマット定義
- Signed HTTP exchanges: 署名する仕組みを定義
- Loading: ブラウザがWebPackageをどのように読み込むかの仕様
- HTTP exchangesをひとつに束ねて、署名することで再配布可能
- まだまだ仕様は変わりそう
- IETF 101で議論がりそう?
- BoFの開催をfailしてたように見えたが...

26. backup slides

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. Accept-Signatureヘッダ
クライアントが対応している署名方式を通知する。
Accept-Signature: -rsa/2048, rsa/4096