|
:: 게시판
:: 이전 게시판
|
- 자유 주제로 사용할 수 있는 게시판입니다.
- 토론 게시판의 용도를 겸합니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
13/10/11 17:16
법적효력근거라.. Active X 라던가, 돈이라던가는 제 관심사는 아니니 제쳐두고서라도, 당 메일을 확인했는지 명확히 확인이 가능한 시스템은 상당히............ 위험하군요. 위험합니다.
13/10/11 17:42
읽어 보니 무엇이 그리 잘못된 것인지는 잘 이해가 안 가는 군요.
국제표준은 개나줘버린 독자적 서비스 - 일단 개발 목적 자체가 국내 수요자를 대상으로 필요한 서비스를 제공할 수 있도록 한다는 것인데, 굳이 국제 표준을 들고 나올 이유가 있을까요? 만약 여기서 제공하고자 하는 서비스와 거의 같은 국제 표준이 있다면 그것을 따르는 것이 온당하겠지만, 그러한 표준이 없으니 서비스 모델을 만들고, 차후 표준화도 노리고 있는 것으로 이해했는데, 어떤 것이 문제인지 알고 싶습니다. 유료 서비스 - 유료라는 것 자체만으로 문제가 있다고 하기는 어렵지요. 정부의 눈먼 돈을 일부 업자들이 손쉽게 챙길 수 있다는 예상을 하신 건지 모르겠지만, 우선 서비스 제공자가 단일이지 않으며, 기업에서 자체 서버를 만들 수도 있다고 하네요. 그 눈먼 돈이라는 게 사실은 지금은 등기우편으로 더 많이 나가고 있었다면? 쓰기 싫어도 써야하는 사태 - 물론 그렇게 되면 절대 안되지요. 그런데 그렇게 되지도 않았는데 그걸로 공격하는 것은 허수아비 때리기지요. 예비군의 예를 들었는데, 지금도 예비군은 문자나 이메일로 통보를 하지만, 이건 신청한(연락정보를 예비군동대에 제공한) 사람에 대해서고, 디폴트는 직접 통지를 전달하는 걸로 알고 있습니다. 이걸 가지고 휴대폰이나 이메일을 쓰기 싫어도 써야 한다고 하면 옳지 않은 주장이 되겠지요.
13/10/11 18:01
지금 그렇게 되지않았다고해서 경계하는 것은 잘못된거다라는 건 어불성설이네요.
그렇게 되버리고나서야 아무리 목소리 높인들 이미 상황 끝난 일 아닌가요.
13/10/11 19:29
경계가 아니라 비난을 하고 있죠. 있지도 않은 일에 비난을 하는 게 어불성설이죠. 그리고 설사 저걸 전면적으로 시행한들 무슨 상황이 끝나겠습니까.
13/10/11 18:09
국제표준이 되지 못해서 생기는 사회적 비용과 불편함은 이미 액티브엑스와 공인인증서에서 많이 겪어보았지요. 똑같은 맥락입니다. #메일이 국제표준이 된다면 당연히 제가 올린 이글은 몇 년 후 비꼼의 댓상이 되게지만 이제까지의 경험과 이 건이 진행되는 흐름으로 볼 때 전혀 그럴 가능성이 없어보입니다. 제 주장도 올라갈팀님의 주장도 어디까지나 결과론에 의한 주장이겠지요.
유료 자체는 큰 문제가 안 됩니다. 저도 말씀하신대로 등기등에 쓰는 돈이 더 많을 수 있다고 생각합니다. 본문에도 쓴 거처럼 취지와 목적을 이해못하는 바가 아닙니다. 실제로 비용 절감이 될 수 있습니다. 이 부분은 어디까지나 이메일과 비슷한 서비스라 볼 때 처음 느끼는 일반적인 유저들의 입장에서 써본 것입니다. (본문에도 썼다시피 정부 주도로 쓰기 싫어도 쓰게되는 것이 가장 큰 문제라고 써놓았지요. 이 부분이 국제표준과 얽히고 유료화와 얽히면 좋지 못한 방향이 될 것이라고 우려하는 글입니다.) 애초에 절대 안되는 일을 진행하는 것을 보고 '절대 안 될테니 되고나서 반대해야지' 보다는 '절대 안 되니 시작도 못하게 해야지'가 여러모로 더 낫다고 봅니다. 뭐 이 글이 시작도 못하게 해야지라는 글은 아닙니다만... (그냥 알림 정도지요)
13/10/11 19:12
그런데 말입니다. 이 샾메일이라는 것이 카톡처럼 열람 여부를 알수있는 메일이다. 정도로 보이는데
제가 그런 관련 공적업무 처리할때 '대상자가 직접 이 물건,우편을 받았는가' 가 엄청 중요한 요소였는데, 이 샾메일은, 그 아이디로 보낸 메일을 그 아이디를 쓴 누군가가 열람했다. 까지는 인정될수 있어도, '대상자가 직접 메일을 확인했는가?' 까지는 인정되지 않을것 같습니다. 어떤식으로 법적 효력이 생기나요? 전국민의 개인정보가 공공재가 된 이 시점에서 해킹이나 공유, 기타 아이디 관리를 전부 본인 책임으로 판단하겠다는 건가요?
13/10/11 19:52
뭐... 내용증명이나 등기에 비유를 하고 있으니, 그 예를 들어서 말하자면 해킹이나 공유는 타인이 수신자의 신분 증명서를 가지고 서신을 전달받은 케이스에 비할 수 있겠지요.
13/10/11 18:09
국제표준을 따르지 않게 됨으로써,
기존의 이메일 표준 사용자들이 새롭게 프로그램 설치 등을 통해서 또 다른 서비스를 설치 및 적응을 해야 하는 문제도 생기게 되지 않을까요? 마치, 오직 인터넷 뱅킹 또는 인터넷 결제를 이용하기 위하여 굳이 크롬을 사용하는 사용자들이 익스플로러를 실행했던 사례를 볼 수 있겠죠. 물론 지금은 크롬 등에서도 가능하기도 합니다만, 여전히 exe 등을 따로 설치해야 하는 등의 불편함이 있기도 합니다. 수신 확인 등은 현재도 이메일 안의 이미지를 삽입하여 수신자가 이메일을 열어 다운로드를 할 경우 수신 확인이 가능 합니다. (물론 수신자의 의지에 따라서 수신 확인을 하지 않을 수도 있습니다. -> 이게 인터넷의 취지와 더 맞다고 봅니다.) 또한, 많은 기업들이 눈먼돈으로 지출 되는 등기우편을 줄이기 위해서, 사용자(고객)들에게 많은 편의사항을 제공하며 이메일 수령 등을 적극 장려하고 있지요. 이것으로 충분하다고 봅니다. 이메일 등에 익숙 하신 분들은 이미 이메일로 잘 받아보고 계시리라 생각 됩니다. 물론 사용을 강제 하지는 않았기 때문에, 이 부분에 대한 추측은 약간 억지스러운 부분이 있긴 합니다만, 그렇다면 공인인증서와 같이 널리 쓰이지도 않을 시스템을 구축하는데 들어가는 비용도 낭비가 아닐까요..?
13/10/11 19:37
새롭게 프로그램을 설치하거나 적응하는 것은 사실은 전혀 문제되지 않는 점입니다. 인터넷 뱅킹의 예를 드셨는데, 액티브엑스의 문제점은 스티브잡스님이 지적하셨다시피 다른 브라우저에서 정상적인 기능을 사용할 수 없다는 것과, 보안에 취약점이 있는 실행 파일의 다운로드에 있었지, 부가적인 프로그램을 설치하는 데 있는 것이 아니었습니다. 만약 샵메일이 윈도우에서만 작동한다든지, 개인정보 보안에 심각한 취약점이 있다면 액티브엑스와 마찬가지로 사장되어야 하지만, 링크글에서 그걸 가지고 까는 건 아니죠.
또한, 이메일에서 수신 확인만이라면 그런 방법도 있지만, 그것이야말로 이메일 표준과는 한참 동떨어진 트릭이고, 실제로 간단히 아웃룩으로 메일 확인만 해도 수신 확인이 안 됩니다. 전혀 여기서 이야기하고자 하는 것과는 동떨어진 논지입니다. 또한, 지금 여러 업무가 실제로 이메일로 잘 수행되고 있기도 하고, 이걸로 충분할 수도 있습니다. 물론 새로운 서비스가 나옴으로써 더 편해질 수도 있고요. 아이폰이 없어서 우리가 불편함을 느끼지는 않았지요.
13/10/11 18:11
현재 있는 기술에서 어느 정도 대응이 되면서 차후의 업그레이드나 추가적인 기능, 내지는 다른 필요성 등을 고려할 때 표준 외의 규격은 국내용으로 고수하지 않는 것이 낫다고 봅니다. 더군다나 한국의 익플 점유율에서 보듯, 결국 국가 표준으로 강제하면 그 국가는 갈라파고스화에 준하는 현상을 직면할 수 밖에 없게되고, 사용자는 어떠한 형태로든 불편함을 감수해야 하죠.
13/10/11 19:46
우선 익플은 국가 표준이 아니죠. 익플과 비슷한 예는 안드로이드의 과점 같은 현상이 있을 텐데, 실제로 이로 인해 불편함이 있기는 하지만 이걸 의도적으로 없애야 할 갈라파고스라고 할 수 있을지는 모르겠군요. 정말로 국가 표준에 해당하는 건 링크글에서도 언급한 공인인증서 제도가 있겠네요. 사실 저는 예전에 피지알에 공인인증서를 비판하는 블로그 소개글이 올라왔을 때도 그 블로그의 내용에 동의하기는 힘들었습니다. 그래서 굳이 표준 외의 규격을 고수할 필요는 없지만, 적당한 표준 기술이 없을 때 국내용으로 새로운 서비스를 만드는 것에 대해서 부정적으로 대하는 것은 적절하지 않다고 봅니다. 물론 샵메일이 제공하는 기능을 거의 가지고 있는 국제 표준이 있다면 샵메일은 거의 완벽한 삽질이지만, 그런 것 같지는 않군요.
13/10/11 18:26
S/MIME이라는 훌륭하고 널리 사용중인 표준기술이 있습니다.
기존 메일이 #메일의 기능을 지원하지 못한게 아니라는 거죠. 왜 만들었을까요? 크크
13/10/11 19:49
구글링해보니 S/MIME는 송수신 내용에 대한 암호화가 목적인 기술인 것 같고(마치 ssh처럼), 샵메일은 수신 추적에 방점을 두고 있는 기술 같습니다. S/MIME 기술로도 법적인 근거로 사용될 수 있는 수신 추적/관리가 가능하다는 말씀인가요?
13/10/11 20:43
물론입니다. Digital Certificate의 가장 기본이 부인방지 (non-repudiation)라서요. 메시지를 읽기 위해서는 반드시 서버인증을 거쳐야 하는데, 다시 말해서 서버 인증 내역이 있다면 메시지를 수신하고 읽은 것입니다. 누가 언제 어디서 인증했나로 #메일이 말하는 추적기능을 대체할 수 있을 것 같네요.
키 관리만 잘 된다면 디지털 인증서만큼 다재다능하고 안전한게 또 없습니다. 결국 #메일은 S/MIME 어플리케이션으로도 충분히 가능하다는거죠.. 표준 놔두고 삽질할 필요가 없습니다...
13/10/11 23:07
http://technet.microsoft.com/en-us/library/aa995740(v=exchg.65).aspx
위 링크를 참조해 봤는데, 디지털 서명의 목적 자체는 보내는 사람의 확인이고, 보내는 사람이 자신이 보내지 않았다고 부인하는 것을 방지하는 게 S/MIME의 목적이라고 하네요, 이때, 받은 측에서 서명의 진위을 확인하기 위해서 서버인증을 거쳐야 한다고 하셨는데, 위 링크에서는 그런 내용이 보이지 않네요. 서명 확인에는 받은 쪽에서 메일을 변환하여 서명을 만들어 내고 메세지와 함께 보내진 서명과 대조한다고 하네요. 그러면 서버 인증 내역이란게 존재할 수 없는 것 아닌가요?
13/10/11 23:20
Digital Signature가 제공할 수 있는 기능 중 하나가 non-repudiation입니다.
그리고 S/MIME은 Email에서 Digital Signature를 사용할 수 있게 하는 기술입니다. (위 링크에는 Digital Signature와 Message Encryption을 분리해서 설명하고 있는데, 개념은 달라도 실제로 Digital Signature가 무엇인지를 생각한다면, 이 두 개념은 뗄레야 뗄 수 없습니다. 즉 Digital Signature을 올바르게 수행하기 위해서는 반드시 Message Encryption이 들어가야 합니다.) 위 링크에 보면, Understanding What S/MIME Does S/MIME provides two security services: Digital signatures Message encryption S/MIME이 Digital signatures를 제공한다고 표현하고 있으며, 또 위 링크에 보면, Understanding Digital Signatures Authentication Nonrepudiation Data integrity 이 된다고 나와 있습니다. 즉 S/MIME 만으로 Nonrepudiation이 됩니다. 이 말은 곧 #메일은 필요없다는 의미입니다. 그리고 S/MIME은 서버와 Secure Channel을 통해 통신하는데, 이 과정에서는 반드시 공개키 암호화 방식을 써야 합니다. 공개키 암호화 방식은 서버와 클라이언트의 Secure Channel 형성과정이 반드시 필요하며, 이 과정에서 클라이언트의 정보를 보내줘야 합니다. 클라이언트의 언제, 어디서, 누가, 어떻게, 무엇을, 왜를 수집하게 됩니다. 이걸 사후에 대조하면 #메일의 '추적'이 됩니다. 결론: #메일 기능은 S/MIME으로 퉁칠 수 있습니다. 사실.. 우리나라같이 기초과학에 투자 안하는 나라에서, 완전히 수학의 영역인 암호학에 관련된 분야의 '개념'과 '기술'을 새로 만들어 내는 것은 불가능합니다. 이미 #메일의 기능은 십수년도 더 전에 나온 개념이고 이미 널리 사용중입니다.
13/10/11 23:25
공개키 암호화 방식이므로, 공개키는 한 번만 받으면 계속해서 쓸 수 있지요. 그 이후에는 서버가 클라이언트에게 정보를 보내줄 필요가 없는 것 같습니다. 샵메일은 등기의 온라인화를 목표로 하고 있으므로, 처음 확인 뿐만이 아니라 메세지를 보낼 때마다 이력의 관리가 필요합니다. 목적도 다르고, 서로 다른 기능이라고 생각되는데요.
13/10/11 23:29
공개키야 뭐 공개하라고 나와있는거니까요. 그 누가 알아도 상관없습니다.
Secure Channel 형성과정에서 클라이언트의 신원을 확인하는 것입니다. #메일의 기능은 이미 다 있는 기능입니다. 추가된 내용에 대한 댓글입니다. 위의 제 댓글에서 적은 것 처럼, #메일은 S/MIME 어플리케이션으로 대체가 가능합니다. S/MIME에 아주 간단한 구현을 올린 것 뿐이니까요. 말씀하신 수신확인, 이력관리.. 이건 그냥 S/MIME에 단순한 양념만 쳐 주면 되는 내용입니다.
13/10/11 23:33
Secure channel 형성은 두 사람 관의 관계를 맺는 것이지요. 이 때 정보 교환이 이루어지고(쌍방의 공개키를 교환) 신원이 확인됩니다. 이후 메세지 교환 때에는 더 이상 양방향 통신이 이루어지지 않습니다. 서버는 보내고, 클라이언트는 받죠. 클라이언트가 서버에게 뭔가를 줄 게 없습니다. 이게 S/MIME에 해당하겠죠.
등기는 처음 관계를 맺을 때 뿐만 아니라, 편지를 주고받을 때마다 클라이언트가 받았다는 것을 서버에게 알려야 합니다. 이는 양방향 통신이 있어야 한다는 이야기입니다. 전혀 다른 것입니다.
13/10/11 23:45
공개키는 공개하라고 나와있는겁니다. 그걸 오바마가 알든, 알카에다가 알든 상관 없습니다. 공개키만 알아봐야 그 어디도 쓸데가 없습니다.
메시지 교환하기 전에 Secure Channel을 형성하기 위한 가장 첫 단계가 공개키 교환일 뿐입니다. 나중에 '만약 Secure Channel을 형성했을 때' 상대방의 메시지를 풀어보려고요. 이미 상대방의 공개키를 알면 공개키를 안 받을 '수도 있고', 받을 '수도 있습니다.' 표준문서에 항상 받는지, 리포지터리에 들어있으면 올바른 것을 가지고 있다고 가정하든지 알아서 하라고 정의돼 있습니다. (보안성을 높이려면 오버헤드를 감수하고 매번 새 키를 받는게 좋겠죠.) 그런데 양방의 공개키가 있으면 뭐할까요? 그걸로는 쓸모가 없는데.. Secure Channel 형성과정을 봅시다. 일단 서버가 미끼를 던집니다. 클라이언트에게 서버의 Private 키로 암호화 해서 네녀석 이거 먹어봐... 라고 미끼를 툭 던집니다. 그러면 클라이언트가 먹습니다. 먹어서 서버 공개키로 풉니다. 그걸*1 클라이언트가 자신의 private 키로 암호화해서 서버로 던집니다. '내가 덥석 물었어!' 라고요. 서버는 그걸 클라이언트의 공개키로 풉니다. 자신이 던진 미끼와 동일하면*2 클라이언트를 인증합니다.*3 자, 여기서 공개키만 있으면 아무것도 못 한다는걸 알 수 있습니다.. 공개키 가지고 있어도 클라이언트를 인증 안하면 Secure Channel이 안 열리고, 당연히 메시지도 안 보냅니다. 샵 메일과 같은 기능을 하기 위해서는 위에서 별표 세군데를 바꾸면 됩니다. 저거 바꾸는 것도 표준규약에서 허용하는 범위입니다. *1: 서버의 미끼를 푼 메시지(Mserver)에 클라이언트의 5W1H 정보를 덧붙여 서버로 전송하도록 수정 *2: 서버가 가지고 있는 메시지(Mserver)과 클라이언트가 보낸 메시지(Mclient = Mserver + 5W1Hclient)의 Mserver가 같은지 확인하고, 클라이언트의 5W1H가 적합한지 확인합니다. 예를들어 메일접속IP와 시큐어 채널을 요구하는 클라이언트의 IP가 같은지 등등.. 사후 추적이 가능한 모든 정보 확인 *3: 부적합하면 Secure Channel 수락을 안합니다. 공개키만 있어봐야 할 수 있는건 없습니다. 공개키도 있고 다른 것도 있어야죠.. 공개키는 오바마도 알아도 되고 알카에다도 알아도 됩니다. #메일 기능은 그냥 S/MIME으로도 다 됩니다.. 저런거 하라고 Digital Certificate, Digital Signature가 있는거라서요... ps. Secure Channel 자체가 근본부터가 양방향 통신입니다.
13/10/11 23:56
UNITED 님// 제 말을 잘 이해하지 못하는 것 같은데, 말씀하신 건 처음에 서버와 클라이언트 간의 신원 확인에 관한 내용을 설명하신 거구요, 저는 그게 아니라 실제 이메일을 주고 받을 때를 얘기하는 겁니다. 처음 secure channel 만들 때는 당연히 양방향 통신이 이루어지고, 부가 정보를 교환하도록 해도 되죠,
짧게 질문하겠습니다. 두 번째부터의 통신에서(secure channel 형성 아닙니다!), 클라이언트로부터 서버로의 통신이 이루어져야 한다고 규정된 부분이 있습니까? 제가 보기에는 없습니다.
13/10/12 00:05
올라갈팀은올라간다 님// 만약 상호의 공개키를 가지고 있을 때 무조건 커넥션을 수락한다면 그 것은 암호화가 아니고 Secure Channel도 아니죠. 그냥 공개키만 가지면 무조건 채널이 열리는걸요. 전혀 안전하지 않습니다.
아주 단순한 TCP 3-Way Handshake도 매번 접속시 클라이언트를 확인하는데, 명색이 암호화 프로토콜이 아무런 조건없이 덜컥 수락하고 그러면 안되지요. 가장 널리 쓰이는 공개키 방식 Secure Channel인 SSL의 커넥션 재 성립 (즉 기존에 공개키가 교환된 적 있는 상호간의 커넥션 재 성립)과정의 링크를 보내 드립니다. 저의 귀차니즘 관계로 표준문서는 일일이 검색하기엔 벅차네요. 표준문서는 찾아야 할 양이 너무 많습니다. http://pic.dhe.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=%2Fcom.ibm.ztpf-ztpfdf.doc_put.cur%2Fgtps5%2Fs5hand.html To resume an SSL session over a new socket, the client includes the session ID of that particular SSL session in the CLIENT_HELLO command that it sends. If the server does not have that session ID in its SSL cache, a new SSL session must be started and the normal SSL handshake flows occur. The server indicates this by creating a new session ID and returning the ID in its SERVER_HELLO command. 질문하신 "짧게 질문하겠습니다. 두 번째부터의 통신에서(secure channel 형성 아닙니다!), 클라이언트로부터 서버로의 통신이 이루어져야 한다고 규정된 부분이 있습니까? 제가 보기에는 없습니다." 에 대한 답변입니다. 당연히 있습니다. Handshake로 검색하시면 나올겁니다. 서로 HELLO 메시지를 주고받아야 한다고 나오죠. 말씀하신 것 처럼 두 번째 통신에서 매 커넥션마다 클라이언트와 서버간 인증을 안 하면 그 것은 암호화를 안 한다는겁니다. 그리고 공개키도 서로 확인할 필요도 없고요. 확인하는건 그냥 전기와 시간만 낭비하는 헛짓입니다. 반드시 해야 한다는 것은 위 링크에도 잘 설명되어 있습니다. ps. 암호화를 안 한다 -> Digital Certificate이 아니다, Digital Signature가 아니다 -> 부인방지가 안된다, 데이터 정합성이 보증되지 않는다 -> 수신확인과 메일이력 추적이 보증되지 않는다 -> 그냥 메일과 다를게 하등 없다. 입니다.
13/10/12 00:23
올라갈팀은올라간다 님// 해당 내용이 반드시 필요하다는 표준문서 내용입니다.
이게 TLS라 좀 옛날거긴 합니다만, 가장 기본이 되는 handshake 절차에는 변함이 없습니다. 문서 번호는 RFC 2246 이고, These goals are achieved by the handshake protocol, which can be summarized as follows: The client sends a client hello message to which the server must respond with a server hello message, or else a fatal error will occur and the connection will fail. The client hello and server hello are used to establish security enhancement capabilities between client and server. The client hello and server hello establish the following attributes: Protocol Version, Session ID, Cipher Suite, and Compression Method. Additionally, two random values are generated and exchanged: ClientHello.random and ServerHello.random. Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Fig. 1 - Message flow for a full handshake 이건 최초 handshake이고, Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data Fig. 2 - Message flow for an abbreviated handshake 이건 재성립입니다. 도식에서 보이는 것 처럼 서로 미끼를 주고받죠... 댓글에선 깨져보이는데 http://www.ietf.org/rfc/rfc2246.txt 의 페이지 29부터 보시면 됩니다. 이제 충분한 답변이 되셨나요?
13/10/12 00:26
UNITED 님// 이제 이해되는 것 같습니다. 님께서는 공개키/개인키 개념을 혼동하고 계시는 것 같습니다. 공개키만 가지고 있으면 무조건 채널이 열린다, 서로 인증(통신을 통해서를 말씀하시는 거겠죠)을 안 하면 암호화를 안 한다고 하셨는데, 그 부분이 오인되는 부분인 것 같습니다. 중요한 점은, 공개키를 교환한 것 뿐만 아니라, 서버는 서버의 비밀 키를 가지고 있고, 클라이언트는 클라이언트의 비밀 키를 가지고 있다는 점입니다. 이 때문에 누구나 다 아는 공개 키만을 교환함으로써 1)누가 보냈는지 확인할 수 있고(signature) 2) 다른 사람이 볼 수 없는 통신(encryption)이 가능한 것입니다. 이 과정에서는 양방간의 인증 같은 건 없습니다.
13/10/12 00:27
올라갈팀은올라간다 님// 표준문서를 보여드렸는데 그리 말씀하시니, 저는 이제 포기하겠습니다. -_-;
표준문서에는 분.명.히. 상호간의 인증을 하라고 나와있습니다... -_-;;;;;
13/10/12 00:28
UNITED 님// 두 번째 다신 내용 또한 secure channel 최초 성립과 재성립의 방법(handshake라고 하네요. 재밌는 표현이네요)을 설명하셨네요. 제 주장의 요지는 재성립이 이루어지지 않아도 S/MIME는 가능하다는 것입니다.
13/10/12 00:31
올라갈팀은올라간다 님// 네... 주장은 주장이고 표준문서는 표준문서입니다.
용도에 맞게 바꿀 수 있는게 규칙이죠... S/MIME을 이력관리용으로 쓰는데 그냥 다 풀어놓고 쓰면 (세션타임을 1년으로 해 둔다거나...) 그게 설계결함입니다. 대표적으로 RC4를 마구잡이로 써서 문제가 된 WEP가 있죠?... 아 그리고 제가 한글용어를 몰라서 죄송할 따름입니다.
13/10/12 00:37
UNITED 님// 아 혹시 오해하셨다면 죄송한데 재밌다는 건 정말 재미있어서 한 말입니다. 저는 이쪽에 문외한이라 암호학이나 컴퓨터과학하는 사람들이 재밌게 사는 것 같아서요.
즉 님이 표준으로 주장하시는 바는 A를 위해서는 B가 필요하다, 따라서 B를 이용해서 원하는 기능을 얻을 수 있다 이고, 저는 A 자체가 필요 없으므로 B도 필요 없고, 따라서 원하는 기능을 얻으려면 새로운 표준이 필요하다 라고 이야기하는 것입니다.
13/10/12 00:47
UNITED 님// 앞에 댓글을 수정한 부분을 지금 읽었는데, 샵메일은 간단한 어플리케이션으로 대체가 가능하다고 하셨네요. 이게 맞는 말 같습니다. 일반 이메일을 간단한 양념을 쳐서 S/MIME가 되고, 또 거기에 양념을 치면 샵메일(Secure-Tracked/MIME라고 멋대로 이름을 붙일 수도 있겠네요)이 되는 거겠지요. 양념은 요리에 중요하지요.
|
||||||||||