HTML5 일정 현황 및 계획
lynda.com Tutorial | HTML5 First Look—HTML5 timeline (
http://www.youtube.com/watch?v=tJurCyWJW9k) 에서 발췌

  • 2004: WHATWG 발족, "Web Application and Compound Documents" 워크샵
  • 2005: Web Application 1.0 초안 (Working Draft) 발표
  • 2007: W3C가 WHATWG의 작업내용을 수용, HTML5 초안 (Working Draft)을 발표함
  • 2009: HTML5 초안 (Working Draft)에 대한 Last Call 시작됨
  • 2012: HTML5 스펙을 Candidate 상태로 레벨 업 (예정)
  • 2022: HTML5 스펙을 Recommendation(최종안) 상태로 레벨 업 (예정)
  • 그리고...
  • 2009: HTML5 에 대한 대중의 관심이 급격히 커짐
  • 2010: 초안 (Working Draft)에 대한 Last Call 과정이 진행중
     * 초안의 일부 항목들은 무척 성숙한 단계에 있음
     * 점점 더 많은 기기와 브라우저들이 HTML5의 일부 항목들을 지원하고 있음
     * 따라서 HTML5의 일부 기술은 2022년 최종 스펙 발표까지 기다릴 필요 없이 지금 당장(!) 사용할 수 있음

W3C 산하 HTML5 표준화 워킹그룹과 표준화 기술 분야
2011년, W3C HTML5 표준화 동향 및 전망 (
http://www.wonsuk73.com/category/HTML5%20%ED%91%9C%EC%A4%80%20%EA%B8%B0%EC%88%A0) 에서 발췌

WG 

표준개발 범위

개발 표준 현황

HTML WG

HTML5 마크업 관련 표준 개발

-   HTML5

-   HTML+RDFa

-   HTML Microdata

-   HTML Canvas 2D Context

Web Application WG

웹 애플리케이션 개발에 필요한 웹소켓, 웹워커, IndexedDB, FileAPI 등을 포함하여 HTML5와 관련된 주요 API 표준 개발

-   Web Sockets API

-   Web Storage

-   Web Workers

-   Indexed Database API

-   Server-Sent Events

-   Cross-Origin Resource Sharing (CORS)

-   HTML5 Web Messaging

-   Clipboard Operations

-   File API

-   File API: Directories and System

-   File API: Writer

-   Programmable HTTP Caching and Serving

Device APIs and Policy WG

데스크탑, 랩탑, 모바일 인터넷 단말(MID), 핸드폰 등 다양한 기기의 웹 브라우저에서 일정, 업무, 연락처, 카메라, 메시지, 시스템 정보, 이벤트 등의 다양한 단말 기능을 사용할 수 있도록 하는 API 표준

-   Contacts API

-   The Calendar API

-   The Media Capture API

-   The Messaging API

-   The System Information API

Geolocation WG

Geolocation API를 포함하여 가속센서, 방향센서 등 센서에 관련된 표준 개발

-   Geolocation API

-   DeviceOrientation Event

Web Notification WG

사용자에게 알려주기 위해 필요한 Notification과 관련된 API 표준으로, Notification과 관련하여 사용자 인터액션(Interaction) 관리에 필요한 이벤트에 대한 표준도 포함

-   Web Notifications

Web Performance WG

웹 브라우저의 특징들과 API들에 대한 애플리케이션 성능 측정에 대한 표준 개발

-   Navigation Timing

Web Event WG

모든 디바이스의 멀티터치,-테블릿 입력 등의 사용을 가능하게 하는 방법에 대한  표준 개발

-   Web Events

Web Real-Time Communications WG

웹 브라우저에서 P2P(Peer to Peer) 오디오, 비디오 등 실시간 통신을 위한 클라이언트 API 표준 개발

-   WG Charter 검토 중



(끝)

저작자 표시 비영리 변경 금지
신고
Posted by ingee
TAG HTML5

댓글을 달아 주세요

SSL/TLS는 안전한(보안이 적용된) TCP/IP socket 채널을 제공해주는 기술이다. 브라우저 빅뱅 초기에 정립된 기술이고, OpenSSL이라는 확실한 오픈소스 프로젝트가 존재하는 잘 정립된 기술이다. OpenSSL은 SSL/TLS의 종결자라 할 수 있는 소스 더미인데, 막상 가져다 쓰려면 참고할만한 문서가 막연하다. 일 때문에 이리저리 헤매다 좋은 문서를 발견하여 여기 요약한다. 다음 내용은 내게 필요했던 일부만 발췌한 것이다. 원본 페이지에는 샘플 코드를 비롯, 더 자세한 설명이 담겨있다. 아쉬운 개발자들은 주저 없이 방문 바란다.

이제 보안 연결을 설정하는데 필요한 것을 알아보자. 달라진 유일한 부분은 연결 설정 및 연결을 만드는 것이다. 다른 모든 것은 똑같다.
보안 연결은 연결이 구축된 후에 핸드쉐이크(handshake)를 필요로 한다. 헨드쉐이크 동안, 서버는 인증을 클라이언트에 보내는데, 클라이언트는 트러스트 인증에 준하여 이를 확인한다. 또한, 인증을 검사하여 만기가 되었는지를 확인한다. 인증이 신뢰를 받는 것인지를 확인하려면 트러스트 인증 스토어가 연결을 구축하기 전에 로딩되어야 한다.
클라이언트는 서버가 인증을 요청할 경우에만 서버로 인증을 보낸다. 이것은 클라이언트 인증으로 알려져 있다. 인증을 사용하여, 암호 매개변수들이 클라이언트와 서버 사이에 전달되어 보안 연결을 구축한다. 핸드쉐이크가 연결이 구축된 후에 수행되더라도, 클라이언트나 서버는 어떤 지점에서라도 새로운 핸드쉐이크를 요청할 수 있다.
핸드쉐이크와 보안 연결을 설정하는 다른 측면들은 Netscape 기술자료와 RFC 2246에 설명되어 있다.

이 글은 핸드쉐이크 하는 사이에 서버의 디지털 인증서를 처리하는 것에 초점을 맞추므로 핸드쉐이크가 어떻게 작동하는지를 상세히 살펴보고자 한다. 여러분이 SSL 프로시저에 익숙하다면, 이 섹션은 무시해도 좋다.
연결에서 개방(opening) 핸드쉐이크는 서버에 "Hello"라고 말하는 클라이언트로 시작된다. Hello 메시지에는 클라이언트의 보안 매개변수들이 포함되어 있다.
SSL 버전 넘버
무작위로 생성된 데이터
암호 설정
통신에 필요한 기타 사항
서버는 클라이언트가 제공한 것과 같은 유형의 정보인 서버의 보안 매개변수들을 포함하고 있는 고유의 Hello 메시지에 응답한다. 바로 이때 서버도 디지털 인증서를 보낸다. 클라이언트 권한이 연결에 사용되면 서버는 클라이언트의 인증서에 대한 요청을 보낸다.
서버의 Hello 메시지를 받으면, 디지털 인증서가 확인된다. 인증서의 다양한 매개변수들을 확인하여 인증서가 원래 그대로 보존되었는지를 확인하고, 유효 기간 내에 인증서가 사용되고 있는지를 확인한다.
여기에서 수행되어야 하는 한 가지 단계는 연결에 사용되는 호스트 네임과 비교하여 인증서 상의 이름을 검사하는 것이다. 이는 SSL 표준의 일부는 아니지만, man in the middle attack (MITM)을 방지하기 위해서 권장된다. 이 단계는 인증서가 여러분이 생각하고 있는 엔터티에서 온 것임을 확인한다. 이 두 개가 이 지점에서 매치되지 않으면, 인증서는 무효한 것이 아닌, 의심의 대상이 된다.
클라이언트와 서버 간 공유되었던 랜덤 데이터는 서버와 클라이언트에게만 알려진 공유 비밀 값으로서 이 세션에만 사용되는 premaster secret을 생성하는데 사용된다. 이 비밀 값은 서버의 디지털 인증서로 암호화 되고 확인을 위해 서버로 보내진다.
서버가 클라이언트 인증을 요청하면, 클라이언트는 핸드쉐이크 동안 무작위로 생성되고 서버와 클라이언트에게만 알려진 데이터의 단방향 해시(hash)를 생성한다. 클라이언트는 클라이언트의 개인 키(private key)를 사용하여 해시에 서명을 하고 서명된 데이터와 디지털 인증서를 서버로 보낸다. 서버는 그 정보를 사용하여 클라이언트를 인증한다.
인증이 성공하면, 서버와 클라이언트 모두 공유된 랜덤 데이터를 알고리즘을 통해 실행하여 master secret을 생성한다. master secret에서, 클라이언트와 서버는 세션 키(session keys)를 생성한다. 이것은 선택된 시메트릭 암호 안에 있는 대칭 키로서 세션 데이터를 암호화 하는데 사용된다.
클라이언트는 종료되었다는 메시지를 서버로 보냄으로써 핸드쉐이크를 종료한다. 이것은 서버에 의해 확인되어야 하는 암호화 된 단방향 해시 값 세트이다. 서버는 비슷한 메시지를 클라이언트로 보낸다. 클라이언트와 서버는 핸드쉐이크를 종료하고 통신을 시작하기 전에 데이터가 정확한지를 확인한다.

피어 인증서 확인하기
핸드쉐이크에서 제공된 서버의 인증서는 서버의 호스트 네임과 매치하는 것에 대한 이름을 가져야 한다. 그렇지 않다면, 인증서는 의심스러운 것으로 표시되어야 한다. 내부 확인 절차는 이미 트러스트와 종료에 대해 인증서를 검사한다. 인증서가 종료되었거나 믿을 수 없는 서명을 포함하고 있다면 무효로 표시된다. 이것은 SSL 표준의 일부가 아니므로 OpenSSL은 호스트 네임에 대해 인증서의 이름을 검사하지 않는다.
인증서의 "이름"은 실제로 인증서 상의 Common Name 필드이다. 이 필드는 인증서에서 가져온 것이어야 하며 호스트 네임에 비교하여 확인되어야 한다. 이 두 가지가 매치되지 않으면, 인증서는 무효가 아닌 의심 상태가 된다. Yahoo! 같은 일부 기업들은 다양한 호스트에 같은 인증서를 사용한다. 그 인증서에 대한 Common Name이 단 한 개의 호스트를 위한 것인데도 말이다. 인증서가 같은 회사에서 온 것인지를 확인하기 위해 보다 심도 깊은 체크가 수행되지만, 이는 프로젝트의 보안 필요에 따라 수행한다.

여기까지... 좋은 개발, 좋은 하루...

저작자 표시 비영리 변경 금지
신고
Posted by ingee
TAG openssl, SSL, TLS

댓글을 달아 주세요

좋은 책. 이런 멋진 책을 한글로 지어낸 저자들이 존경스럽다.
http://book.daum.net/detail/book.do?bookid=KOR9788992939584


저작자 표시 비영리 변경 금지
신고
Posted by ingee

댓글을 달아 주세요