SEA: A Security Extension Architecture for HTTP/1.X
5th W3C Security Working Group
Rohit Khare
quick reminder of PEP,
tour of sea, why 3 only, this WG must do mediu-chunky
Pt 2: how you're going. 4 problem areas.
SEA & the Fifth WG Meeting
!l	SEA is the heart of today’s meeting
l	Part I:SEA
»	SEA Background & Rationale
»	Review of SEA Design, feedback
l	“Part II”: Using PEP/SEA
»	Detailed PEP/SEA Sc!enario
s18 »	Presented by Dr. Phillip Hallam-Baker
l	Part III: This WG’s Work
»	Problems & Breakout
»	W3C Strategy and Planning
SEA: Security Extension Architecture
l	“What is the smallest set of factorable modules to construct Web security from?”
!lainl	80An initial attempt
»	We claim it’s not all that’s necessary, but it is sufficient
l	Quick Review of PEP
l	Detailed Presentation of core SEA classes
PEP: An HTTP Extension Mechanism
l	Progress Report: stable, doing well
l	nNegotiation Review
l	Implementation Model
SEA pass 1
Signature
Encryption
Key-Exchange
Extensions to Core SEA
l	Key-Management
l	Authentication
»	Repudiable authenticity
l	Authorization Mechanisms
Part III
Signature
l	explain questions from agenda
Encryption
l	explain questions from agenda
l	Interface to K-E???
Key-Exchange
l	explain questions from agenda
l	*1Interface to Encryption???
Implementation
l	Do the PEP section 7 concerns scare people?
»	(take this opportunity to review some)
W3C Strategy
7-points
Oxymoron: a Novel Security Solution
l	Security for message-oriented protocols is colored by 2-3 decades of design experience – little of it appropriate for the new age of component solutions (both for !applications and the crypto widgets).
l	Security MUST be done with HTTP.
l	Security should be evolvable