IETF91報告arcmedia-mcic

https://lepidum.co.jp/ Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.
IETF91 Honolulu
BoF Short Report
arcmedia, mcic
株式会社レピダム
前田薫 (@mad_p)
IETF91報告会 2014/12/19
IETF91報告会2014/12/19

Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
arcmedia BoF
 Top-level Archive Media Type (ARCMEDIA)
 non WG-forming BoFのつもりで → WG設立?
 アーカイブメディアに対応するトップレベ
ルmedia-typeを作るべきか?
 draft-seantek-kerwin-arcmedia-type-00
 例: archive/tar
 動機 (Sean Leonard)
 application/tarを作ろうとして
application/zipを発見
IETF91報告会2014/12/19
3

arcmedia 問題点
 ユースケース
 まずどんなsubtypeがあるのかリストしてから
 UIの統一なども考えるのか
 ファイル名の国際化, subpath
 tar, tar|bzip2の両方がないと署名検証で失敗
 multipartとの使い分け
 appsawgで議論するか、新しいWGを作るか
 Barry Leibaは新WGの方向
 ML: arcmedia
IETF91報告会2014/12/19
4

mcic bar BoF
 Multiparty Content Integrity and Confidentiality
 TLSはe2e point-to-pointである。もっと他の場合も扱いた
い
 同一のTLSセッションに3者以上の参加者
 Thomas Fossati案: TLSに3rd-partyパブリックキーを導
入。交信の一部をプロキシでも見えるようにする
 HTTP headersをintermediaryにも見えるように送る、
bodyはendにしか見えないように、など
 多くの問題が指摘された
 compromiseできる、AEADでは難しい、shared-keyを多くのユー
ザ間で共有するのはよくない、など
IETF91報告会2014/12/19
5

mcic
 use casesCaching
 Content inspection
 video pacing/optimizations
 TLS keys for CDN
 多すぎる。wikiなどに集める → 問題定義、解決案、
privacy/security impacなどを検討
 proxyの話に終始していたが、single-flow内での
security level分離が必要なのかという問が大事
 TLSをbreakすることが目的ではないので注意
 ML: mcic
IETF91報告会2014/12/19
6

Any Questions? / Please Feedback!
https://lepidum.co.jp/
mailto:maeda@lepidum.co.jp / twitter: @mad_p
IETF91報告会2014/12/19

IETF91報告arcmedia-mcic

More Related Content

More from Kaoru Maeda

Recently uploaded

IETF91報告arcmedia-mcic